< draft-ietf-spring-nsh-sr-08.txt		draft-ietf-spring-nsh-sr-09.txt >
	SPRING J. Guichard, Ed.		SPRING J. Guichard, Ed.
	Internet-Draft Futurewei Technologies		Internet-Draft Futurewei Technologies
	Intended status: Standards Track J. Tantsura, Ed.		Intended status: Standards Track J. Tantsura, Ed.
	Expires: December 31, 2021 Apstra inc.		Expires: January 27, 2022 Microsoft
	June 29, 2021		July 26, 2021
	Integration of Network Service Header (NSH) and Segment Routing for		Integration of Network Service Header (NSH) and Segment Routing for
	Service Function Chaining (SFC)		Service Function Chaining (SFC)
	draft-ietf-spring-nsh-sr-08		draft-ietf-spring-nsh-sr-09
	Abstract		Abstract
	This document describes the integration of Network Service Header		This document describes the integration of the Network Service Header
	(NSH) and Segment Routing (SR), as well as encapsulation details, to		(NSH) and Segment Routing (SR), as well as encapsulation details, to
	support Service Function Chaining (SFC) in an efficient manner while		support Service Function Chaining (SFC) in an efficient manner while
	maintaining separation of the service and transport planes as		maintaining separation of the service and transport planes as
	originally intended by the SFC architecture.		originally intended by the SFC architecture.
	Combining these technologies allows SR to be used for steering		Combining these technologies allows SR to be used for steering
	packets between Service Function Forwarders (SFF) along a given		packets between Service Function Forwarders (SFF) along a given
	Service Function Path (SFP) while NSH has the responsibility for		Service Function Path (SFP) while NSH has the responsibility for
	maintaining the integrity of the service plane, the SFC instance		maintaining the integrity of the service plane, the SFC instance
	context, and any associated metadata.		context, and any associated metadata.
	This integration demonstrates that NSH and SR can work cooperatively		This integration demonstrates that NSH and SR can work cooperatively
	and provide the network operator with the flexibility to use		and provide a network operator with the flexibility to use whichever
	whichever transport technology makes sense in specific areas of their		transport technology makes sense in specific areas of their network
	network infrastructure while still maintaining an end-to-end service		infrastructure while still maintaining an end-to-end service plane
	plane using NSH.		using NSH.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 December 31, 2021.		This Internet-Draft will expire on January 27, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2		1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4		2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4
	3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5		3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel . . . . . 5
	4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9		4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9
	5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11		5. Packet Processing for SR-based SFC . . . . . . . . . . . . . 11
	5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11		5.1. SR-based SFC (SR-MPLS) Packet Processing . . . . . . . . 11
	5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11		5.2. SR-based SFC (SRv6) Packet Processing . . . . . . . . . . 11
	6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12		6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 12
	6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13		6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 14
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. Caching Considerations . . . . . . . . . . . . . . . . . . . 14
	9.1. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14		10. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14
	9.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15		11.1. Protocol Number for NSH . . . . . . . . . . . . . . . . 14
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		11.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15
	11.1. Normative References . . . . . . . . . . . . . . . . . . 15		12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		13.1. Normative References . . . . . . . . . . . . . . . . . . 16
			13.2. Informative References . . . . . . . . . . . . . . . . . 18
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	1.1. SFC Overview and Rationale		1.1. SFC Overview and Rationale
	The dynamic enforcement of a service-derived and adequate forwarding		The dynamic enforcement of a service-derived and adequate forwarding
	policy for packets entering a network that supports advanced Service		policy for packets entering a network that supports advanced Service
	Functions (SFs) has become a key challenge for network operators.		Functions (SFs) has become a key challenge for network operators.
	For instance, cascading SFs at the 3GPP (Third Generation Partnership		For instance, cascading SFs at the 3GPP (Third Generation Partnership
	Project) Gi interface (N6 interface in 5G architecture) has shown		Project) Gi interface (N6 interface in 5G architecture) has shown
	limitations such as 1) redundant classification features must be		limitations such as 1) redundant classification features must be
	supported by many SFs to execute their function, 2) some SFs receive		supported by many SFs to execute their function, 2) some SFs receive
	traffic that they are not supposed to process (e.g., TCP proxies		traffic that they are not supposed to process (e.g., TCP proxies
	receiving UDP traffic) which inevitably affects their dimensioning		receiving UDP traffic) which inevitably affects their dimensioning
	and performance, and 3) an increased design complexity related to the		and performance, and 3) an increased design complexity related to the
	properly ordered invocation of several SFs.		properly ordered invocation of several SFs.
	In order to solve those problems, and to decouple the services		In order to solve those problems, and to decouple the services
	topology from the underlying physical network while allowing for		topology from the underlying physical network while allowing for
	simplified service delivery, Service Function Chaining (SFC)		simplified service delivery, Service Function Chaining (SFC)
	techniques have been introduced [RFC7665].		techniques have been introduced [RFC7665].
	SFC techniques are meant to rationalize the service delivery logic		SFC techniques are meant to rationalize the service delivery logic
	and master the companion complexity while optimizing service		and master the resulting complexity while optimizing service
	activation time cycles for operators that need more agile service		activation time cycles for operators that need more agile service
	delivery procedures to better accommodate ever-demanding customer		delivery procedures to better accommodate ever-demanding customer
	requirements. SFC allows to dynamically create service planes that		requirements. SFC allows network operators to dynamically create
	can be used by specific traffic flows. Each service plane is		service planes that can be used by specific traffic flows. Each
	realized by invoking and chaining the relevant service functions in		service plane is realized by invoking and chaining the relevant
	the right sequence. [RFC7498] provides an overview of the overall		service functions in the right sequence. [RFC7498] provides an
	SFC problem space and [RFC7665] specifies an SFC data plane		overview of the overall SFC problem space and [RFC7665] specifies an
	architecture. The SFC architecture does not make assumptions on how		SFC data plane architecture. The SFC architecture does not make
	advanced features (e.g., load-balancing, loose or strict service		assumptions on how advanced features (e.g., load-balancing, loose or
	paths) could be enabled within a domain. Various deployment options		strict service paths) could be enabled within a domain. Various
	are made available to operators with the SFC architecture and this		deployment options are made available to operators with the SFC
	approach is fundamental to accommodate various and heterogeneous		architecture and this approach is fundamental to accommodate various
	deployment contexts.		and heterogeneous deployment contexts.
	Many approaches can be considered for encoding the information		Many approaches can be considered for encoding the information
	required for SFC purposes (e.g., communicate a service chain pointer,		required for SFC purposes (e.g., communicate a service chain pointer,
	encode a list of loose/explicit paths, or disseminate a service chain		encode a list of loose/explicit paths, or disseminate a service chain
	identifier together with a set of context information). Likewise,		identifier together with a set of context information). Likewise,
	many approaches can also be considered for the channel to be used to		many approaches can also be considered for the channel to be used to
	carry SFC-specific information (e.g., define a new header, re-use		carry SFC-specific information (e.g., define a new header, re-use
	existing packet header fields, or define an IPv6 extension header).		existing packet header fields, or define an IPv6 extension header).
	Among all these approaches, the IETF created a transport-independent		Among all these approaches, the IETF created a transport-independent
	SFC encapsulation scheme: NSH. This design is pragmatic as it does		SFC encapsulation scheme: NSH [RFC8300]. This design is pragmatic as
	not require replicating the same specification effort as a function		it does not require replicating the same specification effort as a
	of underlying transport encapsulation. Moreover, this design		function of underlying transport encapsulation. Moreover, this
	approach encourages consistent SFC-based service delivery in networks		design approach encourages consistent SFC-based service delivery in
	enabling distinct transport protocols in various network segments or		networks enabling distinct transport protocols in various network
	even between SFFs vs SF-SFF hops.		segments or even between SFFs vs SF-SFF hops.
	1.2. Requirements Language		1.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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119] [RFC8174] when, and only when, they appear in all capitals,		[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
	as shown here.		as shown here.
	2. SFC within Segment Routing Networks		2. SFC within Segment Routing Networks
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 20 ¶
	Function Path (SFP) but different SR policy can coexist on the same		Function Path (SFP) but different SR policy can coexist on the same
	SFP without conflict during SFF processing.		SFP without conflict during SFF processing.
	3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel		3. NSH-based SFC with SR-MPLS or SRv6 Transport Tunnel
	Because of the transport-independent nature of NSH-based service		Because of the transport-independent nature of NSH-based service
	function chains, it is expected that the NSH has broad applicability		function chains, it is expected that the NSH has broad applicability
	across different network domains (e.g., access, core). By way of		across different network domains (e.g., access, core). By way of
	illustration the various SFs involved in a service function chain may		illustration the various SFs involved in a service function chain may
	be available in a single data center, or spread throughout multiple		be available in a single data center, or spread throughout multiple
	locations (e.g., data centers, different POPs), depending upon the		locations (e.g., data centers, different Points of Presense (POPs)),
	network operator preference and/or availability of service resources.		depending upon the network operator preference and/or availability of
	Regardless of where the SFs are deployed it is necessary to provide		service resources. Regardless of where the SFs are deployed it is
	traffic steering through a set of SFFs, and when NSH and SR are		necessary to provide traffic steering through a set of SFFs, and when
	integrated, this is provided by SR-MPLS or SRv6.		NSH and SR are integrated, this is provided by SR-MPLS or SRv6.
	The following three figures provide an example of an SFC established		The following three figures provide an example of an SFC established
	flow F that has SF instances located in different data centers, DC1		flow F that has SF instances located in different data centers, DC1
	and DC2. For the purpose of illustration, let the SFC's NSH SPI be		and DC2. For the purpose of illustration, let the SFC's NSH SPI be
	100 and the initial Service Index (SI) be 255.		100 and the initial Service Index (SI) be 255.
	Referring to Figure 1, packets of flow F in DC1 are classified into		Referring to Figure 1, packets of flow F in DC1 are classified into
	an NSH-based SFC and encapsulated after classification as <Inner		an NSH-based SFC and encapsulated after classification as <Inner
	Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1		Pkt><NSH: SPI 100, SI 255><Outer-transport> and forwarded to SFF1
	(which is the first SFF hop for this service function chain).		(which is the first SFF hop for this service function chain).
	skipping to change at page 6, line 12 ¶		skipping to change at page 6, line 12 ¶
	SFF1 does a lookup on <SPI 100, SI 254> which results in <next-hop:		SFF1 does a lookup on <SPI 100, SI 254> which results in <next-hop:
	DC1-GW1> and forwards the packet to DC1-GW1.		DC1-GW1> and forwards the packet to DC1-GW1.
	+--------------------------- DC1 ----------------------------+		+--------------------------- DC1 ----------------------------+
	| +-----+ |		| +-----+ |
	| | SF1 | |		| | SF1 | |
	| +--+--+ |		| +--+--+ |
	| | |		| | |
	| | |		| | |
	| +------------+ | +------------+ |		| +------------+ | +------------+ |
	| | N(100,255) | | | F:Inner Pkt| |		| | N(100,255) | | | N(100,254) | |
	| +------------+ | +------------+ |		| +------------+ | +------------+ |
	| | F:Inner Pkt| | | N(100,254) | |		| | F:Inner Pkt| | | F:Inner Pkt| |
	| +------------+ ^ | | +------------+ |		| +------------+ ^ | | +------------+ |
	| (2) | | | (3) |		| (2) | | | (3) |
	| | | v |		| | | v |
	| (1) | (4) |		| (1) | (4) |
	|+------------+ ----> +--+---+ ----> +---------+ |		|+------------+ ----> +--+---+ ----> +---------+ |
	|| | NSH | | NSH | | |		|| | NSH | | NSH | | |
	|| Classifier +------------+ SFF1 +--------------+ DC1-GW1 + |		|| Classifier +------------+ SFF1 +--------------+ DC1-GW1 + |
	|| | | | | | |		|| | | | | | |
	|+------------+ +------+ +---------+ |		|+------------+ +------+ +---------+ |
	| |		| |
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	Figure 1: SR for inter-DC SFC - Part 1		Figure 1: SR for inter-DC SFC - Part 1
	Referring now to Figure 2, DC1-GW1 performs a lookup using the		Referring now to Figure 2, DC1-GW1 performs a lookup using the
	information conveyed in the NSH which results in <next-hop: DC2-GW1,		information conveyed in the NSH which results in <next-hop: DC2-GW1,
	encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or		encapsulation: SR>. The SR encapsulation, which may be SR-MPLS or
	SRv6, has the SR segment-list to forward the packet across the inter-		SRv6, has the SR segment-list to forward the packet across the inter-
	DC network to DC2.		DC network to DC2.
	+----------- Inter DC ----------------+		+----------- Inter DC ----------------+
	| (5) |		(4) | (5) |
	+------+ ----> | +---------+ ----> +---------+ |		+------+ ----> | +---------+ ----> +---------+ |
	| | NSH | | | SR | | |		| | NSH | | | SR | | |
	+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |		+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
	| | | | | | | |		| | | | | | | |
	+------+ | +---------+ +---------+ |		+------+ | +---------+ +---------+ |
	| |		| |
	| +------------+ |		| +------------+ |
	| | S(DC2-GW1) | |		| | S(DC2-GW1) | |
	| +------------+ |		| +------------+ |
	| | N(100,254) | |		| | N(100,254) | |
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	Figure 2: SR for inter-DC SFC - Part 2		Figure 2: SR for inter-DC SFC - Part 2
	When the packet arrives at DC2, as shown in Figure 3, the SR		When the packet arrives at DC2, as shown in Figure 3, the SR
	encapsulation is removed and DC2-GW1 performs a lookup on the NSH		encapsulation is removed and DC2-GW1 performs a lookup on the NSH
	which results in next hop: SFF2. When SFF2 receives the packet, it		which results in next hop: SFF2. When SFF2 receives the packet, it
	performs a lookup on <NSH: SPI 100, SI 254> and determines to forward		performs a lookup on <NSH: SPI 100, SI 254> and determines to forward
	the packet to SF2. SF2 applies its service, decrements the SI by 1,		the packet to SF2. SF2 applies its service, decrements the SI by 1,
	and returns the packet to SFF2. SFF2 therefore has <NSH: SPI 100, SI		and returns the packet to SFF2. SFF2 therefore has <NSH: SPI 100, SI
	253> when the packet comes back from SF2. SFF2 does a lookup on		253> when the packet comes back from SF2. SFF2 does a lookup on
	<NSH: SPI 100, SI 253> which results in end of service function		<NSH: SPI 100, SI 253> which results in the end of the service
	chain.		function chain.
	+------------------------ DC2 ----------------------+		+------------------------ DC2 ----------------------+
	| +-----+ |		| +-----+ |
	| | SF2 | |		| | SF2 | |
	| +--+--+ |		| +--+--+ |
	| | |		| | |
	| | |		| | |
	| +------------+ | +------------+ |		| +------------+ | +------------+ |
	| | N(100,254) | | | F:Inner Pkt| |		| | N(100,254) | | | N(100,253) | |
	| +------------+ | +------------+ |		| +------------+ | +------------+ |
	| | F:Inner Pkt| | | N(100,253) | |		| | F:Inner Pkt| | | F:Inner Pkt| |
	| +------------+ ^ | | +------------+ |		| +------------+ ^ | | +------------+ |
	| (7) | | | (8) |		| (7) | | | (8) |
	| | | v |		| | | v |
	| (6) | (9) |		(5) | (6) | (9) |
	|+----------+ ----> +--+---+ ----> |		+---------+ ---> | +----------+ ----> +--+---+ ----> |
	|| | NSH | | IP |		| | SR | | | NSH | | IP |
	|| DC2-GW1 +------------+ SFF2 | |		+ DC1-GW1 +--------|-+ DC2-GW1 +------------+ SFF2 | |
	|| | | | |		| | | | | | | |
	|+----------+ +------+ |		+---------+ | +----------+ +------+ |
	| |		| |
	| +------------+ +------------+ |		| +------------+ +------------+ |
	| | N(100,254) | | F:Inner Pkt| |		| | N(100,254) | | F:Inner Pkt| |
	| +------------+ +------------+ |		| +------------+ +------------+ |
	| | F:Inner Pkt| |		| | F:Inner Pkt| |
	| +------------+ |		| +------------+ |
	+---------------------------------------------------+		+---------------------------------------------------+
	Figure 3: SR for inter-DC SFC - Part 3		Figure 3: SR for inter-DC SFC - Part 3
	The benefits of this scheme are listed hereafter:		The benefits of this scheme are listed hereafter:
	o The network operator is able to take advantage of the transport-		o The network operator is able to take advantage of the transport-
	independent nature of the NSH encapsulation, while the service is		independent nature of the NSH encapsulation, while the service is
	provisioned end2end.		provisioned end-to-end.
	o The network operator is able to take advantage of the traffic		o The network operator is able to take advantage of the traffic
	steering (traffic engineering) capability of SR where appropriate.		steering (traffic engineering) capability of SR where appropriate.
	o Clear responsibility division and scope between NSH and SR.		o Clear responsibility division and scope between NSH and SR.
	Note that this scenario is applicable to any case where multiple		Note that this scenario is applicable to any case where multiple
	segments of a service function chain are distributed across multiple		segments of a service function chain are distributed across multiple
	domains or where traffic-engineered paths are necessary between SFFs		domains or where traffic-engineered paths are necessary between SFFs
	(strict forwarding paths for example). Further note that the above		(strict forwarding paths for example). Further note that the above
	example can also be implemented using end to end segment routing		example can also be implemented using end-to-end segment routing
	between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the		between SFF1 and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the
	packets based on segment routing instructions and are not looking at		packets based on segment routing instructions and are not looking at
	the NSH header for forwarding).		the NSH header for forwarding.)
	4. SR-based SFC with Integrated NSH Service Plane		4. SR-based SFC with Integrated NSH Service Plane
	In this scenario we assume that the SFs are NSH-aware and therefore		In this scenario we assume that the SFs are NSH-aware and therefore
	it should not be necessary to implement an SFC proxy to achieve SFC.		it should not be necessary to implement an SFC proxy to achieve SFC.
	The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF		The operation relies upon SR-MPLS or SRv6 to perform SFF-SFF
	transport and NSH to provide the service plane between SFs thereby		transport and NSH to provide the service plane between SFs thereby
	maintaining SFC context (e.g., the service plane path referenced by		maintaining SFC context (e.g., the service plane path referenced by
	the SPI) and any associated metadata.		the SPI) and any associated metadata.
	When a service function chain is established, a packet associated		When a service function chain is established, a packet associated
	with that chain will first carry an NSH that will be used to maintain		with that chain will first carry an NSH that will be used to maintain
	the end-to-end service plane through use of the SFC context. The SFC		the end-to-end service plane through use of the SFC context. The SFC
	context is used by an SFF to determine the SR segment list for		context is used by an SFF to determine the SR segment list for
	forwarding the packet to the next-hop SFFs. The packet is then		forwarding the packet to the next-hop SFFs. The packet is then
	encapsulated using the SR header and forwarded in the SR domain		encapsulated using the SR header and forwarded in the SR domain
	following normal SR operations.		following normal SR operations.
	When a packet has to be forwarded to an SF attached to an SFF, the		When a packet has to be forwarded to an SF attached to an SFF, the
	SFF performs a lookup on the SID associated with the SF. In the case		SFF performs a lookup on the segment identifier (SID) associated with
	of SR-MPLS this will be a prefix SID [RFC8402]. In the case of SRv6,		the SF. In the case of SR-MPLS this will be a prefix SID [RFC8402].
	the behavior described within this document is assigned the name		In the case of SRv6, the behavior described within this document is
	END.NSH, and section 9.2 requests allocation of a code point by IANA.		assigned the name END.NSH, and section 9.2 requests allocation of a
	The result of this lookup allows the SFF to retrieve the next hop		code point by IANA. The result of this lookup allows the SFF to
	context between the SFF and SF (e.g., the destination MAC address in		retrieve the next hop context between the SFF and SF (e.g., the
	case native Ethernet encapsulation is used between SFF and SF). In		destination MAC address in case native Ethernet encapsulation is used
	addition the SFF strips the SR information from the packet, updates		between SFF and SF). In addition the SFF strips the SR information
	the SR information, and saves it to a cache indexed by the NSH		from the packet, updates the SR information, and saves it to a cache
	Service Path Identifier (SPI) and the Service Index (SI) decremented		indexed by the NSH Service Path Identifier (SPI) and the Service
	by 1. This saved SR information is used to encapsulate and forward		Index (SI) decremented by 1. This saved SR information is used to
	the packet(s) coming back from the SF.		encapsulate and forward the packet(s) coming back from the SF.
	The behavior of remembering the SR segment-list occurs at the end of		The behavior of remembering the SR segment-list occurs at the end of
	the regularly defined logic. The behavior of reattaching the		the regularly defined logic. The behavior of reattaching the
	segment-list occurs before the SR process of forwarding the packet to		segment-list occurs before the SR process of forwarding the packet to
	the next entry in the segment-list. Both behaviors are further		the next entry in the segment-list. Both behaviors are further
	detailed in section 5.		detailed in section 5.
	When the SF receives the packet, it processes it as usual. The SF		When the SF receives the packet, it processes it as usual. When the
	may use a Classifier to re-classify the already processed packet.		SF is co-resident with a classifier, the already processed packet may
	The SF sends the packet back to the SFF. Once the SFF receives this		be re-classified. The SF sends the packet back to the SFF. Once the
	packet, it extracts the SR information using the NSH SPI and SI as		SFF receives this packet, it extracts the SR information using the
	the index into the cache. The SFF then pushes the retrieved SR		NSH SPI and SI as the index into the cache. The SFF then pushes the
	header on top of the NSH header, and forwards the packet to the next		retrieved SR header on top of the NSH header, and forwards the packet
	segment in the segment-list. The lookup in the SFF cache might fail		to the next segment in the segment-list. The lookup in the SFF cache
	if re-classification changed NSH SPI and/or SI values. In such a		might fail if re-classification at the SF changed the NSH SPI and/or
	case, SFF must prepare the new SR header to push on top of NSH before		SI to values that do not exist in the SFF cache. In such a case, the
	forwarding the packet.		SFF must generate an error and drop the packet.
	Figure 4 illustrates an example of this scenario.		Figure 4 illustrates an example of this scenario.
	+-----+ +-----+		+-----+ +-----+
	| SF1 | | SF2 |		| SF1 | | SF2 |
	+--+--+ +--+--+		+--+--+ +--+--+
	| |		| |
	| |		| |
	+-----------+ | +-----------+ +-----------+ | +-----------+		+-----------+ | +-----------+ +-----------+ | +-----------+
	|N(100,255) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|		|N(100,255) | | |N(100,254) | |N(100,254) | | |N(100,253) |
	+-----------+ | +-----------+ +-----------+ | +-----------+		+-----------+ | +-----------+ +-----------+ | +-----------+
	|F:Inner Pkt| | |N(100,254) | |F:Inner Pkt| | |N(100,253) |		|F:Inner Pkt| | |F:Inner Pkt| |F:Inner Pkt| | |F:Inner Pkt|
	+-----------+ | +-----------+ +-----------+ | +-----------+		+-----------+ | +-----------+ +-----------+ | +-----------+
	(2) ^ | (3) | (5) ^ | (6) |		(2) ^ | (3) | (5) ^ | (6) |
	| | | | | |		| | | | | |
	| | v | | v		| | | | | |
	+------------+ (1)--> +-+----+ (4)--> +---+--+ (7)-->IP		(1) | | v (4) | | v (7)
	| | NSHoSR | | NSHoSR | |		+------------+ ---> +-+----+ ----> +---+--+ -->
	| Classifier +--------+ SFF1 +---------------------+ SFF2 |		| | NSHoverSR | | NSHoverSR | | IP
	| | | | | |		| Classifier +-----------+ SFF1 +---------------------+ SFF2 |
	+------------+ +------+ +------+		| | | | | |
			+------------+ +------+ +------+
	+------------+ +------------+		------------+ +------+ +------+
	| S(SF1) | | S(SF2) |		+------------+ +------------+ +------------+
	+------------+ +------------+		| S(SF1) | | S(SF2) | | F:Inner Pkt|
	| S(SFF2) | | N(100,254) |		+------------+ +------------+ +------------+
	+------------+ +------------+		| S(SFF2) | | N(100,254) |
	| S(SF2) | | F:Inner Pkt|		+------------+ +------------+
	+------------+ +------------+		| S(SF2) | | F:Inner Pkt|
	| N(100,255) |		+------------+ +------------+
	+------------+		| N(100,255) |
	| F:Inner Pkt|		+------------+
	+------------+		| F:Inner Pkt|
			+------------+
	Figure 4: NSH over SR for SFC		Figure 4: NSH over SR for SFC
	The benefits of this scheme include:		The benefits of this scheme include:
	o It is economically sound for SF vendors to only support one		o It is economically sound for SF vendors to only support one
	unified SFC solution. The SF is unaware of the SR.		unified SFC solution. The SF is unaware of the SR.
	o It simplifies the SFF (i.e., the SR router) by nullifying the		o It simplifies the SFF (i.e., the SR router) by nullifying the
	needs for re-classification and SR proxy.		needs for re-classification and SR proxy.
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	o It takes advantage of SR to eliminate the NSH forwarding state in		o It takes advantage of SR to eliminate the NSH forwarding state in
	SFFs. This applies each time strict or loose SFPs are in use.		SFFs. This applies each time strict or loose SFPs are in use.
	o It requires no interworking as would be the case if SR-MPLS based		o It requires no interworking as would be the case if SR-MPLS based
	SFC and NSH-based SFC were deployed as independent mechanisms in		SFC and NSH-based SFC were deployed as independent mechanisms in
	different parts of the network.		different parts of the network.
	5. Packet Processing for SR-based SFC		5. Packet Processing for SR-based SFC
	This section describes the End.NSH behavior (SRv6), Prefix SID		This section describes the End.NSH behavior (SRv6), Prefix SID
	behavior (SR-MPLS) and NSH processing logic.		behavior (SR-MPLS), and NSH processing logic.
	5.1. SR-based SFC (SR-MPLS) Packet Processing		5.1. SR-based SFC (SR-MPLS) Packet Processing
	When an SFF receives a packet destined to S and S is a local prefix		When an SFF receives a packet destined to S and S is a local prefix
	SID associated with an SF, the SFF strips the SR segment-list (label		SID associated with an SF, the SFF strips the SR segment-list (label
	stack) from the packet, updates the SR information, and saves it to a		stack) from the packet, updates the SR information, and saves it to a
	cache indexed by the NSH Service Path Identifier (SPI) and the		cache indexed by the NSH Service Path Identifier (SPI) and the
	Service Index (SI) decremented by 1. This saved SR information is		Service Index (SI) decremented by 1. This saved SR information is
	used to re-encapsulate and forward the packet(s) coming back from the		used to re-encapsulate and forward the packet(s) coming back from the
	SF.		SF.
	5.2. SR-based SFC (SRv6) Packet Processing		5.2. SR-based SFC (SRv6) Packet Processing
	This section describes the End.NSH behavior and NSH processing logic		This section describes the End.NSH behavior and NSH processing logic
	for SRv6. The pseudo code is shown below.		for SRv6. The pseudo code is shown below.
	When N receives a packet destined to S and S is a local End.NSH SID,		When N receives a packet destined to S and S is a local End.NSH SID,
	the processing is the same as that specified by RFC 8754 section		the processing is the same as that specified by [RFC8754] section
	4.3.1.1, up through line S.16.		4.3.1.1, up through line S.16.
	After S.15, if S is a local End.NSH SID, then:		After S.15, if S is a local End.NSH SID, then:
	S15.1. Remove and store IPv6 and SRH headers in local cache indexed		S15.1. Remove and store IPv6 and SRH headers in local cache indexed
	by <NSH: service-path-id, service-index -1>		by <NSH: service-path-id, service-index -1>
	S15.2. Submit the packet to the NSH FIB lookup and transmit to the		S15.2. Submit the packet to the NSH FIB lookup and transmit to the
	destination associated with <NSH: service-path-id, service-index>		destination associated with <NSH: service-path-id, service-index>
	Note: The End.NSH behavior interrupts the normal SRH packet		Note: The End.NSH behavior interrupts the normal SRH packet
	processing as described in RFC8754 section 4.3.1.1, which does not		processing as described in [RFC8754] section 4.3.1.1, which does not
	continue to S16 at this time.		continue to S16 at this time.
	When a packet is returned to the SFF from the SF, reattach the cached		When a packet is returned to the SFF from the SF, reattach the cached
	IPv6 and SRH headers based on the <NSH: service-path-id, service-		IPv6 and SRH headers based on the <NSH: service-path-id, service-
	index> from the NSH header. Then resume processing from [RFC8754]		index> from the NSH header. Then resume processing from [RFC8754]
	section 4.3.1.1 with line S.16.		section 4.3.1.1 with line S.16.
	6. Encapsulation		6. Encapsulation
	6.1. NSH using SR-MPLS Transport		6.1. NSH using SR-MPLS Transport
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 37 ¶
	Figure 5: NSH using SR-MPLS Transport		Figure 5: NSH using SR-MPLS Transport
	As described in [RFC8402], the IGP signaling extension for IGP-Prefix		As described in [RFC8402], the IGP signaling extension for IGP-Prefix
	segment includes a flag to indicate whether directly connected		segment includes a flag to indicate whether directly connected
	neighbors of the node on which the prefix is attached should perform		neighbors of the node on which the prefix is attached should perform
	the NEXT operation or the CONTINUE operation when processing the SID.		the NEXT operation or the CONTINUE operation when processing the SID.
	When NSH is carried beneath SR-MPLS it is necessary to terminate the		When NSH is carried beneath SR-MPLS it is necessary to terminate the
	NSH-based SFC at the tail-end node of the SR-MPLS label stack. This		NSH-based SFC at the tail-end node of the SR-MPLS label stack. This
	can be achieved using either the NEXT or CONTINUE operation.		can be achieved using either the NEXT or CONTINUE operation.
	If NEXT operation is to be used, then at the end of the SR-MPLS path		If the NEXT operation is to be used, then at the end of the SR-MPLS
	it is necessary to provide an indication to the tail-end that NSH		path it is necessary to provide an indication to the tail-end that
	follows the SR-MPLS label stack as described by [RFC8596].		NSH follows the SR-MPLS label stack as described by [RFC8596].
	If CONTINUE operation is to be used, this is the equivalent of MPLS		If the CONTINUE operation is to be used, this is the equivalent of
	Ultimate Hop Popping (UHP) and therefore it is necessary to ensure		MPLS Ultimate Hop Popping (UHP) and therefore it is necessary to
	that the penultimate hop node does not pop the top label of the SR-		ensure that the penultimate hop node does not pop the top label of
	MPLS label stack and thereby expose NSH to the wrong SFF. This is		the SR-MPLS label stack and thereby expose NSH to the wrong SFF.
	realized by setting No-PHP flag in Prefix-SID Sub-TLV [RFC8667],		This is realized by setting No-PHP flag in Prefix-SID Sub-TLV
	[RFC8665]. It is RECOMMENDED that a specific prefix-SID be allocated		[RFC8667], [RFC8665]. It is RECOMMENDED that a specific prefix-SID
	at each node for use by the SFC application for this purpose.		be allocated at each node for use by the SFC application for this
			purpose.
	6.2. NSH using SRv6 Transport		6.2. NSH using SRv6 Transport
	When carrying NSH within an SRv6 transport the full encapsulation is		When carrying NSH within an SRv6 transport the full encapsulation is
	as illustrated in Figure 6.		as illustrated in Figure 6.
	0 1 2 3		0 1 2 3
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type | Segments Left |		| Next Header | Hdr Ext Len | Routing Type | Segments Left |
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	7. Security Considerations		7. Security Considerations
	Generic SFC-related security considerations are discussed in		Generic SFC-related security considerations are discussed in
	[RFC7665].		[RFC7665].
	NSH-specific security considerations are discussed in [RFC8300].		NSH-specific security considerations are discussed in [RFC8300].
	Generic segment routing related security considerations are discussed		Generic segment routing related security considerations are discussed
	in section 7 of [RFC8754] and section 5 of [RFC8663].		in section 7 of [RFC8754] and section 5 of [RFC8663].
	8. MTU Considerations		8. Backwards Compatibility
			For SRv6/IPv6, if a processing node does not recognize NSH it should
			follow the procedures described in section 4 of [RFC8200]. For SR-
			MPLS, if a processing node does not recognize NSH it should follow
			the procedures laid out in section 3.18 of [RFC3031].
			9. Caching Considerations
			The cache mechanism must remove cached entries at an appropriate time
			determined by the implementation. Further, an implementation MAY
			allow network operators to set the said time value. In the case a
			packet arriving from an SF does not have a matching cached entry, the
			SFF SHOULD log this event.
			10. MTU Considerations
	Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it		Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it
	is RECOMMENDED for network operators to increase the underlying MTU		is RECOMMENDED for network operators to increase the underlying MTU
	so that SR/NSH traffic is forwarded within an SR domain without		so that SR/NSH traffic is forwarded within an SR domain without
	fragmentation.		fragmentation.
	9. IANA Considerations		11. IANA Considerations
	9.1. Protocol Number for NSH
			11.1. Protocol Number for NSH
	IANA is requested to assign a protocol number TBA1 for the NSH from the		IANA is requested to assign a protocol number TBA1 for the NSH from the
	"Assigned Internet Protocol Numbers" registry available at		"Assigned Internet Protocol Numbers" registry available at
	https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml		https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	| Decimal | Keyword | Protocol | IPv6 | Reference |		| Decimal | Keyword | Protocol | IPv6 | Reference |
	| | | | Extension | |		| | | | Extension | |
	| | | | Header | |		| | | | Header | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	| TBA1 | NSH | Network | N | [ThisDocument] |		| TBA1 | NSH | Network | N | [ThisDocument] |
	| | | Service | | |		| | | Service | | |
	| | | Header | | |		| | | Header | | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	9.2. SRv6 Endpoint Behavior for NSH		11.2. SRv6 Endpoint Behavior for NSH
	This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors"		This I-D requests IANA to allocate, within the "SRv6 Endpoint Behaviors"
	sub-registry belonging to the top-level "Segment-routing with IPv6 data		sub-registry belonging to the top-level "Segment-routing with IPv6 data
	plane (SRv6) Parameters" registry, the following allocations:		plane (SRv6) Parameters" registry, the following allocations:
	Value Description Reference		Value Description Reference
	--------------------------------------------------------------		--------------------------------------------------------------
	TBA2 End.NSH - NSH Segment [This.ID]		TBA2 End.NSH - NSH Segment [This.ID]
	10. Contributing Authors		12. Contributing Authors
	The following co-authors, along with their respective affiliations at		The following co-authors, along with their respective affiliations at
	the time of WG adoption, provided valuable inputs and text contributions		the time of publication, provided valuable inputs and text contributions
	to this document.		to this document.
	Mohamed Boucadair		Mohamed Boucadair
	Orange		Orange
	mohamed.boucadair@orange.com		mohamed.boucadair@orange.com
	Joel Halpern		Joel Halpern
	Ericsson		Ericsson
	joel.halpern@ericsson.com		joel.halpern@ericsson.com
	skipping to change at page 15, line 31 ¶		skipping to change at page 16, line 28 ¶
	shassan@cisco.com		shassan@cisco.com
	Wim Henderickx		Wim Henderickx
	Nokia		Nokia
	wim.henderickx@nokia.com		wim.henderickx@nokia.com
	Haoyu Song		Haoyu Song
	Futurewei Technologies		Futurewei Technologies
	haoyu.song@futurewei.com		haoyu.song@futurewei.com
	11. References		13. References
	11.1. Normative References		13.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>.
			[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
			Label Switching Architecture", RFC 3031,
			DOI 10.17487/RFC3031, January 2001,
			<https://www.rfc-editor.org/info/rfc3031>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
	January 2012, <https://www.rfc-editor.org/info/rfc6347>.		January 2012, <https://www.rfc-editor.org/info/rfc6347>.
	[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function		[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
	Chaining (SFC) Architecture", RFC 7665,		Chaining (SFC) Architecture", RFC 7665,
	DOI 10.17487/RFC7665, October 2015,		DOI 10.17487/RFC7665, October 2015,
	<https://www.rfc-editor.org/info/rfc7665>.		<https://www.rfc-editor.org/info/rfc7665>.
	[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-		[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
	in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,		in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
	March 2017, <https://www.rfc-editor.org/info/rfc8086>.		March 2017, <https://www.rfc-editor.org/info/rfc8086>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	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>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
	[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>.
	[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,		[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,		Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
	July 2018, <https://www.rfc-editor.org/info/rfc8402>.		July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	skipping to change at page 17, line 5 ¶		skipping to change at page 18, line 16 ¶
	Bashandy, A., Gredler, H., and B. Decraene, "IS-IS		Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
	Extensions for Segment Routing", RFC 8667,		Extensions for Segment Routing", RFC 8667,
	DOI 10.17487/RFC8667, December 2019,		DOI 10.17487/RFC8667, December 2019,
	<https://www.rfc-editor.org/info/rfc8667>.		<https://www.rfc-editor.org/info/rfc8667>.
	[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,		[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
	Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header		Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
	(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,		(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
	<https://www.rfc-editor.org/info/rfc8754>.		<https://www.rfc-editor.org/info/rfc8754>.
	11.2. Informative References		13.2. Informative References
	[I-D.ietf-spring-sr-service-programming]		[I-D.ietf-spring-sr-service-programming]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,		Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,		d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
	Henderickx, W., and S. Salsano, "Service Programming with		Henderickx, W., and S. Salsano, "Service Programming with
	Segment Routing", draft-ietf-spring-sr-service-		Segment Routing", draft-ietf-spring-sr-service-
	programming-03 (work in progress), September 2020.		programming-03 (work in progress), September 2020.
	[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,
	skipping to change at page 17, line 30 ¶		skipping to change at page 18, line 41 ¶
	James N Guichard (editor)		James N Guichard (editor)
	Futurewei Technologies		Futurewei Technologies
	2330 Central Express Way		2330 Central Express Way
	Santa Clara		Santa Clara
	USA		USA
	Email: james.n.guichard@futurewei.com		Email: james.n.guichard@futurewei.com
	Jeff Tantsura (editor)		Jeff Tantsura (editor)
	Apstra inc.		Microsoft
	USA		USA
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
End of changes. 43 change blocks.
	143 lines changed or deleted		170 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/