Diff: rfc9655.original

	rfc9655.original	rfc9655.txt


	Routing area D. Rathi, Ed.	Internet Engineering Task Force (IETF) D. Rathi, Ed.
	Internet-Draft Nokia	Request for Comments: 9655 Nokia
	Intended status: Standards Track S. Hegde, Ed.	Category: Standards Track S. Hegde, Ed.
	Expires: 14 December 2024 Juniper Networks Inc.	ISSN: 2070-1721 Juniper Networks Inc.
	K. Arora	K. Arora
	Individual Contributor	Individual Contributor
	Z. Ali	Z. Ali
	N. Nainar	N. Nainar
	Cisco Systems, Inc.	Cisco Systems, Inc.

	12 June 2024	September 2024

	Egress Validation in Label Switched Path Ping and Traceroute Mechanisms	Egress Validation in Label Switched Path Ping and Traceroute Mechanisms

	draft-ietf-mpls-egress-tlv-for-nil-fec-15

	Abstract	Abstract


	The MPLS ping and traceroute mechanisms, as described in [RFC8029]	The MPLS ping and traceroute mechanisms described in RFC 8029 and the
	and the related extensions for Segment Routing (SR) defined in	related extensions for Segment Routing (SR) defined in RFC 8287 are
	[RFC8287], is highly valuable for validating control plane and data	highly valuable for validating control plane and data plane
	plane synchronization. In certain environments, only some	synchronization. In certain environments, only some intermediate or
	intermediate or transit nodes may have been upgraded to support these	transit nodes may have been upgraded to support these validation
	validation procedures. A straightforward MPLS ping and traceroute	procedures. A straightforward MPLS ping and traceroute mechanism
	mechanism allows traversing any path without validating the control	allows traversal of any path without validation of the control plane
	plane state. [RFC8029] supports this mechanism with the Nil	state. RFC 8029 supports this mechanism with the Nil Forwarding
	Forwarding Equivalence Class (FEC). The procedures outlined in	Equivalence Class (FEC). The procedures outlined in RFC 8029 are
	[RFC8029] is primarily applicable when the Nil FEC is used as an	primarily applicable when the Nil FEC is used as an intermediate FEC
	intermediate FEC in the label stack. However, challenges arise when	in the FEC stack. However, challenges arise when all labels in the
	all labels in the label stack are represented using the Nil FEC.	label stack are represented using the Nil FEC.

	This document introduces a new Type-Length-Value (TLV) as an	This document introduces a new Type-Length-Value (TLV) as an
	extension to the existing Nil FEC. It describes MPLS ping and	extension to the existing Nil FEC. It describes MPLS ping and
	traceroute procedures using the Nil FEC with this extension to	traceroute procedures using the Nil FEC with this extension to
	address and overcome these challenges.	address and overcome these challenges.


	Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 14 December 2024.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9655.

	Copyright Notice	Copyright Notice

	Copyright (c) 2024 IETF Trust and the persons identified as the	Copyright (c) 2024 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 (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction
	2. Problem with Nil FEC . . . . . . . . . . . . . . . . . . . . 4	1.1. Requirements Language
	3. Egress TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5	2. Problem with Nil FEC
	4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6	3. Egress TLV
	4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 6	4. Procedure
	4.1.1. Ping Mode . . . . . . . . . . . . . . . . . . . . . . 6	4.1. Sending Egress TLV in MPLS Echo Request
	4.1.2. Traceroute Mode . . . . . . . . . . . . . . . . . . . 7	4.1.1. Ping Mode
	4.1.3. Detailed Example . . . . . . . . . . . . . . . . . . 7	4.1.2. Traceroute Mode
	4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 8	4.1.3. Detailed Example
	5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9	4.2. Receiving Egress TLV in MPLS Echo Request
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9	5. Backward Compatibility
	6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9	6. IANA Considerations
	6.2. New Return code . . . . . . . . . . . . . . . . . . . . . 9	6.1. New TLV
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10	6.2. New Return Code
	8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10	7. Security Considerations
	8.1. Juniper Networks . . . . . . . . . . . . . . . . . . . . 10	8. References
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11	8.1. Normative References
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11	8.2. Informative References
	10.1. Normative References . . . . . . . . . . . . . . . . . . 11	Acknowledgements
	10.2. Informative References . . . . . . . . . . . . . . . . . 12	Authors' Addresses

	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12

	1. Introduction	1. Introduction

	Segment routing supports the creation of explicit paths by using one	Segment routing supports the creation of explicit paths by using one

	or more Link State IGP Segments or BGP Segments defined in [RFC8402].	or more Link-State IGP Segments or BGP Segments defined in [RFC8402].
	In certain use cases, the TE paths are built using mechanisms	In certain use cases, the TE paths are built using mechanisms
	described in [RFC9256] by stacking the labels that represent the	described in [RFC9256] by stacking the labels that represent the
	nodes and links in the explicit path. Controllers are often deployed	nodes and links in the explicit path. Controllers are often deployed
	to construct paths across multi-domain networks. In such	to construct paths across multi-domain networks. In such

	deployments, the head-end routers may have the link state database of	deployments, the headend routers may have the link-state database of
	its domain and may not be aware of the FEC associated with labels	their domain and may not be aware of the FEC associated with labels
	that are used by the controller to build paths across multiple	that are used by the controller to build paths across multiple
	domains. A very useful Operations, Administration, and Maintenance	domains. A very useful Operations, Administration, and Maintenance
	(OAM) requirement is to be able to ping and trace these paths.	(OAM) requirement is to be able to ping and trace these paths.


	[RFC8029] describes a simple and efficient mechanism to detect data-	[RFC8029] describes a simple and efficient mechanism to detect data
	plane failures in MPLS Label Switched Paths (LSPs). It defines a	plane failures in MPLS Label Switched Paths (LSPs). It defines a
	probe message called an "MPLS echo request" and a response message	probe message called an "MPLS echo request" and a response message
	called an "MPLS echo reply" for returning the result of the probe.	called an "MPLS echo reply" for returning the result of the probe.

	SR-related extensions to Echo Request/Echo Reply are specified in	SR-related extensions for these are specified in [RFC8287].
	[RFC8287]. [RFC8029] primarily provides mechanisms to validate the	[RFC8029] provides mechanisms primarily to validate the data plane
	data plane and, secondarily, to verify the consistency of the data	and secondarily to verify the consistency of the data plane with the
	plane with the control plane. It also provides the ability to	control plane. It also provides the ability to traverse Equal-Cost
	traverse Equal-cost Multiple Paths (ECMP) and validate each of the	Multipaths (ECMPs) and validate each of the ECMP paths. The Target
	ECMP paths. Target FEC Stack TLV [RFC8029] contains sub-TLVs that	FEC Stack TLV [RFC8029] contains sub-TLVs that carry information
	carry information about the label. This information gets validated	about the label. This information gets validated on each node for
	on each node for traceroute and on the egress for ping. The use of	traceroute and on the egress for ping. The use of the Target FEC
	Target FEC requires all nodes in the network to have implemented the	Stack TLV requires all nodes in the network to have implemented the
	validation procedures. All intermediate nodes may not have been	validation procedures, but all intermediate nodes may not have been
	upgraded to support validation procedures. In such cases, it is	upgraded to support validation procedures. In such cases, it is
	useful to have the ability to traverse the paths in ping/traceroute	useful to have the ability to traverse the paths in ping/traceroute
	mode without having to obtain the FEC for each label.	mode without having to obtain the FEC for each label.


	A simple MPLS Echo Request/Echo Reply mechanism allows for traversing	A simple MPLS echo request/reply mechanism allows for traversing the
	the SR Policy path without validating the control plane state.	SR Policy path without validating the control plane state. [RFC8029]
	[RFC8029] supports this mechanism with FECs like Nil FEC and Generic	supports this mechanism with FECs like the Nil FEC and the Generic
	FEC. However, there are challenges in reusing the Generic FEC and	FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix). However,
	Nil FEC for validation of SR policies [RFC9256]. Generic IPv4 prefix	there are challenges in reusing the Nil FEC and Generic FECs for
	and Generic IPv6 prefix FECs are used when the protocol that is	validation of SR Policies [RFC9256]. The Generic IPv4 prefix and
		Generic IPv6 prefix FECs are used when the protocol that is
	advertising the label is unknown. The information that is carried in	advertising the label is unknown. The information that is carried in

	Generic FEC is the IPv4 or IPv6 prefix and prefix length. Thus	the Generic FECs is the IPv4 or IPv6 prefix and prefix length. Thus,
	Generic FEC types perform an additional control plane validation.	the Generic FEC types perform an additional control plane validation.
	However, the details of Generic FEC and validation procedures are not	However, the Generic FECs and relevant validation procedures are not
	very detailed in the [RFC8029]. The use-case mostly specifies inter-	thoroughly detailed in [RFC8029]. The use case mostly specifies
	AS VPNs as the motivation. Certain aspects of SR such as anycast	inter-AS (Autonomous System) VPNs as the motivation. Certain aspects
	SIDs require clear guidelines on how the validation procedure should	of SR, such as anycast Segment Identifiers (SIDs), require clear
	work. Also, Generic FEC may not be widely supported and if transit	guidelines on how the validation procedure should work. Also, the
	routers are not upgraded to support validation of Generic FEC,	Generic FECs may not be widely supported, and if transit routers are
	traceroute may fail. On the other hand, Nil FEC consists of the	not upgraded to support validation of Generic FECs, traceroute may
	label and there is no other associated FEC information. Nil FEC is	fail. On the other hand, the Nil FEC consists of the label, and
	used to traverse the path without validation for cases where the FEC	there is no other associated FEC information. The Nil FEC is used to
	is not defined or routers are not upgraded to support the FECs.	traverse the path without validation for cases where the FEC is not
	Thus, it can be used to check any combination of segments on any data	defined or routers are not upgraded to support the FECs. Thus, it
	path. The procedures described in [RFC8029] are mostly applicable	can be used to check any combination of segments on any data path.
	when the Nil FEC is used where the Nil FEC is intermediate in the	The procedures described in [RFC8029] are mostly applicable when the
	label stack. When all labels in the label-stack is represented using	Nil FEC is used as an intermediate FEC in the FEC stack. Challenges
	Nil FEC, it poses some challenges.	arise when all labels in the label stack are represented using the
		Nil FEC.


	Section 2 discusses the problems associated with using Nil FEC in an	Section 2 discusses the problems associated with using the Nil FEC in
	MPLS ping/traceroute procedure and Section 3 and Section 4 discuss	an MPLS ping/traceroute procedure, and Sections 3 and 4 discuss
	simple extensions needed to solve the problem.	simple extensions needed to solve the problem.

	The problems and the solutions described in this document apply to	The problems and the solutions described in this document apply to

	MPLS data plane. SRv6 is out-of-scope for this document.	the MPLS data plane. Segment Routing over IPv6 (SRv6) is out of
		scope for this document.

		1.1. Requirements Language

		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
		"OPTIONAL" in this document are to be interpreted as described in
		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
		capitals, as shown here.

	2. Problem with Nil FEC	2. Problem with Nil FEC


	The purpose of Nil FEC as described in [RFC8029] is to ensure hiding	The purpose of the Nil FEC, as described in [RFC8029], is to ensure
	of transit tunnel information and in some cases to avoid false	that transit tunnel information is hidden and, in some cases, to
	negatives when the FEC information is unknown.	avoid false negatives when the FEC information is unknown.

	This document uses a Nil FEC to represent the complete label stack in	This document uses a Nil FEC to represent the complete label stack in

	an MPLS Echo Request message in ping and traceroute mode. A single	an MPLS echo request message in ping and traceroute mode. A single
	Nil FEC is used in the MPLS Echo Request message irrespective of the	Nil FEC is used in the MPLS echo request message irrespective of the
	number of segments in the label stack. As described in sec 4.4.1 of	number of segments in the label stack. Section 4.4.1 of [RFC8029]
	[RFC8029], "If the outermost FEC of the Target FEC stack is the Nil	notes:
	FEC, then the node MUST skip the Target FEC validation completely."
	When a router in the label-stack path receives an MPLS Echo Request	\| If the outermost FEC of the Target FEC stack is the Nil FEC, then
		\| the node MUST skip the Target FEC validation completely.

		When a router in the label stack path receives an MPLS echo request
	message, there is no definite way to decide whether it is the	message, there is no definite way to decide whether it is the

	intended egress router since Nil FEC does not carry any information	intended egress router since the Nil FEC does not carry any
	and no validation is performed by the router. So there is a high	information and no validation is performed by the router. Thus,
	possibility that the packet may be mis-forwarded to an incorrect	there is a high possibility that the packet may be misforwarded to an
	destination but the MPLS Echo Reply might still return success.	incorrect destination but the MPLS echo reply might still return
		success.

	To mitigate this issue, it is necessary to include additional	To mitigate this issue, it is necessary to include additional

	information in the MPLS Echo Request message in both ping and	information, along with the Nil FEC, in the MPLS echo request message
	traceroute modes, along with the Nil FEC, to perform minimal	in both ping and traceroute modes and to perform minimal validation
	validation on the egress/destination router. This will enable the	on the egress/destination router. This will enable the router to
	router to send appropriate success and failure information to the	send appropriate success and failure information to the headend
	headend router of the SR Policy. This supplementary information	router of the SR Policy. This supplementary information should
	should assist in reporting transit router details to the headend	assist in reporting transit router details to the headend router,
	router, which can be utilized by an offline application to validate	which can be utilized by an offline application to validate the
	the traceroute path.	traceroute path.


	Consequently, the inclusion of egress information in the MPLS Echo	Consequently, the inclusion of egress information in the MPLS echo
	Request messages in ping and traceroute modes will facilitate the	request messages in ping and traceroute modes will facilitate the
	validation of Nil FEC on the egress router ensuring the correct	validation of the Nil FEC on the egress router, ensuring the correct
	destination. It can be employed to verify any combination of	destination. Egress information can be employed to verify any
	segments on any path without requiring upgrades to transit nodes.	combination of segments on any path without requiring upgrades to
	The code point used for Egress TLV is from the range 32768-65535 and	transit nodes. The Egress TLV can be silently dropped if not
	can be silently dropped if not recognized as per [RFC8029] and as per	recognized; alternately, it may be stepped over, or an error message
	clarifications from [RFC9041]. Alternately, the un-recognized TLV	may be sent (per [RFC8029] and the clarifications in [RFC9041]
	may be stepped over or an error message may be sent.	regarding code points in the range 32768-65535).

	If a transit node does not recognize the Egress TLV and chooses to	If a transit node does not recognize the Egress TLV and chooses to

	silently drop or step over the Egress TLV, headend will continue to	silently drop or step over the Egress TLV, the headend will continue
	send Egress TLV in the next echo request message and if egress	to send the Egress TLV in the next echo request message, and if
	recognizes the Egress TLV, egress validation will be executed at the	egress recognizes the Egress TLV, egress validation will be executed
	egress. If a transit node does not recognize the Egress TLV and	at the egress. If a transit node does not recognize the Egress TLV
	chooses to send an error message, the headend will log the message	and chooses to send an error message, the headend will log the
	for informational purposes and continue to send echo requests with	message for informational purposes and continue to send echo requests
	Egress TLV, with TTL incremented. If the egress node does not	with the Egress TLV, with the TTL incremented. If the egress node
	recognize the Egress TLV and chooses to silently drop or step over	does not recognize the Egress TLV and chooses to silently drop or
	the Egress TLV, egress validation will not be done and the ping/	step over the Egress TLV, egress validation will not be done, and the
	traceroute procedure will proceed as if Egress TLV is not received.	ping/traceroute procedure will proceed as if the Egress TLV were not
		received.

	3. Egress TLV	3. Egress TLV


	The Egress TLV MAY be included in an MPLS Echo Request message. It	The Egress TLV MAY be included in an MPLS echo request message. It
	is an optional TLV and, if present, MUST appear before the FEC stack	is an optional TLV and, if present, MUST appear before the Target FEC
	TLV in the MPLS Echo Request packet. This TLV can only be used in	Stack TLV in the MPLS echo request packet. This TLV can only be used
	LSP ping/traceroute requests, generated by the head-end node of an	in LSP ping/traceroute requests that are generated by the headend
	LSP or SR policy for which verification is performed. In cases where	node of an LSP or SR Policy for which verification is performed. In
	multiple Nil FECs are present in the Target FEC Stack TLV, the Egress	cases where multiple Nil FECs are present in the Target FEC Stack
	TLV must be added corresponding to the ultimate egress of the label	TLV, the Egress TLV must be added corresponding to the ultimate
	stack. Explicit paths can be created using Node-SID, Adj-SID,	egress of the label stack. Explicit paths can be created using Node-
	Binding-SID, etc. The address field of the Egress TLV must be	SID, Adj-SID, Binding SID, etc. The Address field of the Egress TLV
	derived from the path egress/destination. The format is as specified	must be derived from the path egress/destination. The format is as
	below:	specified in Figure 1.

	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Type = 32771 (Egress TLV) \| Length \|	\| Type = 32771 (Egress TLV) \| Length \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	\| Address (4 or 16 octets) \|	\| Address (4 or 16 octets) \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Figure 1: Egress TLV	Figure 1: Egress TLV


	Type : 32771 (Section 6.1)	Type: 32771 (Section 6.1)
	Length : variable based on IPV4/IPV6 address. Length excludes the
	length of the Type and Length fields. Length will be 4 octets for
	IPv4 and 16 octets for IPv6.


	Address : This field carries a valid IPv4 address of length 4 octets	Length: Variable (4 octets for IPv4 addresses and 16 octets for IPv6
	or a valid IPv6 address of length 16 octets. It can be obtained from	addresses). Length excludes the length of the Type and Length
	the egress of the path. It corresponds to the last label in the	fields.
	label stack or the SR policy endpoint field
	[I.D-ietf-idr-sr-policy-safi].	Address: This field carries a valid 4-octet IPv4 address or a valid
		16-octet IPv6 address. The address can be obtained from the
		egress of the path and corresponds to the last label in the label
		stack or the SR Policy Endpoint field [SR-POLICY-BGP].

	4. Procedure	4. Procedure

	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 [RFC8029].	that require further considerations beyond those detailed in
		[RFC8029].

	4.1. Sending Egress TLV in MPLS Echo Request	4.1. Sending Egress TLV in MPLS Echo Request


	As previously mentioned, when the sender node constructs an Echo	As previously mentioned, when the sender node constructs an echo
	Request with a Target FEC Stack TLV, the Egress TLV, if present, MUST	request with a Target FEC Stack TLV, the Egress TLV, if present, MUST
	appear before the Target FEC Stack TLV in the MPLS Echo Request	appear before the Target FEC Stack TLV in the MPLS echo request
	packet.	packet.

	4.1.1. Ping Mode	4.1.1. Ping Mode


	When the sender node constructs an Echo Request with target FEC Stack	When the sender node constructs an echo request with a Target FEC
	TLV that contains a single Nil FEC corresponding to the last segment	Stack TLV that contains a single Nil FEC corresponding to the last
	of the SR Policy path, the sender node MUST add an Egress TLV with	segment of the SR Policy path, the sender node MUST add an Egress TLV
	the address obtained from the SR policy endpoint field	with the address obtained from the SR Policy Endpoint field
	[I.D-ietf-idr-sr-policy-safi]. The Label value in the Nil FEC MAY be	[SR-POLICY-BGP]. The Label value in the Nil FEC MAY be set to zero
	set to zero when a single Nil FEC is added for multiple labels in the	when a single Nil FEC is added for multiple labels in the label
	label stack. In case the endpoint is not specified or is equal to	stack. In case the endpoint is not specified or is equal to zero
	zero (Sec 8.8.1 [RFC9256]), the sender MUST use the address	(Section 8.8.1 of [RFC9256]), the sender MUST use the address
	corresponding to the last segment of the SR Policy in the address	corresponding to the last segment of the SR Policy in the Address
	field for Egress TLV. Some specific cases on how to derive the	field of the Egress TLV. Some specific cases on how to derive the
	address field in the Egress TLV are listed below:	Address field in the Egress TLV are listed below:


	a. If the last SID in the SR policy is an Adj-SID, the address	* If the last SID in the SR Policy is an Adj-SID, the Address field
	field in the Egress TLV is derived from the node at the remote end	in the Egress TLV is derived from the node at the remote end of
	of the corresponding adjacency.	the corresponding adjacency.


	b. If the last SID in the SR policy is a Binding SID, the address	* If the last SID in the SR Policy is a Binding SID, the Address
	field in the Egress TLV is derived from the last node of the path	field in the Egress TLV is derived from the last node of the path
	represented by the Binding SID.	represented by the Binding SID.

	4.1.2. Traceroute Mode	4.1.2. Traceroute Mode


	When the sender node builds an Echo Request with target FEC Stack TLV	When the sender node builds an echo request with a Target FEC Stack
	that contains Nil FEC corresponding to the last segment of the	TLV that contains a Nil FEC corresponding to the last segment of the
	segment-list of the SR Policy, the sender node MUST add an Egress TLV	segment list of the SR Policy, the sender node MUST add an Egress TLV
	with the address obtained from the SR policy endpoint field	with the address obtained from the SR Policy Endpoint field
	[I.D-ietf-idr-sr-policy-safi].	[SR-POLICY-BGP].

	Although there is no requirement to do so, an implementation MAY send	Although there is no requirement to do so, an implementation MAY send

	multiple Nil FECs if that makes it easier for the implementation. In	multiple Nil FECs if that makes it easier for the implementation. If
	case the SR Policy headend sends multiple Nil FECs the last one MUST	the SR Policy headend sends multiple Nil FECs, the last one MUST
	correspond to the Egress TLV. The Label value in the Nil FEC MAY be	correspond to the Egress TLV. The Label value in the Nil FEC MAY be

	set to zero for the last Nil FEC. In case the endpoint is not	set to zero for the last Nil FEC. If the endpoint is not specified
	specified or is equal to zero (Sec 8.8.1 [RFC9256]), the sender MUST	or is equal to zero (Section 8.8.1 of [RFC9256]), the sender MUST use
	use the address corresponding to the last segment endpoint of the SR	the address corresponding to the last segment endpoint of the SR
	Policy path i.e. ultimate egress as the address for the Egress TLV.	Policy path (i.e., the ultimate egress is used as the address in the
		Egress TLV).

	4.1.3. Detailed Example	4.1.3. Detailed Example

	----R3----	----R3----
	/ (1003) \	/ (1003) \
	(1001) / \(1005) (1007)	(1001) / \(1005) (1007)
	R1----R2(1002) R5----R6----R7(address X)	R1----R2(1002) R5----R6----R7(address X)
	\ / (1006)	\ / (1006)
	\ (1004) /	\ (1004) /
	----R4----	----R4----


	Figure 2: Egress TLV processing on sample topology	Figure 2: Egress TLV Processing in Sample Topology


	Consider the SR Policy configured on router R1, to destination X,	Consider the SR Policy configured on router R1 to destination X,
	configured with label-stack as 1002, 1004, 1007. Segment 1007	configured with label stack as 1002, 1004, 1007. Segment 1007
	belongs to R7, which has the address X locally configured on it.	belongs to R7, which has the address X locally configured on it.


	Let us look at an example of a ping Echo Request message. The Echo	Let us look at an example of a ping echo request message. The echo
	Request message contains a Target FEC stack TLV with the Nil FEC sub-	request message contains a Target FEC Stack TLV with the Nil FEC sub-
	TLV. An Egress TLV is added before the Target FEC Stack TLV. The	TLV. An Egress TLV is added before the Target FEC Stack TLV. The

	address field contains X (corresponding to a locally configured	Address field contains X (corresponding to a locally configured
	address on R7). X could be an IPv4 or IPv6 address and the Length	address on R7). X could be an IPv4 or IPv6 address, and the Length
	field in the Egress TLV will be 4 or 16 based on the address X's	field in the Egress TLV will be either 4 or 16 octets, based on the
	address type.	address type of address X.


	Let us look at an example of an Echo Request message in a traceroute	Let us look at an example of an echo request message in a traceroute
	packet. The Echo Request message contains a Target FEC stack TLV	packet. The echo request message contains a Target FEC Stack TLV
	with the Nil FEC sub-TLV corresponding to the complete label-stack	with the Nil FEC sub-TLV corresponding to the complete label stack
	(1002, 1004, 1007). An Egress TLV is added before the Target FEC	(1002, 1004, 1007). An Egress TLV is added before the Target FEC

	Stack TLV. The address field contains X (corresponding to a locally	Stack TLV. The Address field contains X (corresponding to a locally
	configured address on destination R7). X could be an IPv4 or IPv6	configured address on destination R7). X could be an IPv4 or IPv6

	address and the Length field in the Egress TLV will be 4 or 16 based	address, and the Length field in the Egress TLV will be either 4 or
	on the address X's address type. If the destination/endpoint is set	16 octets, based on the address type of address X. If the
	to zero (as in the case of the color-only SR Policy) sender should	destination/endpoint is set to zero (as in the case of the color-only
	use the endpoint of segment 1007 (the last segment in the segment	SR Policy), the sender should use the endpoint of segment 1007 (the
	list) as an address for the Egress TLV.	last segment in the segment list) as the address for the Egress TLV.

	4.2. Receiving Egress TLV in MPLS Echo Request	4.2. Receiving Egress TLV in MPLS Echo Request


	Any node that receives the MPLS Echo Request message and processes	Any node that receives an MPLS echo request message and processes it
	it, is referred to as the "receiver". In case of the ping procedure,	is referred to as the "receiver". In the case of the ping procedure,
	the actual destination/egress is the receiver. In the case of	the actual destination/egress is the receiver. In the case of
	traceroute, every node is a receiver. This document does not propose	traceroute, every node is a receiver. This document does not propose

	any change in the processing for Nil FEC as defined in [RFC8029] in	any change in the processing of the Nil FEC (as defined in [RFC8029])
	the Target FEC stack TLV Node that receives an MPLS echo request.	in the node that receives an MPLS echo request with a Target FEC
	The presence of Egress TLV does not affect the validation of Target	Stack TLV. The presence of the Egress TLV does not affect the
	FEC Stack sub-TLV at FEC-stack-depth if it is different than Nil FEC.	validation of the Target FEC Stack sub-TLV at FEC-stack-depth if it
		is different than Nil FEC.

	Additional processing MUST be done for the Egress TLV on the receiver	Additional processing MUST be done for the Egress TLV on the receiver

	node as follows:	node as follows. Note that <RSC> refers to the Return Subcode.

	1. If the Label-stack-depth is greater than 0 and the Target FEC	1. If the Label-stack-depth is greater than 0 and the Target FEC

	Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code to	Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code
	8 ("Label switched at stack-depth") and Best-return-subcode to Label-	to 8 ("Label switched at stack-depth <RSC>") and Best-rtn-subcode
	stack-depth to report transit switching in MPLS Echo Reply message.	to Label-stack-depth to report transit switching in the MPLS echo
		reply message.

	2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at	2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at

	FEC-stack-depth is Nil FEC then do the lookup for an exact match of	FEC-stack-depth is Nil FEC, then do a lookup for an exact match
	the Egress TLV address field to any of the locally configured	of the Address field of the Egress TLV to any of the locally
	interfaces or loopback addresses.	configured interfaces or loopback addresses.


	2a. If the Egress TLV address lookup succeeds, set Best-return-code	a. If the Egress TLV address lookup succeeds, set Best-return-
	to 36 ("Replying router is an egress for the address in Egress TLV	code to 36 ("Replying router is an egress for the address in
	for the FEC at stack depth RSC") (Section 6.2) in MPLS Echo Reply	the Egress TLV for the FEC at stack depth <RSC>")
	message.	(Section 6.2) in the MPLS echo reply message.


	2b. If the Egress TLV address lookup fails, set the Best-return-code	b. If the Egress TLV address lookup fails, set the Best-return-
	to 10, "Mapping for this FEC is not the given label at stack-depth	code to 10 ("Mapping for this FEC is not the given label at
	RSC"	stack-depth <RSC>").

	3. In cases where multiple Nil FECs are sent from the SR Policy	3. In cases where multiple Nil FECs are sent from the SR Policy

	headend, one each corresponding to the labels in the label stack	headend, one each corresponding to the labels in the label stack
	along with Egress TLV, when the packet reaches the egress, the number	along with the Egress TLV, when the packet reaches the egress,
	of labels in the received packet (Size of stack-R) becomes zero or a	the number of labels in the received packet (Size of stack-R)
	label with Bottom-of-Stack bit set to 1 is processed, all Nil FEC	becomes zero or a label with the Bottom-of-Stack bit set to 1 is
	sub-TLVs MUST be removed and the Egress TLV MUST be validated.	processed, all Nil FEC sub-TLVs MUST be removed and the Egress
		TLV MUST be validated.

	5. Backward Compatibility	5. Backward Compatibility


	The extensions defined in this document is backward compatible with	The extensions defined in this document are backward compatible with
	procedures described in [RFC8029]. A Router that does not support	the procedures described in [RFC8029]. A router that does not
	Egress TLV, will ignore it and use current the Nil-FEC procedures	support the Egress TLV will ignore it and use the Nil FEC procedures
	described in [RFC8029].	described in [RFC8029].

	When the egress node in the path does not support the extensions	When the egress node in the path does not support the extensions

	defined in this document egress validation will not be done and Best-	defined in this document, egress validation will not be done, and
	return-code as 3 ("Replying router is an egress for the FEC at stack-	Best-return-code will be set to 3 ("Replying router is an egress for
	depth") and Best-return- subcode set to stack-depth to will be set in	the FEC at stack-depth <RSC>") and Best-rtn-subcode to stack-depth in
	the MPLS Echo Reply message.	the MPLS echo reply message.

	When the transit node in the path does not support the extensions	When the transit node in the path does not support the extensions

	defined in this document Best-return-code as 8 ("Label switched at	defined in this document, Best-return-code will be set to 8 ("Label
	stack-depth") and Best-return-subcode as Label-stack-depth to report	switched at stack-depth <RSC>") and Best-rtn-subcode to Label-stack-
	transit switching will be set in the MPLS Echo Reply message.	depth to report transit switching in the MPLS echo reply message.

	6. IANA Considerations	6. IANA Considerations


	The code points in section Section 6.1 and Section 6.2 have been
	assigned by [IANA] by early allocation on 2023-10-05 and 2021-11-08
	respectively.

	6.1. New TLV	6.1. New TLV


	[IANA] is requested to update the early allocation for Egress TLV in	IANA has added the following entry to the "TLVs" registry within the
	the "Multi-Protocol Label Switching (MPLS) Label Switched Paths	"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
	(LSPs) Ping Parameters" in the "TLVs" sub-registry to reference this	Ping Parameters" registry group [IANA-MPLS-LSP]:
	document when published as an RFC.


	+=======+=============+============================+	+=======+============+===========+
	\| Value \| Description \| Reference \|	\| Type \| TLV Name \| Reference \|
	+=======+=============+============================+	+=======+============+===========+
	\| 32771 \| Egress TLV \| Section 3 of this document \|	\| 32771 \| Egress TLV \| RFC 9655 \|
	+-------+-------------+----------------------------+	+-------+------------+-----------+


	Table 1: TLVs Sub-Registry	Table 1: TLVs Registry


	6.2. New Return code	6.2. New Return Code


	[IANA] is requested to update the early allocation of the Return Code	IANA has added the following entry to the "Return Codes" registry
	for "Replying router is an egress for the address in Egress TLV" in	within the "Multiprotocol Label Switching (MPLS) Label Switched Paths
	the "Multi-Protocol Label Switching (MPLS) Label Switched Paths	(LSPs) Ping Parameters" registry group [IANA-MPLS-LSP]:
	(LSPs) Ping Parameters" in the "Return Codes" sub-registry to
	reference this document when published as an RFC.


	+=======+================================+=============+	+=======+===================================+===========+
	\| Value \| Description \| Reference \|	\| Value \| Meaning \| Reference \|
	+=======+================================+=============+	+=======+===================================+===========+
	\| 36 \| Replying router is an egress \| Section 4.2 \|	\| 36 \| Replying router is an egress for \| RFC 9655 \|
	\| \| for the address in Egress TLV \| of this \|	\| \| the address in the Egress TLV for \| \|
	\| \| for the FEC at stack depth RSC \| document \|	\| \| the FEC at stack depth <RSC>> \| \|
	+-------+--------------------------------+-------------+	+-------+-----------------------------------+-----------+


	Table 2: Return code Sub-Registry	Table 2: Return Codes Registry

	7. Security Considerations	7. Security Considerations


	This document defines additional MPLS LSP ping TLVs and follows the	This document defines an additional TLV for MPLS LSP ping and
	mechanisms defined in [RFC8029]. All the security considerations	conforms to the mechanisms defined in [RFC8029]. All the security
	defined in [RFC8287] will be applicable for this document and, in	considerations defined in [RFC8287] apply to this document. This
	addition, they do not impose any additional security challenges to be	document does not introduce any additional security challenges to be
	considered.	considered.


	8. Implementation Status	8. References

	This section is to be removed before publishing as an RFC.

	RFC-Editor: Please clean up the references cited by this section
	before publication.

	This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of this
	Internet-Draft, and is based on a proposal described in [RFC7942].
	The description of implementations in this section is intended to
	assist the IETF in its decision processes in progressing drafts to
	RFCs. Please note that the listing of any individual implementation
	here does not imply endorsement by the IETF. Furthermore, no effort
	has been spent to verify the information presented here that was
	supplied by IETF contributors. This is not intended as, and must not
	be construed to be, a catalog of available implementations or their
	features. Readers are advised to note that other implementations may
	exist.

	8.1. Juniper Networks

	Organization: Juniper Networks

	Implementation: JUNOS

	Description: Implementation for sending and validating Egress TLV

	Maturity Level: Released
	Coverage: Full

	Contact: shraddha@juniper.net

	9. Acknowledgements

	The authors would like to thank Stewart Bryant, Greg Mirsky,
	Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for
	their careful review and comments.

	10. References


	10.1. Normative References	8.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>.

	[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,	[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
	Aldrin, S., and M. Chen, "Detecting Multiprotocol Label	Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
	Switched (MPLS) Data-Plane Failures", RFC 8029,	Switched (MPLS) Data-Plane Failures", RFC 8029,
	DOI 10.17487/RFC8029, March 2017,	DOI 10.17487/RFC8029, March 2017,

	skipping to change at page 12, line 5 ¶	skipping to change at line 479 ¶
	[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>.

	[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,	[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,
	"Updating the MPLS Label Switched Paths (LSPs) Ping	"Updating the MPLS Label Switched Paths (LSPs) Ping
	Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,	Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
	July 2021, <https://www.rfc-editor.org/info/rfc9041>.	July 2021, <https://www.rfc-editor.org/info/rfc9041>.


	[RFC9256] Filsfils, C., Talaulikar, K., Ed., Bogdanov, A., Mattes,	[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
	P., and D. Voyer, "Segment Routing Policy Architecture",	A., and P. Mattes, "Segment Routing Policy Architecture",
	RFC 9256, DOI 10.17487/RFC9256, July 2020,	RFC 9256, DOI 10.17487/RFC9256, July 2022,
	<https://www.rfc-editor.org/info/rfc9256>.	<https://www.rfc-editor.org/info/rfc9256>.


	10.2. Informative References	8.2. Informative References

	[I.D-ietf-idr-sr-policy-safi]
	Filsfils, C., Ed., Previdi, S., Ed., Talaulikar, K.,
	Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising
	Segment Routing Policies in BGP", draft-ietf-idr-sr-
	policy-safi-04, work in progress, April 2024,
	<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
	policy-safi-04>.


	[IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched	[IANA-MPLS-LSP]
		IANA, "Multiprotocol Label Switching (MPLS) Label Switched
	Paths (LSPs) Ping Parameters",	Paths (LSPs) Ping Parameters",
	<http://www.iana.org/assignments/mpls-lsp-ping-	<http://www.iana.org/assignments/mpls-lsp-ping-
	parameters>.	parameters>.


	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running	[SR-POLICY-BGP]
	Code: The Implementation Status Section", BCP 205,	Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,	P., and D. Jain, "Advertising Segment Routing Policies in
	<https://www.rfc-editor.org/info/rfc7942>.	BGP", Work in Progress, Internet-Draft, draft-ietf-idr-sr-
		policy-safi-06, 26 July 2024,
		<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
		policy-safi-06>.

		Acknowledgements

		The authors would like to thank Stewart Bryant, Greg Mirsky,
		Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for
		their careful review and comments.

	Authors' Addresses	Authors' Addresses

	Deepti N. Rathi (editor)	Deepti N. Rathi (editor)
	Nokia	Nokia
	Manyata Embassy Business Park	Manyata Embassy Business Park
	Bangalore 560045	Bangalore 560045
	Karnataka	Karnataka
	India	India
	Email: deepti.nirmalkumarji_rathi@nokia.com	Email: deepti.nirmalkumarji_rathi@nokia.com

	Shraddha Hegde (editor)	Shraddha Hegde (editor)
	Juniper Networks Inc.	Juniper Networks Inc.
	Exora Business Park	Exora Business Park
	Bangalore 560103	Bangalore 560103

	KA	Karnataka
	India	India
	Email: shraddha@juniper.net	Email: shraddha@juniper.net

	Kapil Arora	Kapil Arora
	Individual Contributor	Individual Contributor
	Email: kapil.it@gmail.com	Email: kapil.it@gmail.com


	Zafar Ali	Zafar Ali
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Email: zali@cisco.com	Email: zali@cisco.com

	Nagendra Kumar Nainar	Nagendra Kumar Nainar
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Email: naikumar@cisco.com	Email: naikumar@cisco.com

End of changes. 70 change blocks.
	341 lines changed or deleted	306 lines changed or added
This html diff was produced by rfcdiff 1.48.