< draft-ietf-spring-nsh-sr-01.txt		draft-ietf-spring-nsh-sr-02.txt >
	SPRING J. Guichard, Ed.		SPRING J. Guichard, Ed.
	Internet-Draft H. Song		Internet-Draft H. Song
	Intended status: Standards Track Futurewei Technologies		Intended status: Standards Track Futurewei Technologies
	Expires: April 6, 2020 J. Tantsura		Expires: October 8, 2020 J. Tantsura
	Apstra inc.		Apstra inc.
	J. Halpern		J. Halpern
	Ericsson		Ericsson
	W. Henderickx		W. Henderickx
	Nokia		Nokia
	M. Boucadair		M. Boucadair
	Orange		Orange
	S. Hassan		S. Hassan
	Cisco Systems		Cisco Systems
	October 4, 2019		April 6, 2020
	Network Service Header (NSH) and Segment Routing Integration for Service		Network Service Header (NSH) and Segment Routing Integration for Service
	Function Chaining (SFC)		Function Chaining (SFC)
	draft-ietf-spring-nsh-sr-01		draft-ietf-spring-nsh-sr-02
	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) techniques can be
	deployed together to support Service Function Chaining (SFC) in an		deployed together to support Service Function Chaining (SFC) in an
	efficient manner while maintaining separation of the service and		efficient manner while maintaining separation of the service and
	transport planes as originally intended by the SFC architecture.		transport planes as originally intended by the SFC architecture.
	In the first scenario, an NSH-based SFC is created using SR as the		In the first scenario, an NSH-based SFC is created using SR as the
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 April 6, 2020.		This Internet-Draft will expire on October 8, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 3, line 7 ¶		skipping to change at page 3, line 7 ¶
	4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11		4.1. NSH using MPLS-SR Transport . . . . . . . . . . . . . . . 11
	4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12		4.2. NSH using SRv6 Transport . . . . . . . . . . . . . . . . 12
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13		6.1. UDP Port Number for NSH . . . . . . . . . . . . . . . . . 13
	6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14		6.2. Protocol Number for NSH . . . . . . . . . . . . . . . . . 14
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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, for example at the Gi interface in the
	context of mobile network infrastructure, have shown their limits,		context of mobile network infrastructure, have shown their limits,
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 30 ¶
	as shown here.		as shown here.
	1.3. SFC within SR Networks		1.3. SFC within SR 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.xuclad-spring-sr-service-programming]. The two SR flavors,
	namely MPLS-SR [I-D.ietf-spring-segment-routing-mpls] and SRv6		namely MPLS-SR [RFC8660] and SRv6 [RFC8754], can both encode a
	[I-D.ietf-6man-segment-routing-header], can both encode a Service		Service Function (SF) as a segment so that an SFC can be specified as
	Function (SF) as a segment so that an SFC can be specified as a		a segment list. Nevertheless, and as discussed in [RFC7498], traffic
	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 should
	be taken into account when designing an SFC data plane solution.		be taken into account 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
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 15 ¶
	[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>.
			[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
			Decraene, B., Litkowski, S., and R. Shakir, "Segment
			Routing with the MPLS Data Plane", RFC 8660,
			DOI 10.17487/RFC8660, December 2019,
			<https://www.rfc-editor.org/info/rfc8660>.
			[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
			Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
			(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
			<https://www.rfc-editor.org/info/rfc8754>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-6man-segment-routing-header]		[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,		Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	Field, B., daniel.voyer@bell.ca, d.,		Field, B., daniel.voyer@bell.ca, d.,
	daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,		daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,		Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing		D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	Header (SRH)", draft-ietf-6man-segment-routing-header-09		Header (SRH)", draft-ietf-6man-segment-routing-header-09
	(work in progress), March 2018.		(work in progress), March 2018.
End of changes. 8 change blocks.
	10 lines changed or deleted		20 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/