< draft-cheng-spring-mpls-path-segment-00.txt		draft-cheng-spring-mpls-path-segment-01.txt >
	Network Working Group W. Cheng		Network Working Group W. Cheng
	Internet-Draft L. Wang		Internet-Draft L. Wang
	Intended status: Standards Track H. Li		Intended status: Standards Track H. Li
	Expires: May 3, 2018 China Mobile		Expires: September 3, 2018 China Mobile
	M. Chen		M. Chen
	Huawei		Huawei
	R. Zigler		R. Zigler
	Broadcom		Broadcom
	S. Zhan		S. Zhan
	ZTE		ZTE
	October 30, 2017		March 2, 2018
	Path Segment in MPLS Based Sement Routing Network		Path Segment in MPLS Based Sement Routing Network
	draft-cheng-spring-mpls-path-segment-00		draft-cheng-spring-mpls-path-segment-01
	Abstract		Abstract
	An SR path is identified by an SR segment list, one or partial		An SR path is identified by an SR segment list, one or partial
	segments of the list cannot uniquely identify the SR path.		segments of the list cannot uniquely identify the SR path.
	This document introduces the concept of Path Segment that is used to		This document introduces the concept of Path Segment that is used to
	identify an SR path. When used, it is inserted at the ingress node		identify an SR path. When used, it is inserted at the ingress node
	of the SR path and immediately follows the last segment of the SR		of the SR path and immediately follows the last segment of the SR
	path. The Path Segment will not be popped off until it reaches the		path. The Path Segment will not be popped off until it reaches the
	egress of the SR path, it can be used by the egress node to implement		egress of the SR path, it can be used by the egress node to implement
	end-2-end SR path protection or performance measurement (PM) of an SR		end-2-end SR path protection or performance measurement (PM)
	path.		(especially for measuring packet loss of real traffic) of an SR path.
	Requirements Language		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", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 7 ¶		skipping to change at page 2, line 7 ¶
	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 May 3, 2018.		This Internet-Draft will expire on September 3, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. One Label Solution . . . . . . . . . . . . . . . . . . . 3		2.1. One Label Solution . . . . . . . . . . . . . . . . . . . 3
	2.1.1. Path Segment Assignment . . . . . . . . . . . . . . . 4		2.1.1. Path Segment Assignment . . . . . . . . . . . . . . . 4
	2.2. Two Labels Solution . . . . . . . . . . . . . . . . . . . 5		2.2. Two Labels Solution . . . . . . . . . . . . . . . . . . . 5
	3. Path Segment Application . . . . . . . . . . . . . . . . . . 7		3. Path Segment Application . . . . . . . . . . . . . . . . . . 7
	3.1. Performance Measurement . . . . . . . . . . . . . . . . . 7		3.1. Packet Loss Measurement for Real Traffic . . . . . . . . 7
	3.2. End-2-end Path Protection . . . . . . . . . . . . . . . . 7		3.2. End-2-end Path Protection . . . . . . . . . . . . . . . . 7
	3.3. Bi-directional SR Tunnel . . . . . . . . . . . . . . . . 8		3.3. Bi-directional SR Tunnel . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	or ingress node of an SR path, or within an SR domain). It is		or ingress node of an SR path, or within an SR domain). It is
	normally used by egress nodes for path identification or correlation.		normally used by egress nodes for path identification or correlation.
	Path Segment can only apply to SR-MPLS.		Path Segment can only apply to SR-MPLS.
	2. Path Segment		2. Path Segment
	This document introduces two options for SR path identification: one		This document introduces two options for SR path identification: one
	label solution and two labels solution.		label solution and two labels solution.
	[Editor notes: it is supposed that the WG will discuss and decide		[Editor notes: it is supposed that the WG will discuss and decide
	which one is the better solution.]		which one is preffered.]
	2.1. One Label Solution		2.1. One Label Solution
	The Path Segment is a single label that is assigned from the Segment		The Path Segment is a single label that is assigned from the Segment
	Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of		Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of
	the egress node of an SR path. It means that the Path Segment is		the egress node of an SR path. It means that the Path Segment is
	unique in the context of the egress node of SR paths. When Path		unique in the context of the egress node of SR paths. When Path
	Segment is used, a Path label MUST be inserted at the ingress node		Segment is used, a Path label MUST be inserted at the ingress node
	and MUST immediately follow the last label of the SR path.		and MUST immediately follow the last label of the SR path.
	skipping to change at page 5, line 12 ¶		skipping to change at page 5, line 12 ¶
	computed, the PCE will send a request (with computed path and		computed, the PCE will send a request (with computed path and
	relevant information) to the egress node to ask for a Path label for		relevant information) to the egress node to ask for a Path label for
	the SR path. The egress node will allocate a label to the SR path		the SR path. The egress node will allocate a label to the SR path
	and build mapping relationship between the label and the path. A		and build mapping relationship between the label and the path. A
	reply will be sent back to the PCE, the PCE will send a reply to the		reply will be sent back to the PCE, the PCE will send a reply to the
	ingress node about the path information and the corresponding Path		ingress node about the path information and the corresponding Path
	Segment label.		Segment label.
	With either way or the variations, the final purpose is to assign a		With either way or the variations, the final purpose is to assign a
	label from the egress node's label space, hence a single label is		label from the egress node's label space, hence a single label is
	enough for path identification. Then the ingress node can put the		enough for path identification. Then the ingress node can insert the
	Path Segment label into the label stack when needed, and the egress		Path Segment label into the label stack when needed, and the egress
	node can use that Path Segment to implement relevant functionalities.		node can use that Path Segment to implement relevant functionalities.
	2.2. Two Labels Solution		2.2. Two Labels Solution
	Two segments (Source segment and Path segment) are used to identify		Two segments (Source segment and Path segment) are used to identify
	an SR path. The Source segment is a global node segment, it can		an SR path. The Source segment is a global node segment, it can
	uniquely identify a node within an SR domain. It MUST NOT be used		uniquely identify a node within an SR domain. It MUST NOT be used
	for forwarding and indicates that a Path segment immediately follows.		for forwarding and indicates that a Path segment immediately follows.
	The Path segment is a local segment generated at the ingress node to		The Path segment is a local segment generated at the ingress node to
	identify an SR path. The combination of Source segment and Path		identify an SR path. The combination of Source segment and Path
	segment can uniquely identify an SR Path with an SR domain.		segment can uniquely identify an SR Path with an SR domain.
	A node that enables Path segment function will be assigned two node		A node that enables Path segment function will be assigned two node
	segments. One is for forwarding just as defined in		segments. One is for forwarding just as defined in
	[I-D.ietf-spring-segment-routing], the other is for source		[I-D.ietf-spring-segment-routing], the other is for source
	identification. The corresponding label of the Source Segment is		identification. The corresponding label of the Source Segment is
	indexed in the SRGB (or in a of the node to which the Source Segment		indexed in the SRGB of the node to which the Source Segment will be
	will be presented.		presented.
	The Path segment label is a local label that is assigned to an SR		The Path segment label is a local label that is assigned to an SR
	path at the ingress node.		path at the ingress node.
	The label stack with Source and Path segments is as below (Figure 2):		The label stack with Source and Path segments is as below (Figure 2):
	+--------------------+		+--------------------+
	| ... |		| ... |
	+--------------------+		+--------------------+
	| Label 1 |		| Label 1 |
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	Segment are presented.		Segment are presented.
	If a node receives a packet with an unknown Source Label, the packet		If a node receives a packet with an unknown Source Label, the packet
	MUST be discarded and an error SHOULD be reported.		MUST be discarded and an error SHOULD be reported.
	The Source label and Path label MUST be popped at the node who		The Source label and Path label MUST be popped at the node who
	receives a packet with the Source label as the stack top label.		receives a packet with the Source label as the stack top label.
	3. Path Segment Application		3. Path Segment Application
	3.1. Performance Measurement		3.1. Packet Loss Measurement for Real Traffic
	To measure the packet loss and delay of the real traffic of an SR
	path, one fundamental condition is path identification at the
	measuring points. For an SR path, the ingress node have the complete
	information of the path, it can use those information for packet
	counting and/or timestamping. At the egress node, since the Path
	Segment label (or combination with Source label) can be used to
	identify the path, path based packet counting and/or timestamping can
	be implemented as well. Then combined with the mechanisms defined
	[RFC6374], end-2-end packet loss and/or delay measurement of an SR
	path can be achieved.
	Measuring at intermediate nodes needs more consideration, it will be		Measuring packet loss of real traffic is called "direct mode" packet
	added in the next version.		loss measurement in [RFC6374], it is sometime called passive
			measurement as well. To measure the packet loss of the real traffic
			of an SR path, one fundamental condition is path identification at
			the measuring points. For an SR path, the ingress node have the
			complete information of the path, it can use those information for
			packet counting. At the egress node, since the Path Segment label
			(or combination with Source label) can be used to identify the path,
			path based packet counting can be implemented as well. Then combined
			with the mechanisms defined in [RFC6374], end-2-end packet loss
			measurement of an SR path can be achieved.
	3.2. End-2-end Path Protection		3.2. End-2-end Path Protection
	For end-2-end 1+1 path protection, the egress node of an path needs		For end-2-end 1+1 path protection, the egress node of an path needs
	to know the set of paths that constitute the primary and the		to know the set of paths that constitute the primary and the
	backup(s), in order to select the primary packet for onward		backup(s), in order to select the primary packet for onward
	transmission, and to discard the packets from the backups.		transmission, and to discard the packets from the backups.
	To do this each path needs a path identifier that is unique at the		To do this each path needs a path identifier that is unique at the
	egress node. Depending on the design, this single unique label		egress node. Depending on the design, this single unique label
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 5 ¶
	is advertised as primary and the others as secondary will or all are		is advertised as primary and the others as secondary will or all are
	advertised as of equal status will depend on the details of the		advertised as of equal status will depend on the details of the
	underlying protection mechanism.		underlying protection mechanism.
	3.3. Bi-directional SR Tunnel		3.3. Bi-directional SR Tunnel
	With the current SR architecture, an SR path is an unidirectional		With the current SR architecture, an SR path is an unidirectional
	path. In some scenarios, for example, mobile backhaul transport		path. In some scenarios, for example, mobile backhaul transport
	network, there are requirements to support bi-directional path, and		network, there are requirements to support bi-directional path, and
	the path is normally treated as a single entity and both directions		the path is normally treated as a single entity and both directions
	of the path have same fate, for example, failure in one direction		of the path have the same fate, for example, failure in one direction
	will result in switching at both directions.		will result in switching at both directions.
	MPLS supports this by introducing the concepts of co-routed		MPLS supports this by introducing the concepts of co-routed
	bidirectional LSP and associated bi-directional LSP. With SR, to		bidirectional LSP and associated bi-directional LSP. With SR, to
	support bidirectional path, a straightforward way is to bind two		support bidirectional path, a straightforward way is to bind two
	unidirectional SR paths to a single bi-directional path. Path		unidirectional SR paths to a single bi-directional path. Path
	segments can be used to correlate the two unidirectional SR paths at		segments can be used to correlate the two unidirectional SR paths at
	both ends of the paths.		both ends of the paths.
	4. IANA Considerations		4. IANA Considerations
	skipping to change at page 9, line 6 ¶		skipping to change at page 8, line 42 ¶
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Stewart Bryant for his review,		The authors would like to thank Stewart Bryant for his review,
	suggestion and comments to this document.		suggestion and comments to this document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-6man-segment-routing-header]		[I-D.ietf-6man-segment-routing-header]
	Previdi, S., Filsfils, C., Raza, K., Leddy, J., Field, B.,		Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
	daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,		Field, B., daniel.voyer@bell.ca, d.,
	Matsushima, S., Leung, I., Linkova, J., Aries, E., Kosugi,		daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
	T., Vyncke, E., Lebrun, D., Steinberg, D., and R. Raszuk,		Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
	"IPv6 Segment Routing Header (SRH)", draft-ietf-6man-		D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
	segment-routing-header-07 (work in progress), July 2017.		Header (SRH)", draft-ietf-6man-segment-routing-header-08
			(work in progress), January 2018.
	[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>.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-13 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), October 2017.		in progress), January 2018.
	[I-D.ietf-spring-segment-routing-mpls]		[I-D.ietf-spring-segment-routing-mpls]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,		Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing with MPLS		Litkowski, S., and R. Shakir, "Segment Routing with MPLS
	data plane", draft-ietf-spring-segment-routing-mpls-10		data plane", draft-ietf-spring-segment-routing-mpls-12
	(work in progress), June 2017.		(work in progress), February 2018.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay		[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374,		Measurement for MPLS Networks", RFC 6374,
	DOI 10.17487/RFC6374, September 2011,		DOI 10.17487/RFC6374, September 2011,
	<https://www.rfc-editor.org/info/rfc6374>.		<https://www.rfc-editor.org/info/rfc6374>.
	Authors' Addresses		Authors' Addresses
	Weiqiang Cheng		Weiqiang Cheng
	China Mobile		China Mobile
End of changes. 18 change blocks.
	39 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/