< draft-ietf-spring-nsh-sr-07.txt		draft-ietf-spring-nsh-sr-08.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 24, 2021 Apstra inc.		Expires: December 31, 2021 Apstra inc.
	June 22, 2021		June 29, 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-07		draft-ietf-spring-nsh-sr-08
	Abstract		Abstract
	This document describes the integration of Network Service Header		This document describes the integration of 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.
	The integration described in this document demonstrates that NSH and		This integration demonstrates that NSH and SR can work cooperatively
	SR can work jointly and complement each other leaving the network		and provide the network operator with the flexibility to use
	operator with the flexibility to use whichever transport technology		whichever transport technology makes sense in specific areas of their
	makes sense in specific areas of their network infrastructure, and		network infrastructure while still maintaining an end-to-end service
	still maintain an end-to-end service plane using NSH.		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
	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 24, 2021.		This Internet-Draft will expire on December 31, 2021.
	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
	skipping to change at page 2, line 52 ¶		skipping to change at page 2, line 52 ¶
	11.2. Informative References . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		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 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.
	Particularly, cascading SFs at the so-called Third Generation		For instance, cascading SFs at the 3GPP (Third Generation Partnership
	Partnership Project (3GPP) Gi interface (N6 interface in 5G		Project) Gi interface (N6 interface in 5G architecture) has shown
	architecture) in the context of mobile network infrastructure, have		limitations such as 1) redundant classification features must be
	shown their limitations, such as the same redundant classification		supported by many SFs to execute their function, 2) some SFs receive
	features must be supported by many SFs to execute their function,		traffic that they are not supposed to process (e.g., TCP proxies
	some SFs receive traffic that they are not supposed to process (e.g.,		receiving UDP traffic) which inevitably affects their dimensioning
	TCP proxies receiving UDP traffic), which inevitably affects their		and performance, and 3) an increased design complexity related to the
	dimensioning and performance, an increased design complexity related		properly ordered invocation of several SFs.
	to the properly ordered invocation of several SFs, etc.
	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 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. SFC allows to dynamically create service planes that
	planes that can be used by specific traffic flows. Each service		can be used by specific traffic flows. Each service plane is
	plane is realized by invoking and chaining the relevant service		realized by invoking and chaining the relevant service functions in
	functions in the right sequence. [RFC7498] provides an overview of		the right sequence. [RFC7498] provides an overview of the overall
	the overall SFC problem space and [RFC7665] specifies an SFC data		SFC problem space and [RFC7665] specifies an SFC data plane
	plane architecture. The SFC architecture does not make assumptions		architecture. The SFC architecture does not make assumptions on how
	on how advanced features (e.g., load-balancing, loose or strict		advanced features (e.g., load-balancing, loose or strict service
	service paths) could be enabled within a domain. Various deployment		paths) could be enabled within a domain. Various deployment options
	options are made available to operators with the SFC architecture and		are made available to operators with the SFC architecture and this
	this approach is fundamental to accommodate various and heterogeneous		approach is fundamental to accommodate various and heterogeneous
	deployment contexts.		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
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 44 ¶
	Service Path Identifier (SPI) and the Service Index (SI) decremented		Service Path Identifier (SPI) and the Service Index (SI) decremented
	by 1. This saved SR information is used to encapsulate and forward		by 1. This saved SR information is used to encapsulate and forward
	the packet(s) coming back from the SF.		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 and sends		When the SF receives the packet, it processes it as usual. The SF
	it back to the SFF. Once the SFF receives this packet, it extracts		may use a Classifier to re-classify the already processed packet.
	the SR information using the NSH SPI and SI as the index into the		The SF sends the packet back to the SFF. Once the SFF receives this
	cache. The SFF then pushes the retrieved SR header on top of the NSH		packet, it extracts the SR information using the NSH SPI and SI as
	header, and forwards the packet to the next segment in the segment-		the index into the cache. The SFF then pushes the retrieved SR
	list.		header on top of the NSH header, and forwards the packet to the next
			segment in the segment-list. The lookup in the SFF cache might fail
			if re-classification changed NSH SPI and/or SI values. In such a
			case, SFF must prepare the new SR header to push on top of NSH before
			forwarding 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) | | |F:Inner Pkt| |N(100,254) | | |F:Inner Pkt|
End of changes. 8 change blocks.
	35 lines changed or deleted		38 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/