< draft-ietf-spring-nsh-sr-02.txt		draft-ietf-spring-nsh-sr-03.txt >
	SPRING J. Guichard, Ed.		SPRING J. Guichard, Ed.
	Internet-Draft H. Song		Internet-Draft Futurewei Technologies
	Intended status: Standards Track Futurewei Technologies		Intended status: Standards Track J. Tantsura, Ed.
	Expires: October 8, 2020 J. Tantsura		Expires: March 28, 2021 Apstra inc.
	Apstra inc.		September 24, 2020
	J. Halpern
	Ericsson
	W. Henderickx
	Nokia
	M. Boucadair
	Orange
	S. Hassan
	Cisco Systems
	April 6, 2020
	Network Service Header (NSH) and Segment Routing Integration for Service		Integration of Network Service Header (NSH) and Segment Routing for
	Function Chaining (SFC)		Service Function Chaining (SFC)
	draft-ietf-spring-nsh-sr-02		draft-ietf-spring-nsh-sr-03
	Abstract		Abstract
	This document describes two application scenarios where Network		This document describes two application scenarios where Network
	Service Header (NSH) and Segment Routing (SR) techniques can be		Service Header (NSH) and Segment Routing (SR) can be deployed
	deployed together to support Service Function Chaining (SFC) in an		together to support Service Function Chaining (SFC) in an efficient
	efficient manner while maintaining separation of the service and		manner while maintaining separation of the service and transport
	transport planes as originally intended by the SFC architecture.		planes as originally intended by the SFC architecture.
	In the first scenario, an NSH-based SFC is created using SR as the
	transport between Service Function Forwarders (SFFs). SR in this
	case is just one of many encapsulations that could be used to
	maintain the transport-independent nature of NSH-based service
	chains.
	In the second scenario, SR is used to represent each service hop of
	the NSH-based SFC as a segment within the segment-list. SR and NSH
	in this case are integrated.
	In both scenarios SR is responsible for steering packets between SFFs		In both scenarios, SR is responsible for steering packets between
	along a given Service Function Path (SFP) while NSH is responsible		SFFs along a given Service Function Path (SFP) while NSH is
	for maintaining the integrity of the service plane, the SFC instance		responsible for maintaining the integrity of the service plane, the
	context, and any associated metadata.		SFC instance context, and any associated metadata.
	These application scenarios demonstrate that NSH and SR can work		These application scenarios demonstrate that NSH and SR can work
	jointly and complement each other leaving the network operator with		jointly and complement each other leaving the network operator with
	the flexibility to use whichever transport technology makes sense in		the flexibility to use whichever transport technology makes sense in
	specific areas of their network infrastructure, and still maintain an		specific areas of their network infrastructure, and still maintain an
	end-to-end service plane using NSH.		end-to-end service plane 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
	skipping to change at page 2, line 20 ¶		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 October 8, 2020.		This Internet-Draft will expire on March 28, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 3		1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.3. SFC within SR Networks . . . . . . . . . . . . . . . . . 4		2. SFC within Segment Routing Networks . . . . . . . . . . . . . 4
	2. NSH-based SFC with SR-based Transport Tunnel . . . . . . . . 5		3. NSH-based SFC with SR-based Transport Tunnel . . . . . . . . 5
	3. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9		4. SR-based SFC with Integrated NSH Service Plane . . . . . . . 9
	4. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11		5. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11
	4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11		5.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11
	4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12		5.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13		7.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13
	6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14		7.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	1.1. SFC Overview and Rationale		1.1. SFC Overview and Rationale
	The dynamic enforcement of a service-derived, adequate forwarding		The dynamic enforcement of a service-derived, 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.
	Particularly, cascading SFs, for example at the Gi interface in the		Particularly, cascading SFs at the so-called Third Generation
	context of mobile network infrastructure, have shown their limits,		Partnership Project (3GPP) Gi interface in the context of mobile
	such as the same redundant classification features must be supported		network infrastructure, have shown their limitations, such as the
	by many SFs in order to execute their function, some SFs are		same redundant classification features must be supported by many SFs
	receiving traffic that they are not supposed to process (e.g., TCP		to execute their function, some SFs are receiving traffic that they
	proxies receiving UDP traffic), which inevitably affects their		are not supposed to process (e.g., TCP proxies receiving UDP
	dimensioning and performance, an increased design complexity related		traffic), which inevitably affects their dimensioning and
	to the properly ordered invocation of several SFs, etc.		performance, an increased design complexity related to the properly
			ordered invocation of several SFs, etc.
	In order to solve those problems and to avoid the adherence with the		In order to solve those problems and to decouple the services
	underlying physical network topology while allowing for simplified		topology from the underlying physical network while allowing for
	service delivery, Service Function Chaining (SFC) techniques have		simplified service delivery, Service Function Chaining (SFC)
	been introduced.		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 companion 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. Indeed, SFC allows to dynamically create service		requirements. Indeed, SFC allows to dynamically create service
	planes that can be used by specific traffic flows. Each service		planes that can be used by specific traffic flows. Each service
	plane is realized by invoking and chaining the relevant service		plane is realized by invoking and chaining the relevant service
	functions in the right sequence. [RFC7498] provides an overview of		functions in the right sequence. [RFC7498] provides an overview of
	the SFC problem space and [RFC7665] specifies an SFC architecture.		the overall SFC problem space and [RFC7665] specifies an SFC data
	The SFC architecture has the merit to not make assumptions on how		plane architecture. The SFC architecture has the merit to not make
	advanced features (e.g., load-balancing, loose or strict service		assumptions on how advanced features (e.g., load-balancing, loose or
	paths) have to be enabled with 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, disseminate a service chain		encode a list of loose/explicit paths, or disseminate a service chain
	identifier together with a set of context information, etc.).		identifier together with a set of context information). Likewise,
	Likewise, many approaches can also be considered for the channel to		many approaches can also be considered for the channel to be used to
	be used to carry SFC-specific information (e.g., define a new header,		carry SFC-specific information (e.g., define a new header, re-use
	re-use existing fields, define an IPv6 extension header, etc.).		existing packet header fields, or define an IPv6 extension header).
	Among all these approaches, the IETF endorsed a transport-independent		Among all these approaches, the IETF endorsed a transport-independent
	SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC		SFC encapsulation scheme: NSH [RFC8300]; which is the most mature SFC
	encapsulation solution. This design is pragmatic as it does not		encapsulation solution. This design is pragmatic as it does not
	require replicating the same specification effort as a function of		require replicating the same specification effort as a function of
	underlying transport encapsulation. Moreover, this design approach		underlying transport encapsulation. Moreover, this design approach
	encourages consistent SFC-based service delivery in networks enabling		encourages consistent SFC-based service delivery in networks enabling
	distinct transport protocols in various segments of the network or		distinct transport protocols in various network segments or even
	even between SFFs vs SF-SFF hops.		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 [RFC2119] when, and only when, they appear in all capitals,		RFC2119 [RFC2119] when, and only when, they appear in all capitals,
	as shown here.		as shown here.
	1.3. SFC within SR Networks		2. SFC within Segment Routing Networks
	As described in [RFC8402], Segment Routing (SR) leverages the source		As described in [RFC8402], Segment Routing (SR) leverages the source
	routing technique. Concretely, a node steers a packet through an SR		routing technique. Concretely, a node steers a packet through an SR
	policy instantiated as an ordered list of instructions called		policy instantiated as an ordered list of instructions called
	segments. While initially designed for policy-based source routing,		segments. While initially designed for policy-based source routing,
	SR also finds its application in supporting SFC		SR also finds its application in supporting SFC
	[I-D.xuclad-spring-sr-service-programming]. The two SR flavors,		[I-D.ietf-spring-sr-service-programming].
	namely MPLS-SR [RFC8660] and SRv6 [RFC8754], can both encode a
	Service Function (SF) as a segment so that an SFC can be specified as		The two SR flavors, namely SR-MPLS [RFC8660] and SRv6 [RFC8754], can
	a segment list. Nevertheless, and as discussed in [RFC7498], traffic		both encode an SF as a segment so that an SFC can be specified as a
			segment list. Nevertheless, and as discussed in [RFC7498], traffic
	steering is only a subset of the issues that motivated the design of		steering is only a subset of the issues that motivated the design of
	the SFC architecture. Further considerations such as simplifying		the SFC architecture. Further considerations such as simplifying
	classification at intermediate SFs and allowing for coordinated		classification at intermediate SFs and allowing for coordinated
	behaviors among SFs by means of supplying context information should		behaviors among SFs by means of supplying context information
	be taken into account when designing an SFC data plane solution.		(a.k.a., metadata) should be considered when designing an SFC data
			plane solution.
	While each scheme (i.e., NSH-based SFC and SR-based SFC) can work		While each scheme (i.e., NSH-based SFC and SR-based SFC) can work
	independently, this document describes how the two can be used		independently, this document describes how the two can be used
	together in concert and complement each other through two		together in concert and complement each other through two
	representative application scenarios. Both application scenarios may		representative application scenarios. Both application scenarios may
	be supported using either MPLS-SR or SRv6:		be supported using either SR-MPLS or SRv6:
	o NSH-based SFC with SR-based transport plane: in this scenario		o NSH-based SFC with SR-based transport plane: in this scenario SR
	segment routing provides the transport encapsulation between SFFs		provides the transport encapsulation between SFFs while NSH is
	while NSH is used to convey and trigger SFC polices.		used to convey and trigger SFC policies.
	o SR-based SFC with integrated NSH service plane: in this scenario		o SR-based SFC with integrated NSH service plane: in this scenario
	each service hop of the SFC is represented as a segment of the SR		each service hop of the SFC is represented as a segment of the SR
	segment-list. SR is responsible for steering traffic through the		segment-list. SR is thus responsible for steering traffic through
	necessary SFFs as part of the segment routing path and NSH is		the necessary SFFs as part of the segment routing path while NSH
	responsible for maintaining the service plane, and holding the SFC		is responsible for maintaining the service plane and holding the
	instance context and associated metadata.		SFC instance context (including associated metadata).
	It is of course possible to combine both of these two scenarios so as		It is of course possible to combine both of these two scenarios to
	to support specific deployment requirements and use cases.		support specific deployment requirements and use cases.
	A classifier SHOULD assign an NSH Service Path Identifier (SPI) per		A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
	SR policy so that different traffic flows that use the same NSH		SR policy so that different traffic flows that use the same NSH
	Service Function Path (SFP) but different SR policy can coexist on		Service Function Path (SFP) but different SR policy can coexist on
	the same SFP without conflict during SFF processing.		the same SFP without conflict during SFF processing.
	2. NSH-based SFC with SR-based Transport Tunnel		3. NSH-based SFC with SR-based Transport Tunnel
	Because of the transport-independent nature of NSH-based service		Because of the transport-independent nature of NSH-based service
	chains, it is expected that the NSH has broad applicability across		function chains, it is expected that the NSH has broad applicability
	different domains of a network. By way of illustration the various		across different network domains (e.g., access, core). By way of
	SFs involved in a service chain are available in a single data		illustration the various SFs involved in a service chain are
	center, or spread throughout multiple locations (e.g., data centers,		available in a single data center, or spread throughout multiple
	different POPs), depending upon the operator preference and/or		locations (e.g., data centers, different POPs), depending upon the
			operator preference (e.g., hierarchical SFC [RFC8459]) and/or
	availability of service resources. Regardless of where the service		availability of service resources. Regardless of where the service
	resources are deployed it is necessary to provide traffic steering		resources are deployed it is necessary to provide traffic steering
	through a set of SFFs and NSH-based service chains provide the		through a set of SFFs and NSH-based service chains provide the
	flexibility for the network operator to choose which particular		flexibility for the network operator to choose which particular
	transport encapsulation to use between SFFs, which may be different		transport encapsulation to use between SFFs, which may be different
	depending upon which area of the network the SFFs/SFs are currently		depending upon which area of the network the SFFs/SFs are currently
	deployed. Therefore from an SFC architecture perspective, segment		deployed. Therefore from an SFC architecture perspective, segment
	routing is simply one of multiple available transport encapsulations		routing is simply one of multiple available transport encapsulations
	that can be used for traffic steering between SFFs. Concretely, NSH		that can be used for traffic steering between SFFs. Concretely, NSH
	does not require to use a unique transport encapsulation when		does not require to use a unique transport encapsulation when
	traversing a service chain. NSH-based service forwarding relies upon		traversing a service chain. NSH-based service forwarding relies upon
	underlying service node capabilities.		underlying service node capabilities.
	The following three figures provide an example of an SFC established		The following three figures provide an example of an SFC established
	for flow F that has SF instances located in different data centers,		flow F that has SF instances located in different data centers, DC1
	DC1 and DC2. For the purpose of illustration, let the SFC's Service		and DC2. For the purpose of illustration, let the SFC's SPI be 100
	Path Identifier (SPI) be 100 and the initial Service Index (SI) be		and the initial Service Index (SI) be 255.
	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 chain).		(which is the first SFF hop for this service chain).
	After removing the outer transport encapsulation, that may or may not		After removing the outer transport encapsulation, that may or may not
	be MPLS-SR or SRv6, SFF1 uses the SPI and SI carried within the NSH		be SR-MPLS or SRv6, SFF1 uses the SPI and SI carried within the NSH
	encapsulation to determine that it should forward the packet to SF1.		encapsulation to determine that it should forward the packet to SF1.
	SF1 applies its service, decrements the SI by 1, and returns the		SF1 applies its service, decrements the SI by 1, and returns the
	packet to SFF1. SFF1 therefore has <SPI 100, SI 254> when the packet		packet to SFF1. SFF1 therefore has <SPI 100, SI 254> when the packet
	comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254> which		comes back from SF1. SFF1 does a lookup on <SPI 100, SI 254> which
	results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.		results in <next-hop: DC1-GW1> and forwards the packet to DC1-GW1.
	+--------------------------- DC1 ----------------------------+		+--------------------------- DC1 ----------------------------+
	| +-----+ |		| +-----+ |
	| | SF1 | |		| | SF1 | |
	| +--+--+ |		| +--+--+ |
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 35 ¶
	| +------------+ +------------+ |		| +------------+ +------------+ |
	| | N(100,255) | | N(100,254) | |		| | N(100,255) | | N(100,254) | |
	| +------------+ +------------+ |		| +------------+ +------------+ |
	| | F:Inner Pkt| | F:Inner Pkt| |		| | F:Inner Pkt| | F:Inner Pkt| |
	| +------------+ +------------+ |		| +------------+ +------------+ |
	| |		| |
	+------------------------------------------------------------+		+------------------------------------------------------------+
	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 on 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 has the SR segment-list to		encapsulation: SR>. The SR encapsulation has the SR segment-list to
	forward the packet across the inter-DC network to DC2.		forward the packet across the inter-DC network to DC2.
	+----------- Inter DC ----------------+		+----------- Inter DC ----------------+
	| (5) |		| (5) |
	+------+ ----> | +---------+ ----> +---------+ |		+------+ ----> | +---------+ ----> +---------+ |
	| | NSH | | | SR | | |		| | NSH | | | SR | | |
	+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |		+ SFF1 +----------|-+ DC1-GW1 +-------------+ DC2-GW1 + |
	| | | | | | | |		| | | | | | | |
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	| | N(100,254) | |		| | N(100,254) | |
	| +------------+ |		| +------------+ |
	| | F:Inner Pkt| |		| | F:Inner Pkt| |
	| +------------+ |		| +------------+ |
	+-------------------------------------+		+-------------------------------------+
	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. The outer transport encapsulation		which results in next hop: SFF2. The outer transport encapsulation
	may be any transport that is able to identify NSH as the next		may be any transport that is able to identify NSH as the next
	protocol.		protocol.
	+------------------------ DC2 ----------------------+		+------------------------ DC2 ----------------------+
	| +-----+ |		| +-----+ |
	| | SF2 | |		| | SF2 | |
	| +--+--+ |		| +--+--+ |
	| | |		| | |
	| | |		| | |
	| +------------+ | +------------+ |		| +------------+ | +------------+ |
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 42 ¶
	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.		independent nature of the NSH encapsulation.
	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 capability of SR where appropriate.		steering capability of SR where appropriate.
	o Light-weight NSH is used in the data center for SFC and avoids
	more complex hierarchical SFC schemes between data centers.
	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 chain are distributed into multiple domains or		segments of a service chain are distributed into multiple domains or
	where traffic-engineered paths are necessary between SFFs (strict		where traffic-engineered paths are necessary between SFFs (strict
	forwarding paths for example). Further note that the above example		forwarding paths for example). Further note that the above example
	can also be implemented using end to end segment routing between SFF1		can also be implemented using end to end segment routing between SFF1
	and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the packets		and SFF2. (As such DC-GW1 and DC-GW2 are forwarding the packets
	based on segment routing instructions and are not looking at the NSH		based on segment routing instructions and are not looking at the NSH
	header for forwarding).		header for forwarding).
	3. 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		it should not be necessary to implement an SFC proxy to achieve SFC.
	Service Function Chaining. The operation relies upon SR to perform		The operation relies upon SR to perform SFF-SFF transport and NSH to
	SFF-SFF transport and NSH to provide the service plane between SFs		provide the service plane between SFs thereby maintaining SFC context
	thereby maintaining SFC context and metadata.		(e.g., the service plane path referenced by the SPI) and any
			associated metadata.
	When a service chain is established, a packet associated with that		When a service chain is established, a packet associated with that
	chain will first encapsulate an NSH that will be used to maintain the		chain will first carry an NSH that will be used to maintain the end-
	end-to-end service plane through use of the SFC context. The SFC		to-end service plane through use of the SFC context. The SFC context
	context (e.g., the service plane path referenced by the SPI) is used		is used by an SFF to determine the SR segment list for forwarding the
	by an SFF to determine the SR segment list for forwarding the packet		packet to the next-hop SFFs. The packet is then encapsulated using
	to the next-hop SFFs. The packet is then encapsulated using the		the (transport-specific) SR header and forwarded in the SR domain
	(transport-specific) SR header and forwarded in the SR domain		following normal SR operations.
	following normal SR operation.
	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 prefix SID associated with the SF to		SFF performs a lookup on the prefix SID associated with the SF to
	retrieve the next-hop context between the SFF and SF. E.g. to		retrieve the next hop context between the SFF and SF (e.g., to
	retrieve the destination MAC address in case native Ethernet		retrieve the destination MAC address in case native Ethernet
	encapsulation is used between SFF and SF. How the next-hop context		encapsulation is used between SFF and SF). How the next hop context
	is populated is out of the scope of this document. The SFF strips		is populated is out of the scope of this document. The SFF strips
	the SR information of the packet, updates the SR information, and		the SR information of the packet, updates the SR information, and
	saves it to a cache indexed by the NSH SPI. This saved SR		saves it to a cache indexed by the NSH SPI. This saved SR
	information is used to encapsulate and forward the packet(s) coming		information is used to encapsulate and forward the packet(s) coming
	back from the SF.		back from the SF.
	When the SF receives the packet, it processes it as usual and sends		When the SF receives the packet, it processes it as usual and sends
	it back to the SFF. Once the SFF receives this packet, it extracts		it back to the SFF. Once the SFF receives this packet, it extracts
	the SR information using the NSH SPI as the index into the cache.		the SR information using the NSH SPI as the index into the cache.
	The SFF then pushes the SR header on top of the NSH header, and		The SFF then pushes the SR header on top of the NSH header, and
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 47 ¶
	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.
	o It provides a unique and standard way to pass metadata to SFs.		o It provides a unique and standard way to pass metadata to SFs.
	Note that currently there is no solution for MPLS-SR to carry		Note that currently there is no solution for SR-MPLS to carry
	metadata and there is no solution to pass metadata to SR-unaware		metadata and there is no solution to pass metadata to SR-unaware
	SFs.		SFs.
	o SR is also used for forwarding purposes including between SFFs.		o SR is also used for forwarding purposes including between SFFs.
	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 MPLS-SR 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.
	4. Encapsulation Details		5. Encapsulation Details
	4.1. NSH using MPLS-SR Transport		5.1. NSH using SR-MPLS Transport
	MPLS-SR instantiates Segment IDs (SIDs) as MPLS labels and therefore		SR-MPLS instantiates Segment IDs (SIDs) as MPLS labels and therefore
	the segment routing header is a stack of MPLS labels.		the segment routing header is a stack of MPLS labels.
	When carrying NSH within an MPLS-SR transport, the full encapsulation		When carrying NSH within an SR-MPLS transport, the full encapsulation
	headers are as illustrated in Figure 5.		headers are as illustrated in Figure 5.
	+------------------+		+------------------+
	~ MPLS-SR Labels ~		~ MPLS-SR Labels ~
	+------------------+		+------------------+
	| NSH Base Hdr |		| NSH Base Hdr |
	+------------------+		+------------------+
	| Service Path Hdr |		| Service Path Hdr |
	+------------------+		+------------------+
	~ Metadata ~		~ Metadata ~
	+------------------+		+------------------+
	Figure 5: NSH using MPLS-SR 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 MPLS-SR 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 MPLS-SR label stack. This		NSH-based SFC at the tail-end node of the SR-MPLS label stack. This
	is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore		is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore
	the prefix-SID associated with the tail-end of the SFC MUST be		the prefix-SID associated with the tail-end of the SFC MUST be
	advertised with the CONTINUE operation so that the penultimate hop		advertised with the CONTINUE operation so that the penultimate hop
	node does not pop the top label of the MPLS-SR label stack and		node does not pop the top label of the SR-MPLS label stack and
	thereby expose NSH to the wrong SFF. It is RECOMMENDED that a		thereby expose NSH to the wrong SFF. It is RECOMMENDED that a
	specific prefix-SID be allocated at each node for use by the SFC		specific prefix-SID be allocated at each node for use by the SFC
	application for this purpose.		application for this purpose.
	At the end of the MPLS-SR path it is necessary to provide an		At the end of the SR-MPLS path it is necessary to provide an
	indication to the tail-end that NSH follows the MPLS-SR label stack.		indication to the tail-end that NSH follows the SR-MPLS label stack.
	There are several ways to achieve this but its specification is		There are several ways to achieve this but its specification is
	outside the scope of this document.		outside the scope of this document.
	4.2. NSH using SRv6 Transport		5.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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Last Entry | Flags | Tag | S		| Last Entry | Flags | Tag | S
	skipping to change at page 13, line 13 ¶		skipping to change at page 13, line 13 ¶
	Figure 6: NSH using SRv6 Transport		Figure 6: NSH using SRv6 Transport
	Encapsulation of NSH following SRv6 may be indicated either by		Encapsulation of NSH following SRv6 may be indicated either by
	encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the		encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the
	Next Header field of the SRH, or by indicating an IP protocol number		Next Header field of the SRH, or by indicating an IP protocol number
	for NSH in the Next Header of the SRH. The behavior for		for NSH in the Next Header of the SRH. The behavior for
	encapsulating NSH over UDP, including the selection of the source		encapsulating NSH over UDP, including the selection of the source
	port number in particular, adheres to similar considerations as those		port number in particular, adheres to similar considerations as those
	discussed in [RFC8086].		discussed in [RFC8086].
	5. Security Considerations		6. Security Considerations
	Generic SFC-related security considerations are discussed in		Generic SFC-related security considerations are discussed in
	[RFC7665]. NSH-specific security considerations are discussed in		[RFC7665].
	[RFC8300]. NSH-in-UDP with DTLS [RFC6347] should follow the
	considerations discussed in Section 5 of [RFC8086], with a
	destination port number set to TBA2
	6. IANA Considerations		NSH-specific security considerations are discussed in [RFC8300].
	6.1. UDP Port Number for NSH		NSH-in-UDP with DTLS [RFC6347] should follow the considerations
			discussed in Section 5 of [RFC8086], with a destination port number
			set to TBA2.
			Generic segment routing related security considerations are discussed
			in section 7 of [RFC8754] and section 5 of [RFC8663].
			7. IANA Considerations
			7.1. UDP Port Number for NSH
	IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the NSH from the "Service Name and Transport Protocol Port Number Registry" available at		IANA is requested to assign the UDP port numbers TBA1 and TBA2 to the NSH from the "Service Name and Transport Protocol Port Number Registry" available at
	https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml:		https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml:
	Service Name: NSH-in-UDP		Service Name: NSH-in-UDP
	Transport Protocol(s): UDP		Transport Protocol(s): UDP
	Assignee: IESG iesg@ietf.org		Assignee: IESG iesg@ietf.org
	Contact: IETF Chair chair@ietf.org		Contact: IETF Chair chair@ietf.org
	Description: NSH-in-UDP Encapsulation		Description: NSH-in-UDP Encapsulation
	Reference: [ThisDocument]		Reference: [ThisDocument]
	Port Number: TBA1		Port Number: TBA1
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 28 ¶
	Service Name: NSH-UDP-DTLS		Service Name: NSH-UDP-DTLS
	Transport Protocol(s): UDP		Transport Protocol(s): UDP
	Assignee: IESG iesg@ietf.org		Assignee: IESG iesg@ietf.org
	Contact: IETF Chair chair@ietf.org		Contact: IETF Chair chair@ietf.org
	Description: NSH-in-UDP with DTLS Encapsulation		Description: NSH-in-UDP with DTLS Encapsulation
	Reference: [ThisDocument]		Reference: [ThisDocument]
	Port Number: TBA2		Port Number: TBA2
	Service Code: N/A		Service Code: N/A
	Known Unauthorized Uses: N/A		Known Unauthorized Uses: N/A
	Assignment Notes: N/A		Assignment Notes: N/A
	6.2. Protocol Number for NSH
			7.2. Protocol Number for NSH
	IANA is requested to assign a protocol number TBA3 for the NSH from the "Assigned Internet Protocol Numbers" registry available at		IANA is requested to assign a protocol number TBA3 for the NSH from the "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 | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	| TBA3 | NSH | Network | N | [ThisDocument] |		| TBA3 | NSH | Network | N | [ThisDocument] |
	| | | Service | | |		| | | Service | | |
	| | | Header | | |		| | | Header | | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	7. Acknowledgments		8. Contributing Authors
			The following coauthors, along with their respective affiliations at
			the time of WG adoption, provided valuable inputs and text contributions
			to this document.
	TBD.		Mohamed Boucadair
			Orange
	8. References		mohamed.boucadair@orange.com
	8.1. Normative References		Joel Halpern
			Ericsson
	[I-D.ietf-spring-segment-routing-mpls]		joel.halpern@ericsson.com
	Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Syed Hassan
	data plane", draft-ietf-spring-segment-routing-mpls-12		Cisco System, inc.
	(work in progress), February 2018.
			shassan@cisco.com
			Wim Henderickx
			Nokia
			wim.henderickx@nokia.com
			Haoyu Song
			Futurewei Technologies
			haoyu.song@futurewei.com
			9. References
			9.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>.
	[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>.
	skipping to change at page 15, line 21 ¶		skipping to change at page 16, line 25 ¶
	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>.
	[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,		[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing with the MPLS Data Plane", RFC 8660,		Routing with the MPLS Data Plane", RFC 8660,
	DOI 10.17487/RFC8660, December 2019,		DOI 10.17487/RFC8660, December 2019,
	<https://www.rfc-editor.org/info/rfc8660>.		<https://www.rfc-editor.org/info/rfc8660>.
			[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
			W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
			DOI 10.17487/RFC8663, December 2019,
			<https://www.rfc-editor.org/info/rfc8663>.
	[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>.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	Field, B., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	Header (SRH)", draft-ietf-6man-segment-routing-header-09
	(work in progress), March 2018.
	[I-D.xuclad-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-xuclad-spring-sr-service-		Segment Routing", draft-ietf-spring-sr-service-
	programming-02 (work in progress), April 2019.		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,
	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>.
			[RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair,
			"Hierarchical Service Function Chaining (hSFC)", RFC 8459,
			DOI 10.17487/RFC8459, September 2018,
			<https://www.rfc-editor.org/info/rfc8459>.
	Authors' Addresses		Authors' Addresses
	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
	Haoyu Song		Jeff Tantsura (editor)
	Futurewei Technologies
	2330 Central Express Way
	Santa Clara
	USA
	Email: haoyu.song@futurewei.com
	Jeff Tantsura
	Apstra inc.		Apstra inc.
	USA		USA
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Joel Halpern
	Ericsson
	USA
	Email: joel.halpern@ericsson.com
	Wim Henderickx
	Nokia
	USA
	Email: wim.henderickx@nokia.com
	Mohamed Boucadair
	Orange
	USA
	Email: mohamed.boucadair@orange.com
	Syed Hassan
	Cisco Systems
	USA
	Email: shassan@cisco.com
End of changes. 60 change blocks.
	179 lines changed or deleted		179 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/