draft-kumarkini-mpls-spring-lsp-ping-05.txt		draft-kumarkini-mpls-spring-lsp-ping-06.txt
	Network Work group N. Kumar		Network Work group N. Kumar
	Internet-Draft G. Swallow		Internet-Draft G. Swallow
	Intended status: Standards Track C. Pignataro		Intended status: Standards Track C. Pignataro
	Expires: August 3, 2016 Cisco Systems, Inc.		Expires: September 22, 2016 Cisco Systems, Inc.
	N. Akiya		N. Akiya
	Big Switch Networks		Big Switch Networks
	S. Kini		S. Kini
	Individual		Individual
	H. Gredler		H. Gredler
	Juniper Networks		Juniper Networks
	M. Chen		M. Chen
	Huawei		Huawei
	January 31, 2016		March 21, 2016
	Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using		Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using
	MPLS Dataplane		MPLS Dataplane
	draft-kumarkini-mpls-spring-lsp-ping-05		draft-kumarkini-mpls-spring-lsp-ping-06
	Abstract		Abstract
	Segment Routing architecture leverages the source routing and		Segment Routing architecture leverages the source routing and
	tunneling paradigms and can be directly applied to MPLS data plane.		tunneling paradigms and can be directly applied to MPLS data plane.
	A node steers a packet through a controlled set of instructions		A node steers a packet through a controlled set of instructions
	called segments, by prepending the packet with a Segment Routing		called segments, by prepending the packet with a Segment Routing
	header.		header.
	The segment assignment and forwarding semantic nature of Segment		The segment assignment and forwarding semantic nature of Segment
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 August 3, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 30 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Challenges with Existing mechanism . . . . . . . . . . . . . 4		4. Challenges with Existing mechanism . . . . . . . . . . . . . 4
	4.1. Path validation in Segment Routing networks . . . . . . . 4		4.1. Path validation in Segment Routing networks . . . . . . . 4
	4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Service Label . . . . . . . . . . . . . . . . . . . . . . 5
	5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5		5. Segment ID sub-TLV . . . . . . . . . . . . . . . . . . . . . 5
	5.1. IPv4 Prefix Node Segment ID . . . . . . . . . . . . . . . 5		5.1. IPv4 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 5
	5.2. IPv6 Prefix Node Segment ID . . . . . . . . . . . . . . . 6		5.2. IPv6 IGP-Prefix Segment ID . . . . . . . . . . . . . . . 6
	5.3. IGP Adjacency Segment ID . . . . . . . . . . . . . . . . 7		5.3. IGP-Adjacency Segment ID . . . . . . . . . . . . . . . . 7
	6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8		6. Extension to Downstream Mapping TLV . . . . . . . . . . . . . 8
	7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9		7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9		7.1. FECs in Target FEC Stack TLV . . . . . . . . . . . . . . 9
	7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10		7.2. FEC Stack Change sub-TLV . . . . . . . . . . . . . . . . 10
	7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10		7.3. Segment ID POP Operation . . . . . . . . . . . . . . . . 10
	7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10		7.4. Segment ID Check . . . . . . . . . . . . . . . . . . . . 10
	7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12		7.5. TTL Consideration for traceroute . . . . . . . . . . . . 12
	8. Issues with non-forwarding labels . . . . . . . . . . . . . . 12		8. Issues with non-forwarding labels . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. Backward Compatibility with non Segment Routing devices . . . 13
	9.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . . 13		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 13		10.1. New Target FEC Stack Sub-TLVs . . . . . . . . . . . . . 13
	11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	12. Contributing Authors . . . . . . . . . . . . . . . . . . . . 13		12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		13. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14
	13.1. Normative References . . . . . . . . . . . . . . . . . . 14		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	13.2. Informative References . . . . . . . . . . . . . . . . . 15		14.1. Normative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		14.2. Informative References . . . . . . . . . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	[I-D.ietf-spring-segment-routing] introduces and explains Segment		[I-D.ietf-spring-segment-routing] introduces and explains Segment
	Routing architecture that leverages the source routing and tunneling		Routing architecture that leverages the source routing and tunneling
	paradigms. A node steers a packet through a controlled set of		paradigms. A node steers a packet through a controlled set of
	instructions called segments, by prepending the packet with Segment		instructions called segments, by prepending the packet with Segment
	Routing header. A detailed definition about Segment Routing		Routing header. A detailed definition about Segment Routing
	architecture is available in [I-D.ietf-spring-segment-routing] and		architecture is available in [I-D.ietf-spring-segment-routing]
	different use-cases are discussed in
	[I-D.filsfils-spring-segment-routing-use-cases]
	The Segment Routing architecture can be directly applied to MPLS data		As defined in [I-D.ietf-spring-segment-routing-mpls], the Segment
	plane in a way that, the Segment identifier (Segment ID) will be of		Routing architecture can be directly applied to MPLS data plane in a
	20-bits size and Segment Routing header is the label stack.		way that, the Segment identifier (Segment ID) will be of 20-bits size
			and Segment Routing header is the label stack.
	Multi Protocol Label Switching (MPLS) has defined in [RFC4379] a		"Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"
	simple and efficient mechanism to detect data plane failures in Label		[RFC4379] defines a simple and efficient mechanism to detect data
	Switched Paths (LSP) by specifying information to be carried in an		plane failures in Label Switched Paths (LSP) by specifying
	MPLS "echo request" and "echo reply" for the purposes of fault		information to be carried in an MPLS "echo request" and "echo reply"
	detection and isolation, and mechanisms for reliably sending the echo		for the purposes of fault detection and isolation. Mechanisms for
	reply. The functionality is modeled after the ping/traceroute		reliably sending the echo reply are defined. The functionality
	paradigm (ICMP echo request [RFC0792]) and is typically referred to		defined in [RFC4379]is modeled after the ping/traceroute paradigm
	as LSP ping and LSP traceroute.		(ICMP echo request [RFC0792]) and is typically referred to as LSP
			ping and LSP traceroute. [RFC6424] updates [RFC4379] to support
			hierarchal and stitching LSPs.
	Unlike LDP or RSVP which are the other well-known MPLS control plane		Unlike LDP or RSVP which are the other well-known MPLS control plane
	protocols, segment assignment in Segment Routing architecture is not		protocols, segment assignment in Segment Routing architecture is not
	hop-by-hop basis.		hop-by-hop basis.
	This nature of Segment Routing raises additional consideration for		This nature of Segment Routing raises additional consideration for
	fault detection and isolation in Segment Routing network. This		fault detection and isolation in Segment Routing network. This
	document illustrates the problem and describe a mechanism to perform		document illustrates the problem and describe a mechanism to perform
	LSP Ping and Traceroute on Segment Routing network over MPLS data		LSP Ping and Traceroute on Segment Routing network over MPLS data
	plane.		plane.
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 19 ¶
	helpful. For example if R3, due to misprogramming, forwards packet		helpful. For example if R3, due to misprogramming, forwards packet
	with Adjacency Segment ID 9236 via link L1 while it is expected to be		with Adjacency Segment ID 9236 via link L1 while it is expected to be
	forwarded over Link L2.		forwarded over Link L2.
	4.2. Service Label		4.2. Service Label
	A Segment ID can represent a service based instruction. An Segment		A Segment ID can represent a service based instruction. An Segment
	Routing header can have label stack entries where the label		Routing header can have label stack entries where the label
	represents a service to be applied along the path. Since these		represents a service to be applied along the path. Since these
	labels are part of the label stack, they can influence the path taken		labels are part of the label stack, they can influence the path taken
	by a packet and consequently have implications on MPLS OAM. In		by a packet and consequently have implications on MPLS OAM. Service
	section 6.5 of this document, it is described how the procedures of		Label is left for future study.
	[RFC4379] can be applied to in the absence of service-labels in
	Section 6.5. Additional considerations for service labels are
	included in Section 7 and requires further discussion.
	5. Segment ID sub-TLV		5. Segment ID sub-TLV
	The format of the following Segment ID sub-TLVs follows the		The format of the following Segment ID sub-TLVs follows the
	philosophy of Target FEC Stack TLV carrying FECs corresponding to		philosophy of Target FEC Stack TLV carrying FECs corresponding to
	each label in the label stack. When operated with the procedures		each label in the label stack. When operated with the procedures
	defined in [RFC4379], this allows LSP ping/traceroute operations to		defined in [RFC4379], this allows LSP ping/traceroute operations to
	function when Target FEC Stack TLV contains more FECs than received		function when Target FEC Stack TLV contains more FECs than received
	label stack at responder nodes.		label stack at responder nodes.
	Three new sub-TLVs are defined for TLVs type 1, 16 and 21.		Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1),
			Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type
			21).
	sub-Type Value Field		sub-Type Value Field
	-------- ---------------		-------- ---------------
	TBD1 IPv4 Prefix Node Segment ID		TBD1 IPv4 IGP-Prefix Segment ID
	TBD2 IPv6 Prefix Node Segment ID		TBD2 IPv6 IGP-Prefix Segment ID
	TBD3 Adjacency Segment ID		TBD3 IGP-Adjacency Segment ID
	Service Segments and FRR will be considered in future version.		Service Segments and FRR will be considered in future version.
	5.1. IPv4 Prefix Node Segment ID		5.1. IPv4 IGP-Prefix Segment ID
	The format is as below:		The format is as below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 Prefix |		| IPv4 Prefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Prefix Length | Protocol | Reserved |		|Prefix Length | Protocol | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IPv4 Prefix		IPv4 Prefix
	This field carries the IPv4 prefix to which the Node Segment ID is		This field carries the IPv4 prefix to which the Segment ID is
	assigned. If the prefix is shorter than 32 bits, trailing bits		assigned. In case of Anycast Segment ID, this field will carry
	SHOULD be set to zero.		IPv4 Anycast address. If the prefix is shorter than 32 bits,
			trailing bits SHOULD be set to zero.
	Prefix Length		Prefix Length
	The Prefix Length field is one octet, it gives the length of the		The Prefix Length field is one octet, it gives the length of the
	prefix in bits (values can be 1 - 32).		prefix in bits (values can be 1 - 32).
	Protocol		Protocol
	Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is		Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is
	ISIS.		ISIS.
	5.2. IPv6 Prefix Node Segment ID		5.2. IPv6 IGP-Prefix Segment ID
	The format is as below:		The format is as below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| IPv6 Prefix |		| IPv6 Prefix |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Prefix Length | Protocol | Reserved |		|Prefix Length | Protocol | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	IPv6 Prefix		IPv6 Prefix
	This field carries the IPv6 prefix to which the Node Segment ID is		This field carries the IPv6 prefix to which the Segment ID is
	assigned. If the prefix is shorter than 128 bits, trailing bits		assigned. In case of Anycast Segment ID, this field will carry
	SHOULD be set to zero.		IPv4 Anycast address. If the prefix is shorter than 128 bits,
			trailing bits SHOULD be set to zero.
	Prefix Length		Prefix Length
	The Prefix Length field is one octet, it gives the length of the		The Prefix Length field is one octet, it gives the length of the
	prefix in bits (values can be 1 - 128).		prefix in bits (values can be 1 - 128).
	Protocol		Protocol
	Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is		Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is
	ISIS.		ISIS.
	5.3. IGP Adjacency Segment ID		5.3. IGP-Adjacency Segment ID
	The format is as below:		The format is as below:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Adj. Type | Protocol | Reserved |		| Adj. Type | Protocol | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Local Interface ID (4 or 16 octets) |		| Local Interface ID (4 or 16 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Remote Interface ID (4 or 16 octets) |		| Remote Interface ID (4 or 16 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	| Advertising Node Identifier (4 or 6 octets) |		| Advertising Node Identifier (4 or 6 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ ~		~ ~
	| Receiving Node Identifier (4 or 6 octets) |		| Receiving Node Identifier (4 or 6 octets) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Adj. Type		Adj. Type (Adjacency Type)
	Set to 1, when the Adjacency Segment is Parallel Adjacency as		Set to 1, when the Adjacency Segment is Parallel Adjacency as
	defined in section 3.5.1 of [I-D.ietf-spring-segment-routing].		defined in section 3.5.1 of [I-D.ietf-spring-segment-routing].
	Set to 4, when the Adjacency segment is IPv4 based and is not a		Set to 4, when the Adjacency segment is IPv4 based and is not a
	parallel adjacency. Set to 6, when the Adjacency segment is IPv6		parallel adjacency. Set to 6, when the Adjacency segment is IPv6
	based and is not a parallel adjacency.		based and is not a parallel adjacency.
	Protocol		Protocol
	Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS		Set to 1 if the IGP protocol is OSPF and 2 if IGP protocol is ISIS
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	1 Static		1 Static
	2 BGP		2 BGP
	3 LDP		3 LDP
	4 RSVP-TE		4 RSVP-TE
	With segment routing, OSPF or ISIS can be used for label		With segment routing, OSPF or ISIS can be used for label
	distribution, this document adds two new protocols as follows:		distribution, this document adds two new protocols as follows:
	Protocol # Signaling Protocol		Protocol # Signaling Protocol
	---------- ------------------		---------- ------------------
	5 OSPF		TBD5 OSPF
	6 ISIS		TBD6 ISIS
	7. Procedures		7. Procedures
	This section describes aspects of LSP Ping and traceroute operations		This section describes aspects of LSP Ping and traceroute operations
	that require further considerations beyond [RFC4379].		that require further considerations beyond [RFC4379].
	7.1. FECs in Target FEC Stack TLV		7.1. FECs in Target FEC Stack TLV
	When LSP echo request packets are generated by an initiator, FECs		When LSP echo request packets are generated by an initiator, FECs
	carried in Target FEC Stack TLV may need to have deviating contents.		carried in Target FEC Stack TLV may need to have deviating contents.
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 50 ¶
	communicate the segments traversed.		communicate the segments traversed.
	Traceroute		Traceroute
	Initiator MUST initially include FECs corresponding to all of		Initiator MUST initially include FECs corresponding to all of
	segments imposed in the label stack.		segments imposed in the label stack.
	When a received echo reply contains FEC Stack Change TLV with		When a received echo reply contains FEC Stack Change TLV with
	one or more of original segment(s) being popped, initiator MAY		one or more of original segment(s) being popped, initiator MAY
	remove corresponding FEC(s) from Target FEC Stack TLV in the		remove corresponding FEC(s) from Target FEC Stack TLV in the
	next (TTL+1) traceroute request.		next (TTL+1) traceroute request as defined in section 4.3.1.2
			of [RFC6424].
	When a received echo reply does not contain FEC Stack Change		When a received echo reply does not contain FEC Stack Change
	TLV, initiator MUST NOT attempt to remove FEC(s) from Target		TLV, initiator MUST NOT attempt to remove FEC(s) from Target
	FEC Stack TLV in the next (TTL+1) traceroute request. Note		FEC Stack TLV in the next (TTL+1) traceroute request.
	that Downstream Label field of DSMAP/DDMAP contains hints on
	how initiator may be able to update the contents of next Target
	FEC Stack TLV. However, such hints are ambiguous without full
	understanding of PHP capabilities.
	7.2. FEC Stack Change sub-TLV		7.2. FEC Stack Change sub-TLV
	Section 3.3.1.3 of [RFC6424] defines a new sub-TLV that a router must		Section 3.3.1.3 of [RFC6424] defines FEC Stack Change sub-TLV that a
	include when the FEC stack changes.		router must include when the FEC stack changes.
	The network node which advertised the Node Segment ID is responsible		The network node which advertised the Node Segment ID is responsible
	for generating FEC Stack Change sub-TLV of &pop& operation for Node		for generating FEC Stack Change sub-TLV of &pop& operation for Node
	Segment ID, regardless of if PHP is enabled or not.		Segment ID, regardless of if PHP is enabled or not.
	The network node that is immediate downstream of the node which		The network node that is immediate downstream of the node which
	advertised the Adjacency Segment ID is responsible for generating FEC		advertised the Adjacency Segment ID is responsible for generating FEC
	Stack Change sub-TLV of &pop& operation for Adjacency Segment ID.		Stack Change sub-TLV of &pop& operation for Adjacency Segment ID.
	7.3. Segment ID POP Operation		7.3. Segment ID POP Operation
	The forwarding semantic of Node Segment ID with PHP flag is		The forwarding semantic of Node Segment ID with PHP flag is
	equivalent to usage of implicit Null in MPLS protocols. Adjacency		equivalent to usage of implicit Null in MPLS protocols. Adjacency
	Segment ID is also similar in a sense that it can be thought as next		Segment ID is also similar in a sense that it can be thought as next
	hop destined locally allocated segment that has PHP enabled.		hop destined locally allocated segment that has PHP enabled.
	Procedures described in Section 4.4 of [RFC4379] relies on Stack-D		Procedures described in Section 4.4 of [RFC4379] relies on Stack-D
	and Stack-R explicitly having Implicit Null value. It may simplify		and Stack-R explicitly having Implicit Null value. It may simplify
	implementations to reuse Implicit Null for Node Segment ID PHP and		implementations to reuse Implicit Null for Node Segment ID PHP and
	Adjacency Segment ID cases. However, it is technically incorrect for		Adjacency Segment ID cases.
	Implicit Null value to externally appear. Therefore, implicit Null
	MUST NOT be placed in Stack-D and Interface and Label Stack TLV for
	Node Segment ID PHP and Adjacency Segment ID cases.
	7.4. Segment ID Check		7.4. Segment ID Check
			This section updates the procedure defined in Step 6 of section 4.4.
			of [RFC4379]
	If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC-		If the Label-stack-depth is 0 and Target FEC Stack Sub-TLV at FEC-
	stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the responder		stack-depth is TBD1 (IPv4 IGP-Prefix Segment ID), the responder
	should set Best return code to 10 if any below conditions fail: /*		should set Best return code to 10, "Mapping for this FEC is not
	The responder LSR is to check if it is the egress of the IPv4		the given label at stack-depth <RSC>" if any below conditions
	Prefix Node Segment ID described in the Target FEC Stack Sub-TLV,		fail:
			/* The responder LSR is to check if it is the egress of the IPv4
			IGP-Prefix Segment ID described in the Target FEC Stack Sub-TLV,
	and if the FEC was advertised with the PHP bit set.*/		and if the FEC was advertised with the PHP bit set.*/
	* Validate that Node Segment ID is advertised for IPv4 Prefix.		* Validate that Node Segment ID is advertised for IPv4 Prefix.
	* Validate that Node Segment ID is advertisement of PHP bit.		* Validate that Node Segment ID is advertised with No-PHP flag {
			+ When Protocol is OSPF, NP-flag defined in Section 5 of
			[I-D.ietf-ospf-segment-routing-extensions] should be set to
			0.
			+ When Protocol is ISIS, P-Flag defined in Section 2.1 of
			[I-D.ietf-isis-segment-routing-extensions] should be set to
			0.
			* }
	If the Label-stack-depth is more than 0 and Target FEC Stack Sub-		If the Label-stack-depth is more than 0 and Target FEC Stack Sub-
	TLV at FEC-stack-depth is TBD1 (IPv4 Prefix Node Segment ID), the		TLV at FEC-stack-depth is TBD1 (IPv4 IGP-Prefix Segment ID), the
	responder is to set Best return code to 10 if any below conditions		responder is to set Best return code to 10 if any below conditions
	fail:		fail:
	* Validate that Node Segment ID is advertised for IPv4 Prefix.		* Validate that Node Segment ID is advertised for IPv4 Prefix.
	If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack-		If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack-
	depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code		depth is TBD2 (IPv6 IGP-Prefix Segment ID), set Best return code
	to 10 if any below conditions fail: /* The LSR needs to check if		to 10 if any below conditions fail:
	its being a tail-end for the LSP and have the prefix advertised
	with PHP bit set*/		/* The LSR needs to check if its being a tail-end for the LSP and
			have the prefix advertised with PHP bit set*/
	* Validate that Node Segment ID is advertised for IPv6 Prefix.		* Validate that Node Segment ID is advertised for IPv6 Prefix.
	* Validate that Node Segment ID is advertised of PHP bit.		* Validate that Node Segment ID is advertised of PHP bit.
	If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack-		If the Label-stack-depth is more than 0 and Target FEC Sub-TLV at
	depth is TBD2 (IPv6 Prefix Node Segment ID), set Best return code		FEC-stack-depth is TBD2 (IPv6 IGP-Prefix Segment ID), set Best
	to 10 if any below conditions fail:		return code to 10 if any below conditions fail:
	* Validate that Node Segment ID is advertised for IPv6 Prefix.		* Validate that Node Segment ID is advertised for IPv6 Prefix.
	If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack-		If the Label-stack-depth is 0 and Target FEC sub-TLV at FEC-stack-
	depth is TBD3 (Adjacency Segment ID), set Best return code to		depth is TBD3 (Adjacency Segment ID), set Best return code to
	(error code TBD) if any below conditions fail:		(error code TBD) if any below conditions fail:
	When the Adj.Type is 1 (Parallel Adjacency):		When the Adj. Type is 1 (Parallel Adjacency):
	+ Validate that Receiving Node Identifier is local IGP		+ Validate that Receiving Node Identifier is local IGP
	identifier.		identifier.
	+ Validate that Adjacency Segment ID is advertised by		+ Validate that Adjacency Segment ID is advertised by
	Advertising Node Identifier of Protocol in local IGP		Advertising Node Identifier of Protocol in local IGP
	database.		database.
	When the Adj.Type is 4 or 6:		When the Adj. Type is 4 or 6:
	+ Validate that Remote Interface ID matches the local		+ Validate that Remote Interface ID matches the local
	identifier of the interface (Interface-I) on which the		identifier of the interface (Interface-I) on which the
	packet was received.		packet was received.
	+ Validate that Receiving Node Identifier is local IGP		+ Validate that Receiving Node Identifier is local IGP
	identifier.		identifier.
	+ Validate that IGP Adjacency Segment ID is advertised by		+ Validate that IGP-Adjacency Segment ID is advertised by
	Advertising Node Identifier of Protocol in local IGP		Advertising Node Identifier of Protocol in local IGP
	database.		database.
	7.5. TTL Consideration for traceroute		7.5. TTL Consideration for traceroute
	LSP Traceroute operation can properly traverse every hop of Segment		LSP Traceroute operation can properly traverse every hop of Segment
	Routing network in Uniform Model described in [RFC3443]. If one or		Routing network in Uniform Model described in [RFC3443]. If one or
	more LSRs employ Short Pipe Model described in [RFC3443], then LSP		more LSRs employ Short Pipe Model described in [RFC3443], then LSP
	Traceroute may not be able to properly traverse every hop of Segment		Traceroute may not be able to properly traverse every hop of Segment
	Routing network due to absence of TTL copy operation when outer label		Routing network due to absence of TTL copy operation when outer label
	is popped. In such scenario, following TTL manipulation technique		is popped. Short Pipe being the most commonly used model. The
	MAY be used.		following TTL manipulation technique MAY be used when Short Pipe
			model is used.
	When tracing a LSP according to the procedures in [RFC4379] the TTL		When tracing a LSP according to the procedures in [RFC4379] the TTL
	is incremented by one in order to trace the path sequentially along		is incremented by one in order to trace the path sequentially along
	the LSP. However when a source routed LSP has to be traced there are		the LSP. However when a source routed LSP has to be traced there are
	as many TTLs as there are labels in the stack. The LSR that		as many TTLs as there are labels in the stack. The LSR that
	initiates the traceroute SHOULD start by setting the TTL to 1 for the		initiates the traceroute SHOULD start by setting the TTL to 1 for the
	tunnel in the LSP's label stack it wants to start the tracing from,		tunnel in the LSP's label stack it wants to start the tracing from,
	the TTL of all outer labels in the stack to the max value, and the		the TTL of all outer labels in the stack to the max value, and the
	TTL of all the inner labels in the stack to zero. Thus a typical		TTL of all the inner labels in the stack to zero. Thus a typical
	start to the traceroute would have a TTL of 1 for the outermost label		start to the traceroute would have a TTL of 1 for the outermost label
	and all the inner labels would have TTL 0. If the FEC Stack TLV is		and all the inner labels would have TTL 0. If the FEC Stack TLV is
	included it should contain only those for the inner stacked tunnels.		included it should contain only those for the inner stacked tunnels.
	The lack of an echo response or the Return Code/Subcode should be		The Return Code/Subcode and FEC Stack Change TLV should be used to
	used to diagnose the tunnel as described in [RFC4379]. When the		diagnose the tunnel as described in [RFC4379] and [RFC6424]. When
	tracing of a tunnel in the stack is complete, then the next tunnel in		the tracing of a tunnel in the stack is complete, then the next
	the stack should be traced. The end of a tunnel can be detected from		tunnel in the stack should be traced. The end of a tunnel can be
	the "Return Code" when it indicates that the responding LSR is an		detected from the "Return Code" when it indicates that the responding
	egress for the stack at depth 1. Thus the traceroute procedures in		LSR is an egress for the stack at depth 1. Thus the traceroute
	[RFC4379] can be recursively applied to traceroute a source routed		procedures in [RFC4379] can be recursively applied to traceroute a
	LSP.		source routed LSP.
	8. Issues with non-forwarding labels		8. Issues with non-forwarding labels
	Source stacking can be optionally used to apply services on the		Source stacking can be optionally used to apply services on the
	packet at a LSR along the path, where a label in the stack is used to		packet at a LSR along the path, where a label in the stack is used to
	trigger service application. A data plane failure detection and		trigger service application. A data plane failure detection and
	isolation mechanism should provide its functionality without applying		isolation mechanism should provide its functionality without applying
	these services. This is mandatory for services that are stateful,		these services. This is mandatory for services that are stateful,
	though for stateless services [RFC4379] could be used as-is. It MAY		though for stateless services [RFC4379] could be used as-is. It MAY
	also provide a mechanism to detect and isolate faults within the		also provide a mechanism to detect and isolate faults within the
	service function itself.		service function itself.
	To prevent services from being applied to an "echo request" packet,		How a node treats Service label is outside the scope of this document
	the TTL of service labels MUST be 0. However TTL processing rules of		and will be included in this or a different document later.
	a service label must be the same as any MPLS label. Due to this a
	TTL of 0 in the service label would prevent the packet from being
	forwarded beyond the LSR that provides the service. To avoid this
	problem, the originator of the "echo request" MUST NOT include the
	service label in the label stack of an echo request above the tunnel
	label of the tunnel that is being currently traced. In other words
	the ingress must remove all service-labels above the label of the
	tunnel being currently traced, but retain service labels below it
	when sending the echo request. Note that load balancing may affect
	the path when the service labels are removed, resulting in a newer
	path being traversed. However this new path is potentially different
	only up to the LSR that provides the service. Since this portion of
	the path was traced when the tunnels above this tunnel in the stack
	were traced and followed the exact path as the source routed LSP,
	this should not be a major concern. Sometimes the newer path may
	have a problem that was not in the original path resulting in a false
	positive. In such a case the original path can be traversed by
	changing the label stack to reach the intermediate LSR with labels
	that route along each hop explicitly.
	9. IANA Considerations		9. Backward Compatibility with non Segment Routing devices
	9.1. New Target FEC Stack Sub-TLVs		[I-D.ietf-spring-segment-routing-ldp-interop] describes how Segment
			Routing operates in network where SR-capable and non-SR-capable nodes
			coexist. In such networks, there may not be any FEC mapping in the
			responder when the Initiator is SR-capable while the responder is not
			(or vice-versa). But this is not different from RSVP and LDP interop
			scenarios. When LSP Ping is triggered, the responder will set the
			FEC-return-code to Return 4, "Replying router has no mapping for the
			FEC at stack-depth".
			Similarly when SR-capable node assigns Adj-SID for non-SR-capable
			node, LSP trace may fail as the non-SR-capable node is not aware of
			"IGP Adjacency Segment ID" sub-TLV and may not reply with FEC Stack
			change. This may result in any further downstream nodes to reply
			back with Return-code as 4, "Replying router has no mapping for the
			FEC at stack-depth".
			10. IANA Considerations
			10.1. New Target FEC Stack Sub-TLVs
	IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV		IANA is requested to assign 3 new Sub-TLVs from "Sub-TLVs for TLV
	Types 1, 16 and 21" sub-registry.		Types 1, 16 and 21" sub-registry.
	Sub-Type Sub-TLV Name Reference		Sub-Type Sub-TLV Name Reference
	---------- ----------------- ------------		---------- ----------------- ------------
	TBD1 IPv4 Prefix Node Segment ID Section 4.1 (this document)		TBD1 IPv4 IGP-Prefix Segment ID Section 4.1 (this document)
	TBD2 IPv6 Prefix Node Segment ID Section 4.2 (this document)		TBD2 IPv6 IGP-Prefix Segment ID Section 4.2 (this document)
	TBD3 Adjacency Segment ID Section 4.3 (this document)		TBD3 IGP-Adjacency Segment ID Section 4.3 (this document)
	10. Security Considerations		11. Security Considerations
	This document defines additional Sub-TLVs and follows the mechanism		This document defines additional Sub-TLVs and follows the mechanism
	defined in [RFC4379]. So all the security consideration defined in		defined in [RFC4379]. So all the security consideration defined in
	[RFC4379] will be applicable for this document and in addition it		[RFC4379] will be applicable for this document and in addition it
	does not impose any security challenges to be considered.		does not impose any security challenges to be considered.
	11. Acknowledgement		12. Acknowledgement
	The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji		The authors would like to thank Stefano Previdi, Les Ginsberg, Balaji
	Rajagopalan and Harish Sitaraman for their review and comments.		Rajagopalan, Harish Sitaraman, Curtis Villamizar, Pranjal Dutta and
			Lizhong Jin for their review and comments.
	The authors wold like to thank Loa Andersson for his comments and		The authors wold like to thank Loa Andersson for his comments and
	recommendation to merge drafts.		recommendation to merge drafts.
	12. Contributing Authors		13. Contributing Authors
	Tarek Saad		Tarek Saad
	Cisco Systems		Cisco Systems
	Email: tsaad@cisco.com		Email: tsaad@cisco.com
	Siva Sivabalan		Siva Sivabalan
	Cisco Systems		Cisco Systems
	Email: msiva@cisco.com		Email: msiva@cisco.com
	Balaji Rajagopalan		Balaji Rajagopalan
	Juniper Networks		Juniper Networks
	Email: balajir@juniper.net		Email: balajir@juniper.net
	13. References		Faisal Iqbal
			Cisco Systems
			Email: faiqbal@cisco.com
	13.1. Normative References		14. References
	[I-D.filsfils-spring-segment-routing-use-cases]		14.1. Normative References
	Filsfils, C., Francois, P., Previdi, S., Decraene, B.,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,		[I-D.ietf-isis-segment-routing-extensions]
	Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.		Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
	Crabbe, "Segment Routing Use Cases", draft-filsfils-		Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
	spring-segment-routing-use-cases-01 (work in progress),		Extensions for Segment Routing", draft-ietf-isis-segment-
	October 2014.		routing-extensions-06 (work in progress), December 2015.
			[I-D.ietf-ospf-segment-routing-extensions]
			Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
			Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
			Extensions for Segment Routing", draft-ietf-ospf-segment-
			routing-extensions-07 (work in progress), March 2016.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,		Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	and r. rjs@rob.sh, "Segment Routing Architecture", draft-		and R. Shakir, "Segment Routing Architecture", draft-ietf-
	ietf-spring-segment-routing-07 (work in progress),		spring-segment-routing-07 (work in progress), December
	December 2015.		2015.
			[I-D.ietf-spring-segment-routing-ldp-interop]
			Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
			S. Litkowski, "Segment Routing interoperability with LDP",
			draft-ietf-spring-segment-routing-ldp-interop-00 (work in
			progress), October 2015.
			[I-D.ietf-spring-segment-routing-mpls]
			Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
			Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
			and E. Crabbe, "Segment Routing with MPLS data plane",
			draft-ietf-spring-segment-routing-mpls-04 (work in
			progress), March 2016.
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<http://www.rfc-editor.org/info/rfc792>.		<http://www.rfc-editor.org/info/rfc792>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 15, line 20 ¶		skipping to change at page 16, line 15 ¶
	[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions		[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
	in Support of Generalized Multi-Protocol Label Switching		in Support of Generalized Multi-Protocol Label Switching
	(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,		(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
	<http://www.rfc-editor.org/info/rfc5307>.		<http://www.rfc-editor.org/info/rfc5307>.
	[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for		[RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for
	Performing Label Switched Path Ping (LSP Ping) over MPLS		Performing Label Switched Path Ping (LSP Ping) over MPLS
	Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,		Tunnels", RFC 6424, DOI 10.17487/RFC6424, November 2011,
	<http://www.rfc-editor.org/info/rfc6424>.		<http://www.rfc-editor.org/info/rfc6424>.
	13.2. Informative References		14.2. Informative References
	[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,		[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	Acronym in the IETF", BCP 161, RFC 6291,		Acronym in the IETF", BCP 161, RFC 6291,
	DOI 10.17487/RFC6291, June 2011,		DOI 10.17487/RFC6291, June 2011,
	<http://www.rfc-editor.org/info/rfc6291>.		<http://www.rfc-editor.org/info/rfc6291>.
	[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,		[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
	Yasukawa, S., and T. Nadeau, "Detecting Data-Plane		Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
	Failures in Point-to-Multipoint MPLS - Extensions to LSP		Failures in Point-to-Multipoint MPLS - Extensions to LSP
End of changes. 48 change blocks.
	133 lines changed or deleted		169 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/