< draft-ietf-spring-nsh-sr-04.txt		draft-ietf-spring-nsh-sr-05.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: June 14, 2021 Apstra inc.		Expires: November 8, 2021 Apstra inc.
	December 11, 2020		May 7, 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-04		draft-ietf-spring-nsh-sr-05
	Abstract		Abstract
	This document describes the integration of Network Service Header		This document describes the integration of Network Service Header
	(NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as		(NSH) [RFC8300] and Segment Routing (SR) [RFC8402], as well as
	encapsulation details, to support Service Function Chaining (SFC)		encapsulation details, to support Service Function Chaining (SFC)
	[RFC7665] in an efficient manner while maintaining separation of the		[RFC7665] in an efficient manner while maintaining separation of the
	service and transport planes as originally intended by the SFC		service and transport planes as originally intended by the SFC
	architecture.		architecture.
	skipping to change at page 1, line 49 ¶		skipping to change at page 1, line 49 ¶
	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 June 14, 2021.		This Internet-Draft will expire on November 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2		1.1. SFC Overview and Rationale . . . . . . . . . . . . . . . 2
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	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 Details . . . . . . . . . . . . . . . . . . 11		5. Packet Processing Details . . . . . . . . . . . . . . . . . . 11
	6. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11		6. Encapsulation Details . . . . . . . . . . . . . . . . . . . . 11
	6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11		6.1. NSH using SR-MPLS Transport . . . . . . . . . . . . . . . 11
	6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12		6.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 15		9.1. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14
	8.3. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 15		9.2. SRv6 Endpoint Behavior for NSH . . . . . . . . . . . . . 14
	9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15		10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10.2. Informative References . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		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		Particularly, cascading SFs at the so-called Third Generation
	Partnership Project (3GPP) Gi interface (N6 interface in 5G		Partnership Project (3GPP) Gi interface (N6 interface in 5G
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	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
	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 SR-MPLS label stack and		node does not pop the top label of the SR-MPLS label stack and
	thereby expose NSH to the wrong SFF. This is realized by setting No-		thereby expose NSH to the wrong SFF. This is realized by setting No-
	PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is		PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665]. It is
	RECOMMENDED that a specific prefix-SID be allocated at each node for		RECOMMENDED that a specific prefix-SID be allocated at each node for
	use by the SFC application for this purpose.		use by the SFC application for this purpose.
	At the end of the SR-MPLS path it is necessary to provide an		Alternatively, if NEXT operation is performed, then at the end of the
	indication to the tail-end that NSH follows the SR-MPLS label stack		SR-MPLS path it is necessary to provide an indication to the tail-end
	as described by [RFC8596].		that NSH follows the SR-MPLS label stack as described by [RFC8596].
	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 13, line 43 ¶		skipping to change at page 13, line 43 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ N
	| Service Path Identifier | Service Index | S		| Service Path Identifier | Service Index | S
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ H
	| |		| |
	~ Variable-Length Context Headers (opt.) ~		~ Variable-Length Context Headers (opt.) ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	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 is indicated by the IP protocol
	encapsulating NSH in UDP (UDP port TBA1) and indicating UDP in the		number for NSH in the Next Header of the SRH.
	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
	encapsulating NSH over UDP, including the selection of the source
	port number in particular, adheres to similar considerations as those
	discussed in [RFC8086].
	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].
	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		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. IANA Considerations		8. MTU Considerations
	8.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
	https://www.iana.org/assignments/service-names-port-numbers/
	service-names-port-numbers.xhtml:
	Service Name: NSH-in-UDP		Aligned with Section 5 of [RFC8300] and Section 5.3 of [RFC8754], it
	Transport Protocol(s): UDP		is RECOMMENDED for network operators to increase the underlying MTU
	Assignee: IESG iesg@ietf.org		so that SR/NSH traffic is forwarded within an SR domain without
	Contact: IETF Chair chair@ietf.org		fragmentation.
	Description: NSH-in-UDP Encapsulation
	Reference: [ThisDocument]
	Port Number: TBA1
	Service Code: N/A
	Known Unauthorized Uses: N/A
	Assignment Notes: N/A
	Service Name: NSH-UDP-DTLS		9. IANA Considerations
	Transport Protocol(s): UDP
	Assignee: IESG iesg@ietf.org
	Contact: IETF Chair chair@ietf.org
	Description: NSH-in-UDP with DTLS Encapsulation
	Reference: [ThisDocument]
	Port Number: TBA2
	Service Code: N/A
	Known Unauthorized Uses: N/A
	Assignment Notes: N/A
	8.2. Protocol Number for NSH		9.1. Protocol Number for NSH
	IANA is requested to assign a protocol number TBA3 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 | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	| TBA3 | NSH | Network | N | [ThisDocument] |		| TBA1 | NSH | Network | N | [ThisDocument] |
	| | | Service | | |		| | | Service | | |
	| | | Header | | |		| | | Header | | |
	+---------+---------+--------------+---------------+----------------+		+---------+---------+--------------+---------------+----------------+
	8.3. SRv6 Endpoint Behavior for NSH		9.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
	--------------------------------------------------------------		--------------------------------------------------------------
	TBA4 End.NSH - NSH Segment [This.ID]		TBA2 End.NSH - NSH Segment [This.ID]
	9. Contributing Authors		10. 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 WG adoption, 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
	skipping to change at page 16, line 28 ¶		skipping to change at page 15, 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
	10. References		11. References
	10.1. Normative References		11.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 18, line 5 ¶		skipping to change at page 17, line 5 ¶
	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>.
	10.2. Informative References		11.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,
End of changes. 20 change blocks.
	67 lines changed or deleted		35 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/