draft-ietf-bess-nsh-bgp-control-plane-03.txt		draft-ietf-bess-nsh-bgp-control-plane-04.txt
	BESS Working Group A. Farrel		BESS Working Group A. Farrel
	Internet-Draft J. Drake		Internet-Draft J. Drake
	Intended status: Standards Track E. Rosen		Intended status: Standards Track E. Rosen
	Expires: September 19, 2018 Juniper Networks		Expires: January 2, 2019 Juniper Networks
	J. Uttaro		J. Uttaro
	AT&T		AT&T
	L. Jalil		L. Jalil
	Verizon		Verizon
	March 18, 2018		July 1, 2018
	BGP Control Plane for NSH SFC		BGP Control Plane for NSH SFC
	draft-ietf-bess-nsh-bgp-control-plane-03		draft-ietf-bess-nsh-bgp-control-plane-04
	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 47 ¶		skipping to change at page 1, line 47 ¶
	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 September 19, 2018.		This Internet-Draft will expire on January 2, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5		2.1. Functional Overview . . . . . . . . . . . . . . . . . . . 5
	2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7		2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 7
	3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9		3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10		3.1. Service Function Instance Route (SFIR) . . . . . . . . . 10
	3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11		3.1.1. SFI Pool Identifier Extended Community . . . . . . . 11
	3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12		3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 12
	3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13		3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 13
	3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13		3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 13
	3.2.2. General Rules For The SFP Attribute . . . . . . . . . 18		3.2.2. General Rules For The SFP Attribute . . . . . . . . . 19
	4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 19		4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 20
	4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 19		4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 20
	4.2. Service Function Instance Routes . . . . . . . . . . . . 19		4.2. Service Function Instance Routes . . . . . . . . . . . . 20
	4.3. Service Function Path Routes . . . . . . . . . . . . . . 19		4.3. Service Function Path Routes . . . . . . . . . . . . . . 21
	4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 21		4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 23
	4.5. Service Function Forwarder Operation . . . . . . . . . . 22		4.5. Service Function Forwarder Operation . . . . . . . . . . 23
	4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 23		4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 24
	5. Selection in Service Function Paths . . . . . . . . . . . . . 24		5. Selection in Service Function Paths . . . . . . . . . . . . . 25
	6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 26		6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 27
	6.1. Protocol Control of Looping, Jumping, and Branching . . . 26		6.1. Protocol Control of Looping, Jumping, and Branching . . . 27
	6.2. Implications for Forwarding State . . . . . . . . . . . . 27		6.2. Implications for Forwarding State . . . . . . . . . . . . 28
	7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 27		7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 27		7.1. Preserving Entropy . . . . . . . . . . . . . . . . . . . 29
	7.2. Correlating Service Function Path Instances . . . . . . . 28		7.2. Correlating Service Function Path Instances . . . . . . . 29
	7.3. Considerations for Stateful Service Functions . . . . . . 29		7.3. Considerations for Stateful Service Functions . . . . . . 30
	7.4. VPN Considerations and Private Service Functions . . . . 30		7.4. VPN Considerations and Private Service Functions . . . . 31
	7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 30		7.5. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 31
	7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 32		7.6. Choice of Data Plane SPI/SI Representation . . . . . . . 33
	7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 33		7.6.1. MPLS Representation of the SPI/SI . . . . . . . . . . 34
	7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 33		7.7. MPLS Label Swapping/Stacking Operation . . . . . . . . . 34
	8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 33		8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	8.1. Example Explicit SFP With No Choices . . . . . . . . . . 35		8.1. Example Explicit SFP With No Choices . . . . . . . . . . 36
	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 . . . . . . . . . . . . . 36		8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 38
	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 . . . 39
	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 . . . . 41
	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 . . . . . . . . . . . 51
	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 . . . . . . 52
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 53
	13.1. Normative References . . . . . . . . . . . . . . . . . . 51		13.1. Normative References . . . . . . . . . . . . . . . . . . 53
	13.2. Informative References . . . . . . . . . . . . . . . . . 52		13.2. Informative References . . . . . . . . . . . . . . . . . 54
	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 39 ¶		skipping to change at page 11, line 39 ¶
	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.
	3.1.1. SFI Pool Identifier Extended Community		3.1.1. SFI Pool Identifier Extended Community
	This document defines a new transitive extended community with Sub-		This document defines a new transitive extended community with Sub-
	Type TBD6 called the SFI Pool Identifier. It can be included in SFIR		Type TBD6 called the SFI Pool Identifier extended community. It can
	advertisements, and is used to indicate the identity of a pool of		be included in SFIR advertisements, and is used to indicate the
	SFIRs to which an SFIR belongs. Since an SFIR may be a member of		identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR
	multiple pools, multiple of these extended communities may be present		may be a member of multiple pools, multiple of these extended
	on a single SFIR advertisement.		communities may be present on a single SFIR advertisement.
	SFIR pools allow SFIRs to be grouped for any purpose. Possible uses		SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
	include control plane scalability and stability.		include control plane scalability and stability.
	The SFI Pool Identifier is encoded as an 8 octet value as shown in		The SFI Pool Identifier extended community is encoded in 8 octets as
	Figure 4.		shown in Figure 4.
	+--------------------------------------------+		+--------------------------------------------+
	| Type = 0x80 (1 octet) |		| Type = 0x80 (1 octet) |
	+--------------------------------------------|		+--------------------------------------------+
	| Sub-Type = TBD6 (1 octet) |		| Sub-Type = TBD6 (1 octet) |
	+--------------------------------------------|		+--------------------------------------------+
	| SPI Pool Identifier (6 octets) |		| SFI Pool Identifier (6 octets) |
	+--------------------------------------------|		+--------------------------------------------+
	Figure 4: The SFI Pool Identifier		Figure 4: The SFI Pool Identifier Extended Community
	The SFI Pool Identifier is a six octet, globally unique value encoded		The SFI Pool Identifier is encoded in a 6 octet field in network
	in network byte order.		byte order and is a globally unique value.
	3.1.2. MPLS Mixed Swapping/Stacking Extended Community		3.1.2. MPLS Mixed Swapping/Stacking Extended Community
	This document defines a new transitive extended community with Sub-		This document defines a new transitive extended community with Sub-
	Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The		Type TBD7 called the MPLS Mixed Swapping/Stacking Labels. The
	community is encoded as shown in Figure 5. It contains a pair of		community is encoded as shown in Figure 5. It contains a pair of
	MPLS labels: an SFC Context Label and an SF Label as described in		MPLS labels: an SFC Context Label and an SF Label as described in
	[I-D.farrel-mpls-sfc]. Each label is 20 bits encoded in a 3-octet		[I-D.ietf-mpls-sfc]. Each label is 20 bits encoded in a 3-octet (24
	(24 bit) field with 4 trailing bits that MUST be set to zero.		bit) field with 4 trailing bits that MUST be set to zero.
	+--------------------------------------------+		+--------------------------------------------+
	| 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) |
	+--------------------------------------------+		+--------------------------------------------+
	skipping to change at page 16, line 42 ¶		skipping to change at page 16, line 42 ¶
	Type is set to 2 to indicate a Hop TLV.		Type is set to 2 to indicate a Hop TLV.
	Length indicates the length in octets of the Service Index and Hop		Length indicates the length in octets of the Service Index and Hop
	Details fields.		Details fields.
	The Service Index is defined in [RFC8300] and is the value found		The Service Index is defined in [RFC8300] and is the value found
	in the Service Index field of the NSH header that an SFF will use		in the Service Index field of the NSH header that an SFF will use
	to lookup to which next SFI a packet should be sent.		to lookup to which next SFI a packet should be sent.
	The Hop Details consist of a sequence of one or more SFT TLVs.		The Hop Details field consists of a sequence of one or more sub-
			TLVs. These may be SFT-SFI TLVs and SFT-Pool TLVs.
	3.2.1.3. The SFT TLV		Each hop of the SFP may demand that a specific type of SF is
			executed, and that type is indicated in sub-TLVs of the Hop TLV. At
			least one sub-TLV MUST be present, and the list of sub-TLVs may
			include SFT-SFI and SFT-Pool TLVs as described in the following
			sections. This provides a list of which types of SF are acceptable
			at a specific hop, and for each type it allow a degree of control to
			be imposed on the choice of SFIs of that particular type.
	There is one or more SFT TLV in each Hop TLV. There is one SFT TLV		3.2.1.3. The SFT-SFI TLV
	for each SFT supported in the specific hop of the SFP. The format of
	the SFT TLV is shown in Figure 9.		The SFT-SFI TLV MAY be included in the list of sub-TLVs of the Hop
			TLV. The format of the SFT-SFI TLV is shown in Figure 9. The TLV
			contains a list of SFIR-RD values each taken from the advertisement
			of an SFI. Together they form a list of acceptable SFIs of the
			indicated type.
	+--------------------------------------------+		+--------------------------------------------+
	| Type = 3 (1 octet) |		| Type = 3 (1 octet) |
	+--------------------------------------------|		+--------------------------------------------|
	| Length (2 octets) |		| Length (2 octets) |
	+--------------------------------------------|		+--------------------------------------------|
	| Service Function Type (2 octets) |		| Service Function Type (2 octets) |
	+--------------------------------------------|		+--------------------------------------------|
	| SFIR-RD List (variable) |		| SFIR-RD List (variable) |
	+--------------------------------------------+		+--------------------------------------------+
	Figure 9: The Format of the SFT TLV		Figure 9: The Format of the SFT-SFI TLV
	The fields are as follows:		The fields are as follows:
	Type is set to 3 to indicate an SFT TLV.		Type is set to 3 to indicate an SFT TLV.
	Length indicates the length in octets of the Service Function Type		Length indicates the length in octets of the Service Function Type
	and SFIR-RD List fields.		and SFIR-RD List fields.
	The Service Function Type is used to identify a Service Function		The Service Function Type value indicates the category (type) of
	Instance Route in the service function overlay network which, in		SF that is to be executed at this hop. The types are as
	turn, will allow lookup of routes to SFIs implementing the SF.		advertised for the SFs supported by the SFFs SFT values in the
	SFT values in the range 1-31 are Special Purpose SFT values and		range 1-31 are Special Purpose SFT values and have meanings
	have meanings defined by the documents that describe them - the		defined by the documents that describe them - the value 'Change
	value 'Change Sequence' is defined in Section 6.1 of this		Sequence' is defined in Section 6.1 of this document.
	document.
	The SFIR-RD List is made up of one or more SFIR-RD or SPI Pool		The hop description is further qualified beyond the specification
	Identifiers obtained from the advertisements of SFIs in SFIRs. An		of the SFTs by listing, for each SFT in each hop, the SFIs that
	SFIR-RD of value zero has special meaning as described in		may be used at the hop. The SFIs are identified using the SFIR-
	Section 5. Note that If the list contains one or more SPI Pool		RDs from the advertisements of the SFIs in the SFIRs. An SFIR-RD
	Identifiers, then for each the SFIR-RD list is effectively		of value zero has special meaning as described in Section 5. Each
	expanded to include the SFIR-RD of each SFIR advertised with that		entry in the list is 8 octets long, and the number of entries in
	SPI Pool Identifier. Each entry in the list is 8 octets long, and		the list can be deduced from the value of the Length field.
	the number of entries in the list can be deduced from the value of
	the Length field.
	3.2.1.4. MPLS Swapping/Stacking TLV		3.2.1.4. The SFT-Pool TLV
	The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub-		The SFT-Pool TLV MAY be included in the list of sub-TLVs of the Hop
			TLV. The format of the SFT-Pool TLV is shown in Figure 10. The TLV
			contains a list of SFI Pool Identifier values each taken from the
			advertisement of an SFI. Together they form a list of pools of
			acceptable SFIs of the indicated type.
			+--------------------------------------------+
			| Type = 4 (1 octet) |
			+--------------------------------------------|
			| Length (2 octets) |
			+--------------------------------------------|
			| Service Function Type (2 octets) |
			+--------------------------------------------|
			| SFI Pool List (variable) |
			+--------------------------------------------+
			Figure 10: The Format of the SFT TLV
			The fields are as follows:
			Type is set to 4 to indicate an SFT TLV.
			Length indicates the length in octets of the Service Function Type
			and SFIR-RD List fields.
			The Service Function Type value indicates the category (type) of
			SF that is to be executed at this hop. The types are as
			advertised for the SFs supported by the SFFs SFT values in the
			range 1-31 are Special Purpose SFT values and have meanings
			defined by the documents that describe them - the value 'Change
			Sequence' is defined in Section 6.1 of this document.
			The hop description is further qualified beyond the specification
			of the SFTs by listing, for each SFT in each hop, the SFI Pool
			Identifiers that may be used at the hop. The SFI pools are
			identified using SFI Pool Identifiers from the advertisements of
			the SFIs in the SFIRs. Each entry in the list is 6 octets long,
			and the number of entries in the list can be deduced from the
			value of the Length field.
			3.2.1.5. MPLS Swapping/Stacking TLV
			The MPLS Swapping/Stacking TLV (Type value 5) is a zero length sub-
	TLV that can be carried in the Hop TLV and is used when the data		TLV that can be carried in the Hop TLV and is used when the data
	representation is MPLS (see Section 7.6). It indicates to the		representation is MPLS (see Section 7.6). It indicates to the
	Classifier that imposes an MPLS label stack whether the current hop		Classifier that imposes an MPLS label stack whether the current hop
	is to use an {SPI, SI} label pair for label swapping or a {Context		is to use an {SPI, SI} label pair for label swapping or a {Context
	label, SF label}. See Section 7.7 for more details.		label, SF label}. See Section 7.7 for more details.
	3.2.1.5. SFP Traversal With MPLS Label Stack TLV		3.2.1.6. 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 6) 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 SPI/SI Representation sub-TLV (see Section 7.6) with
	bit 0 set to 0 and bit 1 set to 1 for the SFP to be considered		bit 0 set to 0 and bit 1 set to 1 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
	skipping to change at page 21, line 29 ¶		skipping to change at page 22, line 42 ¶
	SFIR-RD: The Route Descriptor used in an advertisement of the		SFIR-RD: The Route Descriptor used in an advertisement of the
	Service Function Instance Route		Service Function Instance Route
	Note that the values of SI are from the set {255, ..., 1} and are		Note that the values of SI are from the set {255, ..., 1} and are
	monotonically decreasing within the SFP. SIs MUST appear in order		monotonically decreasing within the SFP. SIs MUST appear in order
	within the SFPR (i.e., monotonically decreasing) and MUST NOT appear		within the SFPR (i.e., monotonically decreasing) and MUST NOT appear
	more than once. Gaps MAY appear in the sequence as described in		more than once. Gaps MAY appear in the sequence as described in
	Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any		Section 4.5.1. Malformed SFPRs MUST be discarded and MUST cause any
	previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.		previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.
	Note that if the SFIR-RD list in an SFT TLV contains one or more SPI		Note that if the SFIR-RD list in an SFT TLV contains one or more SFI
	Pool identifiers, then in the above expression, 'p' is the sum of the		Pool identifiers, then in the above expression, 'p' is the sum of the
	number of individual SFIR-RD values and the sum for each SPI Pool		number of individual SFIR-RD values and the sum for each SFI Pool
	Identifier of the number of SFIRs advertised with that SPI Pool		Identifier of the number of SFIRs advertised with that SFI Pool
	Identifier. I.e., the list of SFIR-RD values is effectively expanded		Identifier. I.e., the list of SFIR-RD values is effectively expanded
	to include the SFIR-RD of each SFIR advertised with each SPI Pool		to include the SFIR-RD of each SFIR advertised with each SFI Pool
	Identifier in the SFRIR-RD list.		Identifier in the SFIR-RD list.
	The choice of SFI is explained further in Section 5. Note that an		The choice of SFI is explained further in Section 5. Note that an
	SFIR-RD value of zero has special meaning as described in that		SFIR-RD value of zero has special meaning as described in that
	Section.		Section.
	4.4. Classifier Operation		4.4. Classifier Operation
	As shown in Figure 1, the Classifier is a special Service Function		As shown in Figure 1, the Classifier is a special Service Function
	that is used to assign packets to an SFP.		that is used to assign packets to an SFP.
	skipping to change at page 26, line 7 ¶		skipping to change at page 27, line 14 ¶
	that SFI. For a particular packet, the SFF chooses a particular SFI		that SFI. For a particular packet, the SFF chooses a particular SFI
	from the set of relevant SFIRs. This choice is made according to		from the set of relevant SFIRs. This choice is made according to
	local policy.		local policy.
	A typical policy might be to figure out the set of SFIs that are		A typical policy might be to figure out the set of SFIs that are
	closest, and to load balance among them. But this is not the only		closest, and to load balance among them. But this is not the only
	possible policy.		possible policy.
	6. Looping, Jumping, and Branching		6. Looping, Jumping, and Branching
	As described in Section 2 an SFI or an SFF may cause a packets to		As described in Section 2 an SFI or an SFF may cause a packet to
	"loop back" to a previous SF on a path in order that a sequence of		"loop back" to a previous SF on a path in order that a sequence of
	functions may be re-executed. This is simply achieved by replacing		functions may be re-executed. This is simply achieved by replacing
	the SI in the NSH with a higher value instead of decreasing it as		the SI in the NSH with a higher value instead of decreasing it as
	would normally be the case to determine the next hop in the path.		would normally be the case to determine the next hop in the path.
	Section 2 also describes how an SFI or an SFF may cause a packets to		Section 2 also describes how an SFI or an SFF may cause a packets to
	"jump forward" to an SF on a path that is not the immediate next SF		"jump forward" to an SF on a path that is not the immediate next SF
	in the SFP. This is simply achieved by replacing the SI in the NSH		in the SFP. This is simply achieved by replacing the SI in the NSH
	with a lower value than would be achieved by decreasing it by the		with a lower value than would be achieved by decreasing it by the
	normal amount.		normal amount.
	skipping to change at page 30, line 41 ¶		skipping to change at page 32, line 6 ¶
	[RFC5575] defines a set of BGP routes that can be used to identify		[RFC5575] defines a set of BGP routes that can be used to identify
	the packets in a given flow using fields in the header of each		the packets in a given flow using fields in the header of each
	packet, and a set of actions, encoded as extended communities, that		packet, and a set of actions, encoded as extended communities, that
	can be used to disposition those packets. This document enables the		can be used to disposition those packets. This document enables the
	use of RFC 5575 mechanisms by SFC Classifiers by defining a new		use of RFC 5575 mechanisms by SFC Classifiers by defining a new
	action extended community called "Flow Spec for SFC classifiers"		action extended community called "Flow Spec for SFC classifiers"
	identified by the value TBD4. Note that other action extended		identified by the value TBD4. Note that other action extended
	communities may also be present.		communities may also be present.
	This extended community is encoded as an 8-octet value, as shown in		This extended community is encoded as an 8-octet value, as shown in
	Figure 10:		Figure 11:
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type=0x80 | Sub-Type=TBD4 | SPI |		| Type=0x80 | Sub-Type=TBD4 | SPI |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SPI (cont.) | SI | SFT |		| SPI (cont.) | SI | SFT |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: The Format of the Flow Spec for SFC Classifiers Extended		Figure 11: The Format of the Flow Spec for SFC Classifiers Extended
	Community		Community
	The extended community contains the Service Path Identifier (SPI),		The extended community contains the Service Path Identifier (SPI),
	Service Index (SI), and Service Function Type (SFT) as defined		Service Index (SI), and Service Function Type (SFT) as defined
	elsewhere in this document. Thus, each action extended community		elsewhere in this document. Thus, each action extended community
	defines the entry point (not necessarily the first hop) into a		defines the entry point (not necessarily the first hop) into a
	specific service function path. This allows, for example, different		specific service function path. This allows, for example, different
	flows to enter the same service function path at different points.		flows to enter the same service function path at different points.
	Note that a given Flow Spec update according to [RFC5575] may include		Note that a given Flow Spec update according to [RFC5575] may include
	skipping to change at page 32, line 13 ¶		skipping to change at page 33, line 17 ¶
	as indicated in the SPFR for the indicated SPI MUST be used.		as indicated in the SPFR for the indicated SPI MUST be used.
	7.6. Choice of Data Plane SPI/SI Representation		7.6. Choice of Data Plane SPI/SI Representation
	This document ties together the control and data planes of an SFC		This document ties together the control and data planes of an SFC
	overlay network through the use of the SPI/SI which is nominally		overlay network through the use of the SPI/SI which is nominally
	carried in the NSH of a given packet. However, in order to handle		carried in the NSH of a given packet. However, in order to handle
	situations in which the NSH is not ubiquitously deployed, it is also		situations in which the NSH is not ubiquitously deployed, it is also
	possible to use alternative data plane representations of the SPI/SI		possible to use alternative data plane representations of the SPI/SI
	by carrying the identical semantics in other protocol fields such as		by carrying the identical semantics in other protocol fields such as
	MPLS labels [I-D.farrel-mpls-sfc].		MPLS labels [I-D.ietf-mpls-sfc].
	This document defines a new sub-TLV for the Tunnel Encapsulation		This document defines a new sub-TLV for the Tunnel Encapsulation
	attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub-		attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub-
	TLV MAY be present in each Tunnel TLV contained in a Tunnel		TLV MAY be present in each Tunnel TLV contained in a Tunnel
	Encapsulation attribute when the attribute is carried by an SFIR.		Encapsulation attribute when the attribute is carried by an SFIR.
	The value field of this sub-TLV is a two octet field of flags, each		The value field of this sub-TLV is a two octet field of flags, each
	of which describes how the originating SFF expects to see the SPI/SI		of which describes how the originating SFF expects to see the SPI/SI
	represented in the data plane for packets carried in the tunnels		represented in the data plane for packets carried in the tunnels
	described by the Tunnel TLV.		described by the Tunnel TLV.
	skipping to change at page 33, line 15 ¶		skipping to change at page 34, line 22 ¶
	NSH itself). It is a requirement that both ends of a tunnel over the		NSH itself). It is a requirement that both ends of a tunnel over the
	underlay network know that the tunnel is used for SFC and know what		underlay network know that the tunnel is used for SFC and know what
	form of NSH representation is used. The signaling mechanism		form of NSH representation is used. The signaling mechanism
	described here allows coordination of this information.		described here allows coordination of this information.
	7.6.1. MPLS Representation of the SPI/SI		7.6.1. MPLS Representation of the SPI/SI
	If bit 1 is set in the in the SPI/SI Representation sub-TLV then		If bit 1 is set in the in the SPI/SI Representation sub-TLV then
	labels in the MPLS label stack are used to indicate SFC forwarding		labels in the MPLS label stack are used to indicate SFC forwarding
	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.farrel-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		stcking 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.
	skipping to change at page 34, line 16 ¶		skipping to change at page 35, line 21 ¶
	Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows:		Types SFT=41, SFT=42, SFT=43, and SFT=44 as follows:
	SFF1 SFT=41 and SFT=42		SFF1 SFT=41 and SFT=42
	SFF2 SFT=41 and SFT=43		SFF2 SFT=41 and SFT=43
	SFF3 SFT=42 and SFT=44		SFF3 SFT=42 and SFT=44
	SFF4 SFT=43 and SFT=44		SFF4 SFT=43 and SFT=44
	The service function network also contains a Controller with address		The service function network also contains a Controller with address
	198.51.100.1.		198.51.100.1.
	This example service function overlay network is shown in Figure 11.		This example service function overlay network is shown in Figure 12.
	--------------		--------------
	| Controller |		| Controller |
	| 198.51.100.1 | ------ ------ ------ ------		| 198.51.100.1 | ------ ------ ------ ------
	-------------- | SFI | | SFI | | SFI | | SFI |		-------------- | SFI | | SFI | | SFI | | SFI |
	|SFT=41| |SFT=42| |SFT=41| |SFT=43|		|SFT=41| |SFT=42| |SFT=41| |SFT=43|
	------ ------ ------ ------		------ ------ ------ ------
	\ / \ /		\ / \ /
	--------- ---------		--------- ---------
	---------- | SFF1 | | SFF2 |		---------- | SFF1 | | SFF2 |
	skipping to change at page 34, line 40 ¶		skipping to change at page 35, line 45 ¶
	---------- --------- ---------		---------- --------- ---------
	| SFF3 | | SFF4 |		| SFF3 | | SFF4 |
	|192.0.2.3| |192.0.2.4|		|192.0.2.3| |192.0.2.4|
	--------- ---------		--------- ---------
	/ \ / \		/ \ / \
	------ ------ ------ ------		------ ------ ------ ------
	| SFI | | SFI | | SFI | | SFI |		| SFI | | SFI | | SFI | | SFI |
	|SFT=42| |SFT=44| |SFT=43| |SFT=44|		|SFT=42| |SFT=44| |SFT=43| |SFT=44|
	------ ------ ------ ------		------ ------ ------ ------
	Figure 11: Example Service Function Overlay Network		Figure 12: Example Service Function Overlay Network
	The SFFs advertise routes to the SFIs they support. So we see the		The SFFs advertise routes to the SFIs they support. So we see the
	following SFIRs:		following SFIRs:
	RD = 192.0.2.1,1, SFT = 41		RD = 192.0.2.1,1, SFT = 41
	RD = 192.0.2.1,2, SFT = 42		RD = 192.0.2.1,2, SFT = 42
	RD = 192.0.2.2,1, SFT = 41		RD = 192.0.2.2,1, SFT = 41
	RD = 192.0.2.2,2, SFT = 43		RD = 192.0.2.2,2, SFT = 43
	RD = 192.0.2.3,7, SFT = 42		RD = 192.0.2.3,7, SFT = 42
	RD = 192.0.2.3,8, SFT = 44		RD = 192.0.2.3,8, SFT = 44
	skipping to change at page 40, line 15 ¶		skipping to change at page 41, line 15 ¶
	8.9. Examples of SFPs with Stateful Service Functions		8.9. Examples of SFPs with Stateful Service Functions
	This section provides some examples to demonstrate establishing SFPs		This section provides some examples to demonstrate establishing SFPs
	when there is a choice of service functions at a particular hop, and		when there is a choice of service functions at a particular hop, and
	where consistency of choice is required in both directions. The		where consistency of choice is required in both directions. The
	scenarios that give rise to this requirement are discussed in		scenarios that give rise to this requirement are discussed in
	Section 7.3.		Section 7.3.
	8.9.1. Forward and Reverse Choice Made at the SFF		8.9.1. Forward and Reverse Choice Made at the SFF
	Consider the topology shown in Figure 12. There are three SFFs		Consider the topology shown in Figure 13. There are three SFFs
	arranged neatly in a line, and the middle one (SFF2) supports three		arranged neatly in a line, and the middle one (SFF2) supports three
	SFIs all of SFT 42. These three instances can be used by SFF2 to		SFIs all of SFT 42. These three instances can be used by SFF2 to
	load balance so that no one instance is swamped.		load balance so that no one instance is swamped.
	------ ------ ------ ------ ------		------ ------ ------ ------ ------
	| SFI | | SFIa | | SFIb | | SFIc | | SFI |		| SFI | | SFIa | | SFIb | | SFIc | | SFI |
	|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|		|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|
	------ ------\ ------ /------ ------		------ ------\ ------ /------ ------
	\ \ | / /		\ \ | / /
	--------- --------- ---------		--------- --------- ---------
	---------- | SFF1 | | SFF2 | | SFF3 |		---------- | SFF1 | | SFF2 | | SFF3 |
	--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->		--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
	--> |Classifier| --------- --------- ---------		--> |Classifier| --------- --------- ---------
	| |		| |
	----------		----------
	Figure 12: Example Where Choice is Made at the SFF		Figure 13: Example Where Choice is Made at the SFF
	This leads to the following SFIRs being advertised.		This leads to the following SFIRs being advertised.
	RD = 192.0.2.1,11, SFT = 41		RD = 192.0.2.1,11, SFT = 41
	RD = 192.0.2.2,11, SFT = 42 (for SFIa)		RD = 192.0.2.2,11, SFT = 42 (for SFIa)
	RD = 192.0.2.2,12, SFT = 42 (for SFIb)		RD = 192.0.2.2,12, SFT = 42 (for SFIb)
	RD = 192.0.2.2,13, SFT = 42 (for SFIc)		RD = 192.0.2.2,13, SFT = 42 (for SFIc)
	RD = 192.0.2.3,11, SFT = 43		RD = 192.0.2.3,11, SFT = 43
	The controller can create a single forward SFP giving SFF2 the choice		The controller can create a single forward SFP giving SFF2 the choice
	skipping to change at page 41, line 38 ¶		skipping to change at page 42, line 38 ¶
	8.9.2. Parallel End-to-End SFPs with Shared SFF		8.9.2. Parallel End-to-End SFPs with Shared SFF
	The mechanism described in Section 8.9.1 might not be desirable		The mechanism described in Section 8.9.1 might not be desirable
	because of the functional assumptions it places on SFF2 to be able to		because of the functional assumptions it places on SFF2 to be able to
	load balance with suitable flow identification, stability, and		load balance with suitable flow identification, stability, and
	equality in both directions. Instead, it may be desirable to place		equality in both directions. Instead, it may be desirable to place
	the responsibility for flow classification in the Classifier and let		the responsibility for flow classification in the Classifier and let
	it determine load balancing with the implied choice of SFIs.		it determine load balancing with the implied choice of SFIs.
	Consider the network graph as shown in Figure 12 and with the same		Consider the network graph as shown in Figure 13 and with the same
	set of SFIRs as listed in Section 8.9.1. In this case the controller		set of SFIRs as listed in Section 8.9.1. In this case the controller
	could specify three forward SFPs with their corresponding associated		could specify three forward SFPs with their corresponding associated
	reverse SFPs. Each bidirectional pair of SFPs uses a different SFI		reverse SFPs. Each bidirectional pair of SFPs uses a different SFI
	for the SF of type 42. The controller can instruct the Classifier		for the SF of type 42. The controller can instruct the Classifier
	how to place traffic on the three bidirectional SFPs, or can treat		how to place traffic on the three bidirectional SFPs, or can treat
	them as a group leaving the Classifier responsible for balancing the		them as a group leaving the Classifier responsible for balancing the
	load.		load.
	SFP14: RD = 198.51.100.1,114, SPI = 28,		SFP14: RD = 198.51.100.1,114, SPI = 28,
	Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31,		Assoc-Type = 1, Assoc-RD = 198.51.100.1,117, Assoc-SPI = 31,
	skipping to change at page 42, line 45 ¶		skipping to change at page 43, line 45 ¶
	SFP19: RD = 198.51.100.1,119, SPI = 33,		SFP19: RD = 198.51.100.1,119, SPI = 33,
	Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30,		Assoc-Type = 1, Assoc-RD = 198.51.100.1,116, Assoc-SPI = 30,
	[SI = 255, SFT = 43, RD = 192.0.2.3,11],		[SI = 255, SFT = 43, RD = 192.0.2.3,11],
	[SI = 254, SFT = 42, RD = 192.0.2.2,13],		[SI = 254, SFT = 42, RD = 192.0.2.2,13],
	[SI = 253, SFT = 41, RD = 192.0.2.1,11]		[SI = 253, SFT = 41, RD = 192.0.2.1,11]
	8.9.3. Parallel End-to-End SFPs with Separate SFFs		8.9.3. Parallel End-to-End SFPs with Separate SFFs
	While the examples in Section 8.9.1 and Section 8.9.2 place the		While the examples in Section 8.9.1 and Section 8.9.2 place the
	choice of SFI as subtended from the same SFF, it is also possible		choice of SFI as subtended from the same SFF, it is also possible
	that the SFIs are ach subtended from a different SFF as shown in		that the SFIs are each subtended from a different SFF as shown in
	Figure 13. In this case it is harder to coordinate the choices for		Figure 14. In this case it is harder to coordinate the choices for
	forward and reverse paths without some form of coordination between		forward and reverse paths without some form of coordination between
	SFF1 and SFF3. Therefore it would be normal to consider end-to-end		SFF1 and SFF3. Therefore it would be normal to consider end-to-end
	parallel SFPs as described in Section 8.9.2.		parallel SFPs as described in Section 8.9.2.
	------		------
	| SFIa |		| SFIa |
	|SFT=42|		|SFT=42|
	------		------
	------ |		------ |
	| SFI | ---------		| SFI | ---------
	skipping to change at page 43, line 34 ¶		skipping to change at page 44, line 34 ¶
	:.---------.:		:.---------.:
	| SFF7 |		| SFF7 |
	|192.0.2.7|		|192.0.2.7|
	---------		---------
	|		|
	------		------
	| SFIc |		| SFIc |
	|SFT=42|		|SFT=42|
	------		------
	Figure 13: Second Example With Parallel End-to-End SFPs		Figure 14: Second Example With Parallel End-to-End SFPs
	In this case, five SFIRs are advertised as follows:		In this case, five SFIRs are advertised as follows:
	RD = 192.0.2.1,11, SFT = 41		RD = 192.0.2.1,11, SFT = 41
	RD = 192.0.2.5,11, SFT = 42 (for SFIa)		RD = 192.0.2.5,11, SFT = 42 (for SFIa)
	RD = 192.0.2.6,11, SFT = 42 (for SFIb)		RD = 192.0.2.6,11, SFT = 42 (for SFIb)
	RD = 192.0.2.7,11, SFT = 42 (for SFIc)		RD = 192.0.2.7,11, SFT = 42 (for SFIc)
	RD = 192.0.2.3,11, SFT = 43		RD = 192.0.2.3,11, SFT = 43
	In this case the controller could specify three forward SFPs with		In this case the controller could specify three forward SFPs with
	skipping to change at page 45, line 6 ¶		skipping to change at page 46, line 6 ¶
	The mechanism of parallel SFPs demonstrated in Section 8.9.3 is		The mechanism of parallel SFPs demonstrated in Section 8.9.3 is
	perfectly functional and may be practical in many environments.		perfectly functional and may be practical in many environments.
	However, there may be scaling concerns because of the large amount of		However, there may be scaling concerns because of the large amount of
	state (knowledge of SFPs, i.e., SFPR advertisements retained) if		state (knowledge of SFPs, i.e., SFPR advertisements retained) if
	there is a very large amount of choice of SFIs (for example, tens of		there is a very large amount of choice of SFIs (for example, tens of
	instances of the same stateful SF), or if there are multiple choices		instances of the same stateful SF), or if there are multiple choices
	of stateful SF along a path. This situation may be mitigated using		of stateful SF along a path. This situation may be mitigated using
	SFP fragments that are combined to form the end to end SFPs.		SFP fragments that are combined to form the end to end SFPs.
	The example presented here is necessarily simplistic, but should		The example presented here is necessarily simplistic, but should
	convey the basic principle. The example presented in Figure 14 is		convey the basic principle. The example presented in Figure 15 is
	similar to that in Section 8.9.3 but with an additional first hop.		similar to that in Section 8.9.3 but with an additional first hop.
	------		------
	| SFIa |		| SFIa |
	|SFT=43|		|SFT=43|
	------		------
	------ ------ |		------ ------ |
	| SFI | | SFI | ---------		| SFI | | SFI | ---------
	|SFT=41| |SFT=42| | SFF5 |		|SFT=41| |SFT=42| | SFF5 |
	------ ------ ..|192.0.2.5|..		------ ------ ..|192.0.2.5|..
	skipping to change at page 45, line 38 ¶		skipping to change at page 46, line 38 ¶
	:.---------.:		:.---------.:
	| SFF7 |		| SFF7 |
	|192.0.2.7|		|192.0.2.7|
	---------		---------
	|		|
	------		------
	| SFIc |		| SFIc |
	|SFT=43|		|SFT=43|
	------		------
	Figure 14: Example With Parallel SFPs Downstream of Choice		Figure 15: Example With Parallel SFPs Downstream of Choice
	The six SFIs are advertised as follows:		The six SFIs are advertised as follows:
	RD = 192.0.2.1,11, SFT = 41		RD = 192.0.2.1,11, SFT = 41
	RD = 192.0.2.2,11, SFT = 42		RD = 192.0.2.2,11, SFT = 42
	RD = 192.0.2.5,11, SFT = 43 (for SFIa)		RD = 192.0.2.5,11, SFT = 43 (for SFIa)
	RD = 192.0.2.6,11, SFT = 43 (for SFIb)		RD = 192.0.2.6,11, SFT = 43 (for SFIb)
	RD = 192.0.2.7,11, SFT = 43 (for SFIc)		RD = 192.0.2.7,11, SFT = 43 (for SFIc)
	RD = 192.0.2.3,11, SFT = 44		RD = 192.0.2.3,11, SFT = 44
	skipping to change at page 49, line 9 ¶		skipping to change at page 50, line 9 ¶
	o Reference Document or Contact		o Reference Document or Contact
	o Registration Date		o Registration Date
	The registry should initially be populated as follows:		The registry should initially be populated as follows:
	Type | Name | Reference | Date		Type | Name | Reference | Date
	------+-------------------------+---------------+---------------		------+-------------------------+---------------+---------------
	1 | Association TLV | [This.I-D] | Date-to-be-set		1 | Association TLV | [This.I-D] | Date-to-be-set
	2 | Hop TLV | [This.I-D] | Date-to-be-set		2 | Hop TLV | [This.I-D] | Date-to-be-set
	3 | SFT TLV | [This.I-D] | Date-to-be-set		3 | SFT-SFI TLV | [This.I-D] | Date-to-be-set
	4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set		4 | SFT-Pool TLV | [This.I-D] | Date-to-be-set
	5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set		5 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set
			6 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set
	10.4. New SFP Association Type Registry		10.4. New SFP Association Type Registry
	IANA maintains a registry of "Border Gateway Protocol (BGP)		IANA maintains a registry of "Border Gateway Protocol (BGP)
	Parameters". IANA is request to create a new subregistry called the		Parameters". IANA is request to create a new subregistry called the
	"SFP Association Type" registry.		"SFP Association Type" registry.
	Valid values are in the range 0 to 65535.		Valid values are in the range 0 to 65535.
	o Values 0 and 65535 are to be marked "Reserved, not to be		o Values 0 and 65535 are to be marked "Reserved, not to be
	skipping to change at page 51, line 38 ¶		skipping to change at page 52, line 44 ¶
	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 for helpful comments, and to Joel Halpern
	for discussions that improved this document.		for discussions that improved this document. Yuanlong Jiang provided
			a useful review and caught some important issues.
	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-09		Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09
	(work in progress), February 2018.		(work in progress), February 2018.
	skipping to change at page 52, line 45 ¶		skipping to change at page 54, line 7 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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.farrel-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-
	farrel-mpls-sfc-04 (work in progress), March 2018.		ietf-mpls-sfc-01 (work in progress), May 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. 44 change blocks.
	123 lines changed or deleted		175 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/