draft-ietf-bess-nsh-bgp-control-plane-05.txt		draft-ietf-bess-nsh-bgp-control-plane-06.txt
	BESS Working Group A. Farrel		BESS Working Group A. Farrel
	Internet-Draft Old Dog Consulting		Internet-Draft Old Dog Consulting
	Intended status: Standards Track J. Drake		Intended status: Standards Track J. Drake
	Expires: July 16, 2019 E. Rosen		Expires: August 29, 2019 E. Rosen
	Juniper Networks		Juniper Networks
	J. Uttaro		J. Uttaro
	AT&T		AT&T
	L. Jalil		L. Jalil
	Verizon		Verizon
	January 12, 2019		February 25, 2019
	BGP Control Plane for NSH SFC		BGP Control Plane for NSH SFC
	draft-ietf-bess-nsh-bgp-control-plane-05		draft-ietf-bess-nsh-bgp-control-plane-06
	Abstract		Abstract
	This document describes the use of BGP as a control plane for		This document describes the use of BGP as a control plane for
	networks that support Service Function Chaining (SFC). The document		networks that support Service Function Chaining (SFC). The document
	introduces a new BGP address family called the SFC AFI/SAFI with two		introduces a new BGP address family called the SFC AFI/SAFI with two
	route types. One route type is originated by a node to advertise		route types. One route type is originated by a node to advertise
	that it hosts a particular instance of a specified service function.		that it hosts a particular instance of a specified service function.
	This route type also provides "instructions" on how to send a packet		This route type also provides "instructions" on how to send a packet
	to the hosting node in a way that indicates that the service function		to the hosting node in a way that indicates that the service function
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 15, 2019.		This Internet-Draft will expire on Augus7 29, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	skipping to change at page 3, line 6 ¶		skipping to change at page 3, line 6 ¶
	6.2. Implications for Forwarding State . . . . . . . . . . . . 27		6.2. Implications for Forwarding State . . . . . . . . . . . . 27
	7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28		7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 28
	7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28		7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 28
	7.2. Correlating Service Function Path Instances . . . . . . . 28		7.2. Correlating Service Function Path Instances . . . . . . . 28
	7.3. Considerations for Stateful Service Functions . . . . . . 29		7.3. Considerations for Stateful Service Functions . . . . . . 29
	7.4. VPN Considerations and Private Service Functions . . . . 30		7.4. VPN Considerations and Private Service Functions . . . . 30
	7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30		7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30
	7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32		7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32
	7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33		7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33
	7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33		7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33
	8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33		7.8. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 33
			8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35		8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35
	8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 35		8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 36
	8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 36		8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 37
	8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37		8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 37
	8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 37		8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 38
	8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38		8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 38
	8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 38		8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 39
	8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 39		8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 40
	8.9. Examples of SFPs with Stateful Service Functions . . . . 40		8.9. Examples of SFPs with Stateful Service Functions . . . . 40
	8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 40		8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 41
	8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 41		8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 42
	8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 42		8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 43
	8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 44		8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 45
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 47		9. Security Considerations . . . . . . . . . . . . . . . . . . . 48
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
	10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 48		10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 49
	10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 48		10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 49
	10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 48		10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 49
	10.4. New SFP Association Type Registry . . . . . . . . . . . 49		10.4. New SFP Association Type Registry . . . . . . . . . . . 50
	10.5. New Service Function Type Registry . . . . . . . . . . . 49		10.5. New Service Function Type Registry . . . . . . . . . . . 50
	10.6. New Generic Transitive Experimental Use Extended		10.6. New Generic Transitive Experimental Use Extended
	Community Sub-Types . . . . . . . . . . . . . . . . . . 50		Community Sub-Types . . . . . . . . . . . . . . . . . . 51
	10.7. New BGP Transitive Extended Community Types . . . . . . 50		10.7. New BGP Transitive Extended Community Types . . . . . . 51
	10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 51		10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 52
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 51		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
	13.1. Normative References . . . . . . . . . . . . . . . . . . 51		13.1. Normative References . . . . . . . . . . . . . . . . . . 52
	13.2. Informative References . . . . . . . . . . . . . . . . . 52		13.2. Informative References . . . . . . . . . . . . . . . . . 53
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
	1. Introduction		1. Introduction
	As described in [RFC7498], the delivery of end-to-end services can		As described in [RFC7498], the delivery of end-to-end services can
	require a packet to pass through a series of Service Functions (SFs)		require a packet to pass through a series of Service Functions (SFs)
	(e.g., classifiers, firewalls, TCP accelerators, and server load		(e.g., classifiers, firewalls, TCP accelerators, and server load
	balancers) in a specified order: this is termed "Service Function		balancers) in a specified order: this is termed "Service Function
	Chaining" (SFC). There are a number of issues associated with		Chaining" (SFC). There are a number of issues associated with
	deploying and maintaining service function chaining in production		deploying and maintaining service function chaining in production
	networks, which are described below.		networks, which are described below.
	skipping to change at page 11, line 26 ¶		skipping to change at page 11, line 26 ¶
	determined by provisioning. If two SFIRs are originated from		determined by provisioning. If two SFIRs are originated from
	different administrative domains, they must have different RDs. In		different administrative domains, they must have different RDs. In
	particular, SFIRs from different VPNs (for different service function		particular, SFIRs from different VPNs (for different service function
	overlay networks) must have different RDs, and those RDs must be		overlay networks) must have different RDs, and those RDs must be
	different from any non-VPN SFIRs.		different from any non-VPN SFIRs.
	The Service Function Type identifies a service function, e.g.,		The Service Function Type identifies a service function, e.g.,
	classifier, firewall, load balancer, etc. There may be several SFIs		classifier, firewall, load balancer, etc. There may be several SFIs
	that can perform a given Service Function. Each node hosting an SFI		that can perform a given Service Function. Each node hosting an SFI
	must originate an SFIR for each type of SF that it hosts, and it may		must originate an SFIR for each type of SF that it hosts, and it may
	advertize an SFIR for each instance of each type of SF. The SFIR		advertise an SFIR for each instance of each type of SF. The SFIR
	representing a given SFI will contain an NLRI with RD field set to an		representing a given SFI will contain an NLRI with RD field set to an
	RD as specified above, and with SFT field set to identify that SFI's		RD as specified above, and with SFT field set to identify that SFI's
	Service Function Type. The values for the SFT field are taken from a		Service Function Type. The values for the SFT field are taken from a
	registry administered by IANA (see Section 10). A BGP Update		registry administered by IANA (see Section 10). A BGP Update
	containing one or more SFIRs will also include a Tunnel Encapsulation		containing one or more SFIRs will also include a Tunnel Encapsulation
	attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be		attribute [I-D.ietf-idr-tunnel-encaps]. If a data packet needs to be
	sent to an SFI identified in one of the SFIRs, it will be		sent to an SFI identified in one of the SFIRs, it will be
	encapsulated as specified by the Tunnel Encapsulation attribute, and		encapsulated as specified by the Tunnel Encapsulation attribute, and
	then transmitted through the underlay network.		then transmitted through the underlay network.
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 37 ¶
	+--------------------------------------------+		+--------------------------------------------+
	| Type = 0x80 (1 octet) |		| Type = 0x80 (1 octet) |
	+--------------------------------------------|		+--------------------------------------------|
	| Sub-Type = TBD7 (1 octet) |		| Sub-Type = TBD7 (1 octet) |
	+--------------------------------------------|		+--------------------------------------------|
	| SFC Context Label (3 octets) |		| SFC Context Label (3 octets) |
	+--------------------------------------------|		+--------------------------------------------|
	| SF Label (3 octets) |		| SF Label (3 octets) |
	+--------------------------------------------+		+--------------------------------------------+
	Figure 5: The MPLS Mixed Swapping/Stacking Labels		Figure 5: The MPLS Mixed Swapping/Stacking Extended Community
	Note that it is assumed that each SFF has one or more globally unique		Note that it is assumed that each SFF has one or more globally unique
	SFC Context Labels and that the context label space and the SPI		SFC Context Labels and that the context label space and the SPI
	address space are disjoint.		address space are disjoint.
			If an SFF supports SFP Traversal with an MPLS Label Stack it MUST
			include this extended community with the SFIRs that it advertises.
	See Section 7.7 for a description of how this extended community is		See Section 7.7 for a description of how this extended community is
	used.		used.
	3.2. Service Function Path Route (SFPR)		3.2. Service Function Path Route (SFPR)
	Figure 6 shows the Route Type specific NLRI of the SFPR.		Figure 6 shows the Route Type specific NLRI of the SFPR.
	+-----------------------------------------------+		+-----------------------------------------------+
	| Route Distinguisher (RD) (8 octets) |		| Route Distinguisher (RD) (8 octets) |
	+-----------------------------------------------+		+-----------------------------------------------+
	skipping to change at page 15, line 37 ¶		skipping to change at page 15, line 37 ¶
	one value is defined in this document: type 1 indicates		one value is defined in this document: type 1 indicates
	association of two unidirectional SFPs to form a bidirectional		association of two unidirectional SFPs to form a bidirectional
	SFP. An SFP attribute SHOULD NOT contain more than one		SFP. An SFP attribute SHOULD NOT contain more than one
	Association TLV with Association Type 1: if more than one is		Association TLV with Association Type 1: if more than one is
	present, the first one MUST be processed and subsequent instances		present, the first one MUST be processed and subsequent instances
	MUST be ignored. Note that documents that define new Association		MUST be ignored. Note that documents that define new Association
	Types must also define the presence rules for Association TLVs of		Types must also define the presence rules for Association TLVs of
	the new type.		the new type.
	The Associated SFPR-RD contains the RD of the associated SFP as		The Associated SFPR-RD contains the RD of the associated SFP as
	advertized in an SFPR.		advertised in an SFPR.
	The Associated SPI contains the SPI of the associated SFP as		The Associated SPI contains the SPI of the associated SFP as
	advertised in an SFPR.		advertised in an SFPR.
	Association TLVs with unknown Association Type values SHOULD be		Association TLVs with unknown Association Type values SHOULD be
	ignored. Association TLVs that contain an Associated SFPR-RD value		ignored. Association TLVs that contain an Associated SFPR-RD value
	equal to the RD of the SFPR in which they are contained SHOULD be		equal to the RD of the SFPR in which they are contained SHOULD be
	ignored. If the Associated SPI is not equal to the SPI advertised in		ignored. If the Associated SPI is not equal to the SPI advertised in
	the SFPR indicated by the Associated SFPR-RD then the Association TLV		the SFPR indicated by the Associated SFPR-RD then the Association TLV
	SHOULD be ignored.		SHOULD be ignored.
	skipping to change at page 18, line 21 ¶		skipping to change at page 18, line 21 ¶
	current hop is to use an {SFC Context Label, SF label} rather than an		current hop is to use an {SFC Context Label, SF label} rather than an
	{SPI, SF} label pair. See Section 7.7 for more details.		{SPI, SF} label pair. See Section 7.7 for more details.
	3.2.1.5. SFP Traversal With MPLS Label Stack TLV		3.2.1.5. SFP Traversal With MPLS Label Stack TLV
	The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero		The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
	length sub-TLV that can be carried in the SFP Attribute and indicates		length sub-TLV that can be carried in the SFP Attribute and indicates
	to the Classifier and the SFFs on the SFP that an MPLS labels stack		to the Classifier and the SFFs on the SFP that an MPLS labels stack
	with label swapping/stacking is to be used for packets traversing the		with label swapping/stacking is to be used for packets traversing the
	SFP. All of the SFF specified at each the SFP's hops must have		SFP. All of the SFF specified at each the SFP's hops must have
	advertised an SPI/SI Representation sub-TLV (see Section 7.6) with		advertised an MPLS Mixed Swapping/Stacking Extended Community (see
	bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered		Section 3.1.2) for the SFP to be considered usable.
	usable.
	3.2.2. General Rules For The SFP Attribute		3.2.2. General Rules For The SFP Attribute
	It is possible for the same SFI, as described by an SFIR, to be used		It is possible for the same SFI, as described by an SFIR, to be used
	in multiple SFPRs.		in multiple SFPRs.
	When two SFPRs have the same SPI but different SFPR-RDs there can be		When two SFPRs have the same SPI but different SFPR-RDs there can be
	three cases:		three cases:
	o Two or more Controllers are originating SFPRs for the same SFP.		o Two or more Controllers are originating SFPRs for the same SFP.
	skipping to change at page 23, line 11 ¶		skipping to change at page 23, line 11 ¶
	The installed forwarding state may change over time reacting to		The installed forwarding state may change over time reacting to
	changes in the underlay network and the availability of particular		changes in the underlay network and the availability of particular
	SFIs.		SFIs.
	Note that SFFs only create and store forwarding state for the SFPs on		Note that SFFs only create and store forwarding state for the SFPs on
	which they are included. They do not retain state for all SFPs		which they are included. They do not retain state for all SFPs
	advertised.		advertised.
	An SFF may also install forwarding state to support looping, jumping,		An SFF may also install forwarding state to support looping, jumping,
	and branching. The protocol mechanism for explicit control of		and branching. The protocol mechanism for explicit control of
	looping, jumping, and branching uses a specific resereved SFT value		looping, jumping, and branching uses a specific reserved SFT value
	at a given hop of an SFPR and is described in Section 6.1.		at a given hop of an SFPR and is described in Section 6.1.
	4.5.1. Processing With 'Gaps' in the SI Sequence		4.5.1. Processing With 'Gaps' in the SI Sequence
	The behavior of an SF as described in [RFC8300] is to decrement the		The behavior of an SF as described in [RFC8300] is to decrement the
	value of the SI field in the NSH by one before returning a packet to		value of the SI field in the NSH by one before returning a packet to
	the local SFF for further processing. This means that there is a		the local SFF for further processing. This means that there is a
	good reason to assume that the SFP is composed of a series of SFs		good reason to assume that the SFP is composed of a series of SFs
	each indicated by an SI value one less than the previous.		each indicated by an SI value one less than the previous.
	skipping to change at page 33, line 31 ¶		skipping to change at page 33, line 31 ¶
	and processing instructions to achieve the semantics of a logical		and processing instructions to achieve the semantics of a logical
	NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc].		NSH. The label stack is encoded as shown in [I-D.ietf-mpls-sfc].
	7.7. MPLS Label Swapping/Stacking Operation		7.7. MPLS Label Swapping/Stacking Operation
	When a classifier constructs an MPLS label stack for an SFP it starts		When a classifier constructs an MPLS label stack for an SFP it starts
	with that SFP' last hop. If the last hop requires an {SPI, SI} label		with that SFP' last hop. If the last hop requires an {SPI, SI} label
	pair for label swapping, it pushes the SI (set to the SI value of the		pair for label swapping, it pushes the SI (set to the SI value of the
	last hop) and the SFP's SPI onto the MPLS label stack. If the last		last hop) and the SFP's SPI onto the MPLS label stack. If the last
	hop requires a {context label, SFI label} label pair for label		hop requires a {context label, SFI label} label pair for label
	stcking it selects a specific SFIR and pushes that SFIR's SFI label		stacking it selects a specific SFIR and pushes that SFIR's SFI label
	and context label onto the MPLS label stack.		and context label onto the MPLS label stack.
	The classifier then moves sequentially back through the SFP one hop		The classifier then moves sequentially back through the SFP one hop
	at a time. For each hop, if the hop requires an {SPI, SI]} and there		at a time. For each hop, if the hop requires an {SPI, SI]} and there
	is an {SPI, SI} at the top of the MPLS label stack, the SI is set to		is an {SPI, SI} at the top of the MPLS label stack, the SI is set to
	the SI value of the current hop. If there is not an {SPI, SI} at the		the SI value of the current hop. If there is not an {SPI, SI} at the
	top of the MPLS label stack, it pushes the SI (set to the SI value of		top of the MPLS label stack, it pushes the SI (set to the SI value of
	the current hop) and the SFP's SPI onto the MPLS label stack.		the current hop) and the SFP's SPI onto the MPLS label stack.
	If the hop requires a {context label, SFI label}, it selects a		If the hop requires a {context label, SFI label}, it selects a
	specific SFIR and pushes that SFIR's SFI label and context label onto		specific SFIR and pushes that SFIR's SFI label and context label onto
	the MPLS label stack.		the MPLS label stack.
			7.8. Support for MPLS-Encapsulated NSH Packets
			[I-D.ietf-mpls-sfc-encapsulation] describes how to transport SFC
			packets using the NSH over an MPLS transport network. Signaling MPLS
			encapsulation of SFC packets using the NSH is also supported by this
			document by using the "BGP Tunnel Encapsulation Attribute Sub-TLV"
			with the codepoint 10 (representing "MPLS Label Stack") from the "BGP
			Tunnel Encapsulation Attribute Sub-TLVs" registry defined in
			[I-D.ietf-idr-tunnel-encaps], and also using the "SFP Traversal With
			MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" with
			bit 0 set and bit 1 cleared.
			In this case the MPLS label stack constructed by the SFF to forward a
			packet to the next SFF on the SFP will consist of the labels needed
			to reach that SFF, and if label stacking is used it will also include
			the labels advertised in the MPLS Label Stack sub-TLV and the labels
			remaining in the stack needed to traverse the remainder of the SFP.
	8. Examples		8. Examples
	Assume we have a service function overlay network with four SFFs		Assume we have a service function overlay network with four SFFs
	(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the		(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the
	underlay network as follows:		underlay network as follows:
	SFF1 192.0.2.1		SFF1 192.0.2.1
	SFF2 192.0.2.2		SFF2 192.0.2.2
	SFF3 192.0.2.3		SFF3 192.0.2.3
	SFF4 192.0.2.4		SFF4 192.0.2.4
	skipping to change at page 51, line 37 ¶		skipping to change at page 52, line 37 ¶
	Email: keyur@arrcus.com		Email: keyur@arrcus.com
	Avinash Lingala		Avinash Lingala
	AT&T		AT&T
	Email: ar977m@att.com		Email: ar977m@att.com
	12. Acknowledgements		12. Acknowledgements
	Thanks to Tony Przygienda for helpful comments, and to Joel Halpern		Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful
	for discussions that improved this document. Yuanlong Jiang provided		comments, and to Joel Halpern for discussions that improved this
	a useful review and caught some important issues.		document. Yuanlong Jiang provided a useful review and caught some
			important issues.
			Andy Malis contributed text that formed the basis of Section 7.8.
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-idr-tunnel-encaps]		[I-D.ietf-idr-tunnel-encaps]
	Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel		Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
	Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-10		Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-11
	(work in progress), August 2018.		(work in progress), February 2019.
	[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>.
	skipping to change at page 52, line 48 ¶		skipping to change at page 54, line 8 ¶
	[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300,		"Network Service Header (NSH)", RFC 8300,
	DOI 10.17487/RFC8300, January 2018,		DOI 10.17487/RFC8300, January 2018,
	<https://www.rfc-editor.org/info/rfc8300>.		<https://www.rfc-editor.org/info/rfc8300>.
	13.2. Informative References		13.2. Informative References
	[I-D.ietf-mpls-sfc]		[I-D.ietf-mpls-sfc]
	Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based		Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
	Forwarding Plane for Service Function Chaining", draft-		Forwarding Plane for Service Function Chaining", draft-
	ietf-mpls-sfc-04 (work in progress), November 2018.		ietf-mpls-sfc-05 (work in progress), February 2019.
			[I-D.ietf-mpls-sfc-encapsulation]
			Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
			"MPLS Encapsulation For The SFC NSH", draft-ietf-mpls-sfc-
			encapsulation-02 (work in progress), December 2018.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.		<https://www.rfc-editor.org/info/rfc6790>.
	[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for		[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
	Service Function Chaining", RFC 7498,		Service Function Chaining", RFC 7498,
	DOI 10.17487/RFC7498, April 2015,		DOI 10.17487/RFC7498, April 2015,
	<https://www.rfc-editor.org/info/rfc7498>.		<https://www.rfc-editor.org/info/rfc7498>.
End of changes. 21 change blocks.
	44 lines changed or deleted		74 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/