draft-ietf-grow-bgp-session-culling-05.txt		rfc8327.txt
	Global Routing Operations W. Hargrave		Internet Engineering Task Force (IETF) W. Hargrave
	Internet-Draft LONAP		Request for Comments: 8327 LONAP
	Intended status: Best Current Practice M. Griswold		BCP: 214 M. Griswold
	Expires: April 1, 2018 20C		Category: Best Current Practice 20C
	J. Snijders		ISSN: 2070-1721 J. Snijders
	NTT		NTT
	N. Hilliard		N. Hilliard
	INEX		INEX
	September 28, 2017		March 2018
	Mitigating Negative Impact of Maintenance through BGP Session Culling		Mitigating the Negative Impact of Maintenance through
	draft-ietf-grow-bgp-session-culling-05		BGP Session Culling
	Abstract		Abstract
	This document outlines an approach to mitigate negative impact on		This document outlines an approach to mitigate the negative impact on
	networks resulting from maintenance activities. It includes guidance		networks resulting from maintenance activities. It includes guidance
	for both IP networks and Internet Exchange Points (IXPs). The		for both IP networks and Internet Exchange Points (IXPs). The
	approach is to ensure BGP-4 sessions affected by the maintenance are		approach is to ensure BGP-4 sessions that will be affected by
	forcefully torn down before the actual maintenance activities		maintenance are forcefully torn down before the actual maintenance
	commence.		activities commence.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This memo documents an Internet Best Current Practice.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			BCPs is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on April 1, 2018.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8327.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
	3. BGP Session Culling . . . . . . . . . . . . . . . . . . . . . 3		3. BGP Session Culling . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Voluntary BGP Session Teardown Recommendations . . . . . 3		3.1. Voluntary BGP Session Teardown Recommendations . . . . . 4
	3.1.1. Maintenance Considerations . . . . . . . . . . . . . 4		3.1.1. Maintenance Considerations . . . . . . . . . . . . . 4
	3.2. Involuntary BGP Session Teardown Recommendations . . . . 4		3.2. Involuntary BGP Session Teardown Recommendations . . . . 4
	3.2.1. Packet Filter Considerations . . . . . . . . . . . . 4		3.2.1. Packet-Filter Considerations . . . . . . . . . . . . 5
	3.2.2. Hardware Considerations . . . . . . . . . . . . . . . 5		3.2.2. Hardware Considerations . . . . . . . . . . . . . . . 5
	3.3. Procedural Considerations . . . . . . . . . . . . . . . . 6		3.3. Procedural Considerations . . . . . . . . . . . . . . . . 6
	4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		6.1. Normative References . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		6.2. Informative References . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 7		Appendix A. Example Packet Filters . . . . . . . . . . . . . . . 8
	Appendix A. Example packet filters . . . . . . . . . . . . . . . 7		A.1. Example Configuration for Cisco IOS, IOS XR, and Arista
	A.1. Cisco IOS, IOS XR & Arista EOS Firewall Example		EOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Configuration . . . . . . . . . . . . . . . . . . . . . . 7		A.2. Example Configuration for Nokia SR OS . . . . . . . . . . 9
	A.2. Nokia SR OS Filter Example Configuration . . . . . . . . 8		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	BGP Session Culling is the practice of ensuring BGP sessions are		BGP Session Culling is the practice of ensuring BGP sessions are
	forcefully torn down before maintenance activities on a lower layer		forcefully torn down before maintenance activities on a lower-layer
	network commence, which otherwise would affect the flow of data		network commence -- activities that otherwise would affect the flow
	between the BGP speakers.		of data between the BGP speakers. BGP Session Culling is the
			practice of ensuring BGP sessions are forcefully torn down before
			commencing maintenance activities (that otherwise would affect the
			flow of data between the BGP speakers) on a lower-layer network.
	BGP Session Culling ensures that lower layer network maintenance		BGP Session Culling minimizes the amount of disruption that lower-
	activities cause the minimum possible amount of disruption, by		layer network maintenance activities cause, by making BGP speakers
	causing BGP speakers to preemptively converge onto alternative paths		preemptively converge onto alternative paths while the lower-layer
	while the lower layer network's forwarding plane remains fully		network's forwarding plane remains fully operational.
	operational.
	The grace period required for a successful application of BGP Session		The grace period required for a successful application of BGP Session
	Culling is the sum of the time needed to detect the loss of the BGP		Culling is the sum of the time needed to detect the loss of the BGP
	session, plus the time required for the BGP speaker to converge onto		session plus the time required for the BGP speaker to converge onto
	alternative paths. The first value is often governed by the BGP Hold		alternative paths. The first value is often governed by the BGP Hold
	Timer (section 6.5 of [RFC4271]), commonly between 90 and 180		Timer (see Section 6.5 of [RFC4271]), which is commonly between 90
	seconds. The second value is implementation specific, but could be		and 180 seconds. The second value is implementation specific, but it
	as much as 15 minutes when a router with a slow control-plane is		could be as much as 15 minutes when a router with a slow control
	receiving a full set of Internet routes.		plane is receiving a full set of Internet routes.
	Throughout this document the "Caretaker" is defined to be in control		Throughout this document, the "Caretaker" is defined to be in control
	of the lower layer network, while "Operators" directly administrate		of the lower-layer network, while "Operators" directly administrate
	the BGP speakers. Operators and Caretakers implementing BGP Session		the BGP speakers. Operators and Caretakers implementing BGP Session
	Culling are encouraged to avoid using a fixed grace period, but		Culling are encouraged to avoid using a fixed grace period, and
	instead monitor forwarding plane activity while the culling is taking		instead to monitor forwarding-plane activity while the culling is
	place and consider it complete once traffic levels have dropped to a		taking place and to consider it complete once traffic levels have
	minimum (Section 3.3).		dropped to a minimum (Section 3.3).
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC 2119 [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. BGP Session Culling		3. BGP Session Culling
	From the viewpoint of the Operator, there are two types of BGP		From the viewpoint of the Operator, there are two types of BGP
	Session Culling:		Session Culling:
	Voluntary BGP Session Teardown: The Operator initiates the tear down		Voluntary BGP Session Teardown: The Operator initiates the teardown
	of the potentially affected BGP session by issuing an		of the potentially affected BGP session by issuing an
	Administrative Shutdown.		Administrative Shutdown.
	Involuntary BGP Session Teardown: The Caretaker of the lower layer		Involuntary BGP Session Teardown: The Caretaker of the lower-layer
	network disrupts (higher layer) BGP control-plane traffic, causing		network disrupts (higher-layer) BGP control-plane traffic, causing
	the BGP Hold Timers of the affected BGP session to expire,		the BGP Hold Timers of the affected BGP session to expire,
	subsequently triggering rerouting of end user traffic.		subsequently triggering rerouting of end-user traffic.
	3.1. Voluntary BGP Session Teardown Recommendations		3.1. Voluntary BGP Session Teardown Recommendations
	Before an Operator commences activities which can cause disruption to		Before an Operator commences activities that can cause disruption to
	the flow of data through the lower layer network, an Operator can		the flow of data through the lower-layer network, an Operator can
	reduce loss of traffic by issuing an administrative shutdown to all		reduce loss of traffic by issuing an administrative shutdown to all
	BGP sessions running across the lower layer network and wait a few		BGP sessions running across the lower-layer network and wait a few
	minutes for data-plane traffic to subside.		minutes for data-plane traffic to subside.
	While architectures exist to facilitate quick network reconvergence		While architectures exist to facilitate quick network reconvergence
	(such as BGP PIC [I-D.ietf-rtgwg-bgp-pic]), an Operator cannot assume		(such as BGP Prefix Independent Convergence (PIC) [BGP_PIC]), an
	the remote side has such capabilities. As such, a grace period		Operator cannot assume the remote side has such capabilities. As
	between the Administrative Shutdown and the impacting maintenance		such, a grace period between the Administrative Shutdown and the
	activities is warranted.		impacting maintenance activities is warranted.
	After the maintenance activities have concluded, the Operator is		After the maintenance activities have concluded, the Operator is
	expected to restore the BGP sessions to their original Administrative		expected to restore the BGP sessions to their original Administrative
	state.		state.
	3.1.1. Maintenance Considerations		3.1.1. Maintenance Considerations
	Initiators of the administrative shutdown MAY consider using Graceful		Initiators of the Administrative Shutdown MAY consider using Graceful
	Shutdown [I-D.ietf-grow-bgp-gshut] to facilitate smooth drainage of		Shutdown [RFC8326] to facilitate smooth drainage of traffic prior to
	traffic prior to session tear down, and the Shutdown Communication		session tear down, and the Shutdown Communication [RFC8203] to inform
	[RFC8203] to inform the remote side on the nature and duration of the		the remote side on the nature and duration of the maintenance
	maintenance activities.		activities.
	3.2. Involuntary BGP Session Teardown Recommendations		3.2. Involuntary BGP Session Teardown Recommendations
	In the case where multilateral interconnection between BGP speakers		In the case where multilateral interconnection between BGP speakers
	is facilitated through a switched layer-2 fabric, such as commonly		is facilitated through a switched Layer 2 fabric, such as commonly
	seen at Internet Exchange Points (IXPs), different operational		seen at Internet Exchange Points (IXPs), different operational
	considerations can apply.		considerations can apply.
	Operational experience shows many Operators are unable to carry out		Operational experience shows that many Operators are unable to carry
	the Voluntary BGP Session Teardown recommendations, because of the		out the Voluntary BGP Session Teardown recommendations, because of
	operational cost and risk of coordinating the two configuration		the operational cost and risk of coordinating the two configuration
	changes required. This has an adverse affect on Internet		changes required. This has an adverse affect on Internet
	performance.		performance.
	In the absence of notifications from the lower layer (e.g. Ethernet		In the absence of notifications from the lower layer (e.g., Ethernet
	link down) consistent with the planned maintenance activities in a		link down) consistent with the planned maintenance activities in a
	switched layer-2 fabric, the Caretaker of the fabric could choose to		switched Layer 2 fabric, the Caretaker of the fabric could choose to
	cull BGP sessions on behalf of the Operators connected to the fabric.		cull BGP sessions on behalf of the Operators connected to the fabric.
	Such culling of control-plane traffic will preempt the loss of end-		Such culling of control-plane traffic will preempt the loss of end-
	user traffic, by causing the expiration of BGP Hold Timers ahead of		user traffic by causing the expiration of BGP Hold Timers ahead of
	the moment where the expiration would occur without intervention from		the moment where the expiration would occur without intervention from
	the fabric's Caretaker.		the fabric's Caretaker.
	In this scenario, BGP Session Culling is accomplished as described in		In this scenario, BGP Session Culling is accomplished as described in
	the next sub-section, through the application of a combined layer-3		the next subsection, through the application of a combined Layer 3
	and layer-4 packet filter deployed in the Caretaker's switched		and Layer 4 (Layer 3/4) packet filter deployed in the Caretaker's
	fabric.		switched fabric.
	3.2.1. Packet Filter Considerations		3.2.1. Packet-Filter Considerations
	The peering LAN prefixes used by the IXP form the control plane, and		The peering LAN prefixes used by the IXP form the control plane, and
	following considerations apply to the packet filter design:		the following considerations apply to the packet-filter design:
	o The packet filter MUST only affect BGP traffic specific to the		o The packet filter MUST only affect BGP traffic specific to the
	layer-2 fabric, i.e. forming part of the control plane of the		Layer 2 fabric, i.e., traffic forming part of the control plane of
	system described, rather than multihop BGP traffic which merely		the system described, rather than multihop BGP traffic that merely
	transits.		transits.
	o The packet filter MUST only affect BGP, i.e. TCP/179.		o The packet filter MUST only affect BGP, i.e., TCP port 179.
	o The packet filter SHOULD make provision for the bidirectional		o The packet filter SHOULD make provision for the bidirectional
	nature of BGP, i.e. that sessions may be established in either		nature of BGP, i.e., sessions may be established in either
	direction.		direction.
	o The packet filter MUST affect all Address Family Identifiers.		o The packet filter MUST affect all Address Family Identifiers.
	Appendix A contains examples of correct packet filters for various		Appendix A contains examples of correct packet filters for various
	platforms.		platforms.
	3.2.2. Hardware Considerations		3.2.2. Hardware Considerations
	Not all hardware is capable of deploying Layer 3 / Layer 4 filters on		Not all hardware is capable of deploying combined Layer 3/4 filters
	Layer 2 ports, and even on platforms which claim support for such a		on Layer 2 ports; even on platforms that claim support for such a
	feature, limitations may exist or hardware resource allocation		feature, limitations may exist or hardware resource allocation
	failures may occur during filter deployment which may cause		failures may occur during filter deployment, which may cause
	unexpected results. These problems may include:		unexpected results. These problems may include:
	o Platform inability to apply layer 3/4 filters on ports which		o Platform inability to apply Layer 3/4 filters on ports that
	already have layer 2 filters applied.		already have Layer 2 filters applied.
	o Layer 3/4 filters supported for IPv4 but not for IPv6.		o Layer 3/4 filters supported for IPv4 but not for IPv6.
	o Layer 3/4 filters supported on physical ports, but not on 802.3ad		o Layer 3/4 filters supported on physical ports, but not on IEEE
	Link Aggregate ports.		802.1AX Link Aggregate ports [IEEE802.1AX].
	o Failure of the Caretaker to apply filters to all 802.3ad Link		o Failure of the Caretaker to apply filters to all IEEE 802.1AX Link
	Aggregate ports.		Aggregate ports [IEEE802.1AX].
	o Limitations in ACL hardware mechanisms causing filters not to be		o Limitations in Access Control List (ACL) hardware mechanisms
	applied.		causing filters not to be applied.
	o Fragmentation of ACL lookup memory causing transient ACL		o Fragmentation of ACL lookup memory causing transient ACL
	application problems which are resolved after ACL removal /		application problems that are resolved after ACL removal/
	reapplication.		reapplication.
	o Temporary service loss during hardware programming		o Temporary service loss during hardware programming.
	o Reduction in hardware ACL capacity if the platform enables		o Reduction in hardware ACL capacity if the platform enables
	lossless ACL application.		lossless ACL application.
	It is advisable for the Caretaker to be aware of the limitations of		It is advisable for the Caretaker to be aware of the limitations of
	their hardware, and to thoroughly test all complicated configurations		their hardware and to thoroughly test all complicated configurations
	in advance to ensure that problems don't occur during production		in advance to ensure that problems don't occur during production
	deployments.		deployments.
	3.3. Procedural Considerations		3.3. Procedural Considerations
	The Caretaker of the lower layer network can monitor data-plane		The Caretaker of the lower-layer network can monitor data-plane
	traffic (e.g. interface counters) and carry out the maintenance		traffic (e.g., interface counters) and carry out the maintenance
	without impact to traffic once session culling is complete.		without impact to traffic once session culling is complete.
	It is recommended that the packet filters are only deployed for the		It is recommended that the packet filters be deployed for the
	duration of the maintenance and immediately removed after the		duration of the maintenance only and be removed immediately after the
	maintenance. To prevent unnecessarily troubleshooting, it is		maintenance is completed. To prevent unnecessary troubleshooting, it
	RECOMMENDED that Caretakers notify the affected Operators before the		is RECOMMENDED that Caretakers notify the affected Operators before
	maintenance takes place, and make it explicit that the Involuntary		the maintenance takes place and make it explicit that the Involuntary
	BGP Session Culling methodology will be applied.		BGP Session Culling methodology will be applied.
	4. Acknowledgments		4. Security Considerations
	The authors would like to thank the following people for their
	contributions to this document: Saku Ytti, Greg Hankins, James
	Bensley, Wolfgang Tremmel, Daniel Roesen, Bruno Decraene, Tore
	Anderson, John Heasley, Warren Kumari, Stig Venaas, and Brian
	Carpenter.
	5. Security Considerations
	There are no security considerations.		There are no security considerations.
	6. IANA Considerations		5. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. References		6. References
	7.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<https://www.rfc-editor.org/info/rfc4271>.		<https://www.rfc-editor.org/info/rfc4271>.
	7.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[I-D.ietf-grow-bgp-gshut]		6.2. Informative References
	Francois, P., Decraene, B., Pelsser, C., Patel, K., and C.
	Filsfils, "Graceful BGP session shutdown", draft-ietf-
	grow-bgp-gshut-11 (work in progress), September 2017.
	[I-D.ietf-rtgwg-bgp-pic]		[BGP_PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP
	Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix		Prefix Independent Convergence", Work in Progress,
	Independent Convergence", draft-ietf-rtgwg-bgp-pic-05		draft-ietf-rtgwg-bgp-pic-06, November 2017.
	(work in progress), May 2017.
			[IEEE802.1AX]
			IEEE, "IEEE Standard for Local and metropolitan area
			networks -- Link Aggregation", IEEE Std 802.1AX-2014,
			DOI 10.1109/IEEESTD.2014.7055197, December 2014,
			<http://ieeexplore.ieee.org/servlet/
			opac?punumber=6997981>.
	[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP		[RFC8203] Snijders, J., Heitz, J., and J. Scudder, "BGP
	Administrative Shutdown Communication", RFC 8203,		Administrative Shutdown Communication", RFC 8203,
	DOI 10.17487/RFC8203, July 2017,		DOI 10.17487/RFC8203, July 2017,
	<https://www.rfc-editor.org/info/rfc8203>.		<https://www.rfc-editor.org/info/rfc8203>.
	7.3. URIs		[RFC8326] Francois, P., Ed., Decraene, B., Ed., Pelsser, C., Patel,
			K., and C. Filsfils, "Graceful BGP Session Shutdown",
	[1] https://github.com/bgp/bgp-session-culling-config-examples		RFC 8326, DOI 10.17487/8326, March 2018,
			<https://www.rfc-editor.org/info/rfc8326>.
	Appendix A. Example packet filters		Appendix A. Example Packet Filters
	Example packet filters for "Involuntary BGP Session Teardown" at an		This section includes examples of packet filters performing
	IXP using peering LAN prefixes 192.0.2.0/24 and 2001:db8:2::/64 as		Involuntary BGP Session Teardown at an IXP using peering LAN prefixes
	its control plane.		192.0.2.0/24 and 2001:db8:2::/64 as its control plane.
	A repository of configuration examples for a number of assorted		A repository of configuration examples for a number of assorted
	platforms can be found at https://github.com/bgp/bgp-session-culling-		platforms can be found at
	config-examples [1].		<https://github.com/bgp/bgp-session-culling-config-examples>.
	A.1. Cisco IOS, IOS XR & Arista EOS Firewall Example Configuration		A.1. Example Configuration for Cisco IOS, IOS XR, and Arista EOS
	ipv6 access-list acl-ipv6-permit-all-except-bgp		ipv6 access-list acl-ipv6-permit-all-except-bgp
	10 deny tcp 2001:db8:2::/64 eq bgp 2001:db8:2::/64		10 deny tcp 2001:db8:2::/64 eq bgp 2001:db8:2::/64
	20 deny tcp 2001:db8:2::/64 2001:db8:2::/64 eq bgp		20 deny tcp 2001:db8:2::/64 2001:db8:2::/64 eq bgp
	30 permit ipv6 any any		30 permit ipv6 any any
	!		!
	ip access-list acl-ipv4-permit-all-except-bgp		ip access-list acl-ipv4-permit-all-except-bgp
	10 deny tcp 192.0.2.0/24 eq bgp 192.0.2.0/24		10 deny tcp 192.0.2.0/24 eq bgp 192.0.2.0/24
	20 deny tcp 192.0.2.0/24 192.0.2.0/24 eq bgp		20 deny tcp 192.0.2.0/24 192.0.2.0/24 eq bgp
	30 permit ip any any		30 permit ip any any
	!		!
	interface Ethernet33		interface Ethernet33
	description IXP Participant Affected by Maintenance		description IXP Participant Affected by Maintenance
	ip access-group acl-ipv4-permit-all-except-bgp in		ip access-group acl-ipv4-permit-all-except-bgp in
	ipv6 access-group acl-ipv6-permit-all-except-bgp in		ipv6 access-group acl-ipv6-permit-all-except-bgp in
	!		!
	A.2. Nokia SR OS Filter Example Configuration		A.2. Example Configuration for Nokia SR OS
	ip-filter 10 create		ip-filter 10 create
	filter-name "ACL IPv4 Permit All Except BGP"		filter-name "ACL IPv4 Permit All Except BGP"
	default-action forward		default-action forward
	entry 10 create		entry 10 create
	match protocol tcp		match protocol tcp
	dst-ip 192.0.2.0/24		dst-ip 192.0.2.0/24
	src-ip 192.0.2.0/24		src-ip 192.0.2.0/24
	port eq 179		port eq 179
	exit		exit
	skipping to change at page 8, line 45 ¶		skipping to change at page 10, line 5 ¶
	exit		exit
	interface "port-1/1/1"		interface "port-1/1/1"
	description "IXP Participant Affected by Maintenance"		description "IXP Participant Affected by Maintenance"
	ingress		ingress
	filter ip 10		filter ip 10
	filter ipv6 10		filter ipv6 10
	exit		exit
	exit		exit
			Acknowledgments
			The authors would like to thank the following people for their
			contributions to this document: Saku Ytti, Greg Hankins, James
			Bensley, Wolfgang Tremmel, Daniel Roesen, Bruno Decraene, Tore
			Anderson, John Heasley, Warren Kumari, Stig Venaas, and Brian
			Carpenter.
	Authors' Addresses		Authors' Addresses
	Will Hargrave		Will Hargrave
	LONAP Ltd		LONAP Ltd
	5 Fleet Place		5 Fleet Place
	London EC4M 7RD		London EC4M 7RD
	United Kingdom		United Kingdom
	Email: will@lonap.net		Email: will@lonap.net
	Matt Griswold		Matt Griswold
	20C		20C
End of changes. 64 change blocks.
	145 lines changed or deleted		153 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/