<?xml version="1.0"?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC8287 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8287.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8029 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8029.xml"> nbhy   "&#8209;">
  <!ENTITY RFC3443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3443.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY RFC8402 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC9041 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9041.xml">
<!ENTITY RFC7942 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml"> wj     "&#8288;">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" docName="draft-ietf-mpls-egress-tlv-for-nil-fec-15" number="9655" ipr="trust200902" consensus="true" version="2"> version="3" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true">

  <front>
    <title abbrev="Egress Validation in LSP Ping/Traceroute ">
  Egress Ping/Traceroute">Egress Validation
    in Label Switched Path Ping and Traceroute Mechanisms</title>
    <seriesInfo name="RFC" value="9655"/>
    <author initials="D." surname="Rathi" fullname="Deepti N. Rathi" role="editor">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>Manyata Embassy Business Park</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560045</code>
          <country>India</country>
        </postal>
        <email>deepti.nirmalkumarji_rathi@nokia.com</email>
      </address>
    </author>
    <author initials="S." surname="Hegde" fullname="Shraddha Hegde" role="editor">
      <organization>Juniper Networks Inc.</organization>
      <address>
        <postal>
          <street>Exora Business Park</street>
          <city>Bangalore</city>
        <region>KA</region>
          <region>Karnataka</region>
          <code>560103</code>
          <country>India</country>
        </postal>
        <email>shraddha@juniper.net</email>
      </address>
    </author>
    <author initials="K." surname="Arora" fullname="Kapil Arora">
      <organization>Individual Contributor</organization>
      <address>
        <email>kapil.it@gmail.com</email>
      </address>
    </author>
    <author initials="Z." surname="Ali" fullname="Zafar Ali">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>zali@cisco.com</email>
      </address>
    </author>
    <author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <email>naikumar@cisco.com</email>
      </address>
    </author>
    <date year="2024"/>
  <area>Routing</area>
  <workgroup>Routing area</workgroup> year="2024" month="November"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>
    <keyword>FEC</keyword>
    <keyword>OAM</keyword>
    <keyword>OSPF</keyword>
    <keyword>IS-IS</keyword>
    <keyword>SPRING</keyword>
    <abstract>
      <t>
	The MPLS ping and traceroute mechanisms, as mechanisms described in <xref target="RFC8029"/> RFC 8029 and the
	related extensions for Segment Routing (SR) defined in <xref target="RFC8287"/>,
	is RFC 8287 are
	highly valuable for validating control plane and data plane
	synchronization.  In certain environments, only some intermediate or
	transit nodes may have been upgraded to support these validation
	procedures. A straightforward MPLS ping and traceroute mechanism
	allows traversing traversal of any path without validating validation of the control plane
	state. <xref target="RFC8029"/> RFC 8029 supports this mechanism with the Nil Forwarding
	Equivalence Class (FEC). The procedures outlined in <xref target="RFC8029"/>
	is RFC 8029 are
	primarily applicable when the Nil FEC is used as an intermediate FEC
	in the label FEC stack. However, challenges arise when all labels in the
	label stack are represented using the Nil FEC.</t>
      <t>This document introduces a new Type-Length-Value (TLV) as an extension
	to the existing Nil FEC. It describes MPLS ping and traceroute procedures
	using the Nil FEC with this extension to address and overcome these challenges.</t>
    </abstract>

  <note title="Requirements Language">
    <t>
	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
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
	they appear in all capitals, as shown here.
	</t>
  </note>
  </front>
  <middle>
    <section title="Introduction" anchor='intro'> anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Segment routing supports the creation of explicit paths by using one or more
	Link State
	Link-State IGP Segments or BGP Segments defined in <xref target="RFC8402"/>. target="RFC8402" format="default"/>.
	In certain use cases, the TE paths are
	built using mechanisms described in <xref target="RFC9256"/> target="RFC9256" format="default"/>
	by stacking the labels that represent the nodes and links in the explicit path.
	Controllers are often deployed to construct paths across multi-domain networks.
	In such deployments, the head-end headend routers may
	have the link state link-state database of its their domain and may not be aware of the FEC
	associated with labels that are used by the controller to build
	paths across multiple domains. A very useful
	Operations, Administration, and Maintenance (OAM) requirement
	is to be able to ping and trace these paths. </t>
      <t>

	<xref target="RFC8029"/> target="RFC8029" format="default"/> describes a simple and
	efficient mechanism to detect
   data-plane data plane failures in MPLS Label
	Switched Paths (LSPs).  It defines a probe message called an "MPLS
	echo request" and a response message called an "MPLS echo reply" for
	returning the result of the probe.  SR-related extensions to Echo Request/Echo Reply for these
	are specified in <xref target="RFC8287"/>. target="RFC8287" format="default"/>. <xref target="RFC8029"/> primarily
	target="RFC8029" format="default"/> provides mechanisms primarily to
	validate the data plane and, secondarily, and secondarily to verify the consistency of
	the data plane with the control plane.  It also provides the ability
	to traverse
	 Equal-cost Multiple Paths (ECMP) Equal-Cost Multipaths (ECMPs) and validate each of the
	ECMP paths.  The Target FEC Stack TLV <xref target="RFC8029"/> target="RFC8029"
	format="default"/> contains sub-TLVs that carry information about the
	label. This information gets validated on each node for traceroute and
	on the egress for ping.  The use of the Target FEC Stack TLV requires all nodes
	in the network to have implemented the validation
	procedures. All procedures, but all
	intermediate nodes may not have been upgraded to support validation
	procedures. In such cases, it is useful to have the ability to
	traverse the paths in ping/traceroute mode without having to obtain
	the FEC for each label. </t>

      <t>A simple MPLS
	Echo Request/Echo Reply echo request/reply mechanism allows for traversing the
      SR Policy path without validating the control plane state. <xref target="RFC8029"/>
      target="RFC8029" format="default"/> supports this mechanism with FECs
      like the Nil FEC  and the Generic FEC.
 FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix).  However, there are challenges in reusing
      the Generic FEC and Nil FEC and Generic FECs for validation of SR policies Policies <xref target="RFC9256"/>.
      target="RFC9256" format="default"/>.  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 the Generic FEC FECs is the
      IPv4 or IPv6 prefix and prefix length. Thus Thus, the Generic FEC types perform
      an additional control plane validation. However, the details of Generic FEC
      FECs and relevant validation procedures are not very thoroughly detailed in the <xref target="RFC8029"/>.
      target="RFC8029" format="default"/>.

	The use-case use case mostly specifies inter-AS (Autonomous System) VPNs as the motivation.
	Certain aspects of SR SR, such as anycast SIDs Segment Identifiers (SIDs), require clear guidelines
	on how the validation procedure should work. Also, the Generic FEC FECs may not be widely
	supported
	supported, and if transit routers are not upgraded to support validation of Generic
	FEC,
	FECs, traceroute may fail.
	On the other hand, the Nil FEC consists of the label label, and there is no other associated
	FEC information. The Nil FEC is used to traverse the path without validation for
	cases where the FEC is not defined or routers are not upgraded to support the
	FECs. Thus, it can be used to check any combination of segments on any data path.
	The procedures described in <xref target="RFC8029"/> target="RFC8029" format="default"/> are mostly applicable when the
 Nil FEC is used where the Nil FEC is as an intermediate FEC in the
	label FEC stack. When
 Challenges arise when all labels in the label-stack is label stack are represented
 using the Nil FEC,
	it poses some challenges.</t> FEC.</t>
      <t>  <xref target="Problems_with_Nil_FEC"/> target="Problems_with_Nil_FEC" format="default"/> discusses the problems
	associated with using the Nil FEC in an MPLS ping/traceroute procedure procedure, and Sections
	<xref target="egress_tlv"/> target="egress_tlv" format="counter"/> and <xref target="detail_procedure"/> target="detail_procedure" format="counter"/> discuss
	simple extensions needed to solve the problem.
      </t>
      <t>The problems and the solutions described in this document apply to the
	MPLS data plane. SRv6 Segment Routing over IPv6 (SRv6) is out-of-scope out of scope for this document.</t>
      <section anchor="Requirements_Language" numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

      </section>

    </section>

    <section anchor='Problems_with_Nil_FEC' title='Problem anchor="Problems_with_Nil_FEC" numbered="true" toc="default">
      <name>Problem with Nil FEC'> FEC</name>
      <t>The purpose of the Nil FEC FEC, as described in <xref target="RFC8029"/> target="RFC8029" format="default"/>, is to
	ensure hiding of that transit tunnel information and is hidden and, in some cases cases, to avoid false
	negatives when the FEC information is unknown.</t>
      <t>This document uses a Nil FEC to represent the complete label stack in an
	MPLS Echo Request echo request message in ping and traceroute mode. A single Nil FEC is used
	in the MPLS Echo Request echo request message irrespective of the number of segments in the
      label stack. As described in sec 4.4.1 of <xref target="RFC8029"/>,
	"If target="RFC8029" format="default" sectionFormat="of" section="4.4.1"/> notes:</t>
      <blockquote><t>
	If the outermost FEC of the Target FEC stack is the Nil FEC, then the
	node MUST <bcp14>MUST</bcp14> skip the Target FEC validation completely."
   When completely.</t>
      </blockquote>
   <t>When a router in the label-stack label stack path receives an MPLS
	Echo Request
	echo request message, there is no definite way to decide whether it is
	the intended egress router since the Nil FEC does not carry any information and no validation
	is performed by the router.
	So
	Thus, there is a high possibility that the packet may be mis-forwarded misforwarded to an incorrect
	destination but the MPLS Echo Reply echo reply might still return success.</t>
      <t>
 To mitigate this issue, it is necessary to include additional
	information information,
 along with the Nil FEC, in the MPLS Echo Request echo request message in both ping and
 traceroute
	modes, along with the Nil FEC, modes and to perform minimal validation on the egress/destination
 router.
	This will enable the router to send appropriate
	success and failure information to the headend router of the SR Policy. This supplementary
	information should assist in reporting transit router details to the
	headend router, which can be utilized by an offline application
	to validate the traceroute path.
      </t>

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

      <t>If a transit node does not recognize the Egress TLV and chooses to silently
	drop or step over the Egress TLV, the
	headend will continue to send the Egress TLV in the next echo request
	message
	message, and if egress recognizes the Egress TLV, egress validation
	will be executed at the egress.
	If a transit node does not recognize the Egress TLV and chooses to send an error
	message, the headend will log the message for informational purposes and
	continue to send echo requests with the Egress TLV, with the TTL incremented.

	If the egress node does not recognize the Egress TLV and chooses to silently
	drop or step over the Egress TLV, egress validation will not be done done,
	and the ping/traceroute procedure will proceed as if the Egress TLV is were
	not received.
      </t>
    </section>
    <section title="Egress TLV" anchor='egress_tlv'> anchor="egress_tlv" numbered="true" toc="default">
      <name>Egress TLV</name>

      <t>
	The Egress TLV MAY <bcp14>MAY</bcp14> be included in an MPLS Echo Request echo request message.
	It is an optional TLV and, if present, MUST <bcp14>MUST</bcp14> appear before the
	Target FEC stack Stack TLV in the MPLS Echo Request echo request packet. This TLV can
	only be used in LSP ping/traceroute requests, requests that are generated by
	the head-end headend node of an LSP or SR policy Policy for which verification
	is performed. In cases where multiple Nil FECs are present in
	the Target FEC Stack TLV, the Egress TLV must be added corresponding
	to the ultimate egress of the label stack. Explicit paths can be
	created using Node-SID, Adj-SID,
	Binding-SID,
	Binding SID, etc. The address Address field of the Egress TLV must be derived
	from the path egress/destination. The format is as specified below: in <xref target="pic_egress_tlv"/>.
      </t>
      <figure anchor="pic_egress_tlv" title="Egress TLV">
    <artwork> anchor="pic_egress_tlv">
        <name>Egress TLV</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Type = 32771 (Egress TLV)  |          Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Address (4 or 16 octets)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    </artwork>
]]></artwork>
      </figure>
        <t>Type             : 32771

<dl>
  <dt>Type:</dt>
  <dd>32771 (<xref target="tlv"/>)</t>

        <t>Length           : variable based on IPV4/IPV6 address. target="tlv" format="default"/>)</dd>

  <dt>Length:</dt>
  <dd>Variable (4 octets for IPv4 addresses and 16 octets for IPv6 addresses).
  Length excludes the length of the Type and Length fields. Length will be 4 octets for IPv4 and
                              16 octets for IPv6.</t>

        <t>Address          : This
  </dd>

  <dt>Address:</dt>
  <dd>This field carries a valid 4-octet IPv4 address of length
                              4 octets or a valid
  16-octet IPv6 address.  The address of length 16 octets.
                              It can be obtained from the egress of the path.
                              It
  path and corresponds to the last label in the label stack or the SR policy endpoint Policy
  Endpoint field <xref target="I.D-ietf-idr-sr-policy-safi"/>.
                              </t> target="I-D.ietf-idr-sr-policy-safi"
  format="default"/>.</dd>
</dl>
    </section>
    <section title="Procedure" anchor='detail_procedure'> anchor="detail_procedure" numbered="true" toc="default">
      <name>Procedure</name>
      <t>This section describes aspects of LSP ping and traceroute operations that
	require further considerations beyond those detailed in <xref target="RFC8029"/>.</t> target="RFC8029" format="default"/>.</t>
      <section title="Sending anchor="send_procedure" numbered="true" toc="default">
        <name>Sending Egress TLV in MPLS Echo Request" anchor='send_procedure'> Request</name>
        <t>As previously mentioned, when the sender node constructs
	  an Echo Request echo request with a Target FEC Stack TLV, the Egress TLV,
	  if present, MUST <bcp14>MUST</bcp14> appear before the Target FEC Stack TLV in
	  the MPLS Echo Request echo request packet.</t>
        <section title="Ping Mode" anchor='ping_procedure'> anchor="ping_procedure" numbered="true" toc="default">
          <name>Ping Mode</name>
          <t>When the sender node constructs an Echo Request echo request with target a Target FEC Stack TLV
		that contains a single Nil FEC corresponding to the last segment of the
		SR Policy path, the sender node MUST <bcp14>MUST</bcp14> add an Egress TLV with the address obtained from
		the SR policy endpoint Policy Endpoint field <xref target="I.D-ietf-idr-sr-policy-safi"/>. target="I-D.ietf-idr-sr-policy-safi" format="default"/>.
		The Label value in the Nil FEC MAY <bcp14>MAY</bcp14> be set to zero when a single Nil FEC is
		added for multiple labels in the label stack.
		In case the endpoint is not specified or is equal to zero
		(Sec 8.8.1 <xref target="RFC9256"/>),
		(<xref target="RFC9256" format="default" sectionFormat="of" section="8.8.1"/>), the sender MUST <bcp14>MUST</bcp14> use the
		address corresponding to the last segment of the SR Policy
		in the address Address field for of
		the Egress TLV. Some specific cases on how to derive the address Address field
		in the Egress TLV are listed below:</t>
		<t>
		 <list>
		<t>a.	If
          <ul spacing="normal">
            <li>
              <t>If the last SID in the SR policy Policy is an Adj-SID,
		the address Address field in the Egress TLV is derived from the node
		at the remote end of the corresponding adjacency.</t>
		<t>b.	If
            </li>
            <li>
              <t>If the last SID in the SR policy Policy is a Binding SID,
		the address Address field in the Egress TLV is derived from the
		last node of the path represented by the Binding SID.</t>
        </list>
        </t>
            </li>
          </ul>
        </section>
        <section title="Traceroute Mode" anchor='traceroute_procedure'> anchor="traceroute_procedure" numbered="true" toc="default">
          <name>Traceroute Mode</name>
          <t>When the sender node builds an Echo Request echo request with target a Target FEC Stack TLV
		that contains a Nil FEC corresponding to the last segment of the segment-list segment list of
		the SR Policy, the sender node MUST <bcp14>MUST</bcp14> add an Egress TLV with the address obtained
		from the SR policy endpoint Policy Endpoint field
		<xref target="I.D-ietf-idr-sr-policy-safi"/>. target="I-D.ietf-idr-sr-policy-safi" format="default"/>.
          </t>

	  <t> Although there is no requirement to do so, an implementation MAY
          <bcp14>MAY</bcp14> send multiple Nil FECs if that makes it easier
          for the implementation.
        In case  If the SR Policy headend sends
          multiple Nil FECs FECs, the last one MUST <bcp14>MUST</bcp14> correspond to
          the Egress TLV.  The Label value in the Nil FEC MAY <bcp14>MAY</bcp14>
          be set to zero for the last Nil FEC.
		In case  If the endpoint is not
          specified or is equal to zero
		(Sec 8.8.1 <xref target="RFC9256"/>), (<xref target="RFC9256"
          format="default" sectionFormat="of" section="8.8.1"/>), the sender MUST
          <bcp14>MUST</bcp14> use the address corresponding to the last
          segment endpoint of the SR Policy path i.e. (i.e., the ultimate egress is used as the
          address for in the Egress TLV. TLV).
          </t>
        </section>
        <section title="Detailed Example" anchor='detail_example'> anchor="detail_example" numbered="true" toc="default">
          <name>Detailed Example</name>
          <figure anchor="example_topology" title="Egress anchor="example_topology">
            <name>Egress TLV processing on sample topology">
        <artwork> Processing in Sample Topology</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                  ----R3----
                 /  (1003)  \
      (1001)    /            \(1005)     (1007)
        R1----R2(1002)        R5----R6----R7(address X)
                \            /     (1006)
                 \   (1004) /
                  ----R4----
        </artwork>
]]></artwork>
          </figure>
          <t>Consider the SR Policy configured on router R1, R1 to destination X,
		configured with label-stack label stack as 1002, 1004, 1007.
		Segment 1007 belongs to R7, which has the address X
		locally	configured on it.
          </t>
          <t>Let us look at an example of a ping Echo Request echo request message.  The Echo Request
          echo request message contains a Target FEC stack Stack TLV with the Nil
          FEC sub-TLV.  An Egress TLV is added before the Target FEC Stack
          TLV. The address Address field contains X (corresponding to a locally
          configured address on R7). X could be an IPv4 or IPv6 address address, and
          the Length field in the Egress TLV will be either 4 or 16 octets,
          based on the address X's type of address type. X.
          </t>
          <t>Let us look at an example of an Echo Request echo request message in a
          traceroute packet.  The Echo Request echo request message contains a Target FEC stack
          Stack TLV with the Nil FEC sub-TLV corresponding to the complete label-stack
          label stack (1002, 1004, 1007).  An Egress TLV is added before the
          Target FEC Stack TLV.  The address Address field contains X (corresponding
          to a locally configured address on destination R7). X could be an
          IPv4 or IPv6 address address, and the Length field in the Egress TLV will be either
          4 or 16 octets, based on the address X's type of address type. X.  If the
          destination/endpoint is set to zero (as in the case of the
          color-only SR Policy) Policy), the sender should use the endpoint of segment
          1007 (the last segment in the segment list) as an the address for the
          Egress TLV.

          </t>
        </section>
      </section>
      <section title="Receiving anchor="recv_procedure" numbered="true" toc="default">
        <name>Receiving Egress TLV in MPLS Echo Request"
	anchor='recv_procedure'> Request</name>
        <t>Any node that receives the an MPLS Echo Request echo request message and processes it, it
	  is referred to as the "receiver". In the case of the ping procedure,
	  the actual destination/egress is the receiver.
	  In the case of traceroute, every node is a receiver.

	  This document does not propose any change in the processing
	  for of the
	  Nil FEC as (as defined in <xref target="RFC8029"/> target="RFC8029" format="default"/>) in
	  the Target FEC stack TLV Node node that receives an MPLS echo request. request with a Target FEC Stack
	  TLV.  The presence of the Egress TLV does not affect the validation
	  of the Target FEC Stack sub-TLV at FEC-stack-depth if it is
	  different than Nil FEC.</t>
        <t>Additional processing MUST <bcp14>MUST</bcp14> be done for the Egress TLV on
	  the receiver node as follows: follows. Note that &lt;RSC&gt; refers to the Return Subcode.
        </t>
      <t>1. If

<ol spacing="normal" type="1">
        <li><t>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 8 ("Label switched at stack-depth") stack-depth &lt;RSC&gt;")
	  and Best-return-subcode Best-rtn-subcode to Label-stack-depth to report transit switching
	  in the MPLS Echo Reply message.</t>
	  <t>2. If echo reply message.</t></li>
        <li><t>If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
	  FEC-stack-depth is Nil FEC FEC, then do the a lookup for an exact match of the
	   Address field of the Egress TLV address field to any of the locally configured interfaces
	  or loopback addresses.</t>
	  <t>       2a. If
	  <ol spacing="normal" type="a">
            <li>If the Egress TLV address lookup succeeds,
	  set Best-return-code to 36 ("Replying router is an egress for the
	  address in the Egress TLV for the FEC at stack depth RSC") &lt;RSC&gt;")

	  (<xref target="ret_code"/>) target="ret_code" format="default"/>) in the MPLS Echo Reply message.</t>
      <t>      2b. If echo reply message.</li>
        <li>If the Egress TLV address lookup fails,
	  set the Best-return-code to 10, "Mapping 10 ("Mapping for this FEC is not the given
	label at stack-depth RSC" </t>
	  <t> &lt;RSC&gt;").</li>
	  </ol>
	</li>
<!-- [rfced] This long sentence is difficult to follow. May we break it up into
several sentences to improve readability? Also, please clarify "one each
corresponding to the labels in the label stack along with Egress TLV".

Original:
  3. In cases where multiple Nil FECs are sent from the SR Policy headend, one
  each corresponding to the labels in the label stack along with Egress TLV,
  when the packet reaches the egress, the number of labels in the received
  packet (Size of stack-R) becomes zero or a label with Bottom-of-Stack bit set
  to 1 is processed, all Nil FEC sub-TLVs MUST be removed and the Egress TLV
  MUST be validated.
		</t>

Perhaps:
  3. In some cases, multiple Nil FECs (one corresponding to each label in the
  label stack), along with the Egress TLV, are sent from the SR Policy headend.
  When the packet reaches the egress, the number of labels in the
  received packet (size of stack-R) becomes zero, or a label with the
  Bottom-of-Stack bit set to 1 is processed. All Nil FEC sub-TLVs
  MUST be removed, and the Egress TLV MUST be validated.

Or:
  3. If multiple Nil FECs (one corresponding to each label in the
  label stack), along with the Egress TLV, are sent from the SR Policy headend,
  when the packet reaches the egress, the number of labels in the
  received packet (size of stack-R) becomes zero, or a label with the
  Bottom-of-Stack bit set to 1 is processed. All Nil FEC sub-TLVs
  MUST be removed, and the Egress TLV MUST be validated.
-->
        <li><t>In cases where multiple Nil FECs are sent from the SR Policy headend,
	  one each corresponding to the	labels in the label stack along with the Egress TLV, when the packet reaches the egress, the number of labels in the received packet (Size of stack-R) becomes zero or a label with the Bottom-of-Stack bit set to 1 is processed, all Nil FEC sub-TLVs <bcp14>MUST</bcp14> be removed and the Egress TLV <bcp14>MUST</bcp14> be validated.</t></li>

</ol>

      </section>
    </section>
    <section anchor='backward_compatibility' title='Backward Compatibility'> anchor="backward_compatibility" numbered="true" toc="default">
      <name>Backward Compatibility</name>
      <t>The extensions defined in this document is are backward compatible with the
	procedures described in <xref target="RFC8029"/>. target="RFC8029" format="default"/>. A Router router that does not
	support the Egress TLV, TLV will ignore it and use current the Nil-FEC Nil FEC procedures
	described in <xref target="RFC8029"/>. target="RFC8029" format="default"/>.
      </t>
    <t>When
      <t>
 When the egress node in the path does not support the extensions
 defined in this document document, egress validation will not be done done, and Best-return-code as will be set to 3 ("Replying router is an egress for the FEC at stack-depth") stack-depth &lt;RSC&gt;") and	Best-return-
	subcode set Best-rtn-subcode to stack-depth to will be set in
 the MPLS Echo Reply echo reply message.
      </t>
      <t>When the transit node in the path does not support the extensions defined
	in this document document, Best-return-code as will be set to 8 ("Label switched at stack-depth") stack-depth &lt;RSC&gt;") and
	Best-return-subcode as
	Best-rtn-subcode to Label-stack-depth to report transit switching will be
	set
	in the MPLS Echo Reply echo reply message.
      </t>
    </section>
    <section anchor="iana_con" title="IANA Considerations">
    <t>The code points in section <xref target="tlv"/> and <xref target="ret_code"/>
	have been assigned by <xref target="IANA"/> by early allocation on 2023-10-05
	and 2021-11-08 respectively.
	</t> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="tlv" title="New TLV">

	  <t> <xref target="IANA"/> is requested numbered="true" toc="default">
        <name>New TLV</name>
        <t>IANA has added the following entry to update the early
	  allocation for Egress TLV in "TLVs" registry within
        the
	  "Multi-Protocol "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "TLVs" sub-registry to reference this
   document when published as an RFC. registry group <xref target="IANA-MPLS-LSP" format="default"/>:
        </t>
	  <texttable
        <table anchor="iana_tlvs_tbl" title="TLVs Sub-Registry">
        <ttcol align="left">Value</ttcol>
        <ttcol align="center">Description</ttcol>
        <ttcol align="left">Reference</ttcol>
        <c>32771</c>
        <c>Egress TLV</c>
        <c><xref target="egress_tlv"/> of this document</c>
      </texttable> align="center">
          <name>TLVs Registry</name>
          <thead>
            <tr>
              <th align="left">Type</th>
              <th align="left">TLV Name</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">32771</td>
              <td align="left">Egress TLV</td>
              <td align="left">RFC 9655</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="ret_code" title="New numbered="true" toc="default">
        <name>New Return code"> Code</name>
        <t> <xref target="IANA"/> is requested to update the
	  early allocation of IANA has added the Return Code for
	  "Replying router is an egress for following entry to the address in Egress TLV" in "Return Codes" registry
        within the
	  "Multi-Protocol "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Return Codes" sub-registry to reference this
   document when published as an RFC. registry group <xref target="IANA-MPLS-LSP"
        format="default"/>:
        </t>
	  <texttable
        <table anchor="iana_return_code_tbl" title="Return code Sub-Registry">
        <ttcol align="left">Value</ttcol>
        <ttcol align="center">Description</ttcol>
        <ttcol align="left">Reference</ttcol>
        <c>36</c>
        <c>Replying align="center">
          <name>Return Codes Registry</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Meaning</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">36</td>
              <td align="left">Replying router is an egress for the
	  address in the Egress TLV for the FEC at stack depth RSC</c>
        <c><xref target="recv_procedure"/> of this document</c>
        </texttable> &lt;RSC&gt;></td>
              <td align="left">RFC 9655</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section title='Security Considerations' anchor='sec-con'> anchor="sec-con" numbered="true" toc="default">
      <name>Security Considerations</name>

<t>This document defines an additional TLV for MPLS LSP ping TLVs and follows conforms to
	the mechanisms defined in <xref target="RFC8029"/>. target="RFC8029" format="default"/>.
	All the security considerations defined in <xref target="RFC8287"/> will
	be applicable for target="RFC8287" format="default"/> apply to this document. This document and, in addition, they do does not impose
 introduce any additional security challenges to be considered.
      </t>
    </section>

  <section title='Implementation Status'>
   <t>This section is to be removed before publishing as an RFC.</t>

   <t>RFC-Editor: Please clean up the references cited by this section
   before publication.</t>
   <t>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 <xref target="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.</t>
   <section title='Juniper Networks'>
   <t>Organization: Juniper Networks</t>
   <t>Implementation: JUNOS</t>
   <t>Description: Implementation for sending and validating Egress TLV</t>
   <t>Maturity Level: Released</t>
   <t>Coverage: Full</t>
   <t>Contact: shraddha@juniper.net</t>
   </section>
    </section>
  <section title='Acknowledgements' anchor='ack'>
    <t> The authors would like to thank Stewart Bryant, Greg Mirsky, Alexander Vainshtein,
	Sanga Mitra Rajgopal, and Adrian Farrel for their careful review and comments.</t>
  </section>
  </middle>
  <back>
  <references title='Normative References'>
  &RFC9041;
  &RFC8402;

     <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
       <front>
         <title>Key words for use in RFCs to Indicate Requirement Levels</title>
         <author initials="S." surname="Bradner" fullname="S. Bradner"/>
         <date year="1997" month="March"/>
         <abstract>
           <t>In many standards track documents several words are used to
		   signify the requirements in the specification.  These words are often
		   capitalized. This document defines these words as they should be
		   interpreted in IETF documents.  This document specifies an Internet
		   Best Current Practices for the Internet Community, and requests
		   discussion and suggestions for improvements.</t>
         </abstract>
       </front>
       <seriesInfo name="BCP" value="14"/>
       <seriesInfo name="RFC" value="2119"/>
       <seriesInfo name="DOI" value="10.17487/RFC2119"/>
     </reference>
     <reference anchor="RFC8029" target="https://www.rfc-editor.org/info/rfc8029">
       <front>
         <title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane
		 Failures</title>
         <author initials="K." surname="Kompella" fullname="K. Kompella"/>
         <author initials="G." surname="Swallow" fullname="G. Swallow"/>
         <author initials="C." surname="Pignataro" fullname="C. Pignataro"
		 role="editor"/>
         <author initials="N." surname="Kumar" fullname="N. Kumar"/>
         <author initials="S." surname="Aldrin" fullname="S. Aldrin"/>
         <author initials="M." surname="Chen" fullname="M. Chen"/>
         <date year="2017" month="March"/>
         <abstract>
           <t>This document describes a simple and efficient mechanism to detect
		   data-plane failures in Multiprotocol Label Switching (MPLS) Label
		   Switched Paths (LSPs).  It defines a probe message called an "MPLS
		   echo request" and a response message called an "MPLS echo reply" for
		   returning the result of the probe.  The MPLS echo request is intended
		   to contain sufficient information to check correct operation of the
		   data plane and to verify the data plane against the control plane,
		   thereby localizing faults.</t>
           <t>This document obsoletes RFCs 4379, 6424, 6829, and 7537,
		   and updates RFC 1122.</t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="8029"/>
       <seriesInfo name="DOI" value="10.17487/RFC8029"/>
     </reference>
     <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
       <front>
         <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
         <author initials="B." surname="Leiba" fullname="B. Leiba"/>
         <date year="2017" month="May"/>
         <abstract>
           <t>RFC 2119 specifies common key words that may be used in protocol
		   specifications.  This document aims to reduce the ambiguity by
		   clarifying that only UPPERCASE usage of the key words have the
		   defined special meanings.</t>
         </abstract>
       </front>
       <seriesInfo name="BCP" value="14"/>
       <seriesInfo name="RFC" value="8174"/>
       <seriesInfo name="DOI" value="10.17487/RFC8174"/>
     </reference>
     <reference anchor="RFC8287" target="https://www.rfc-editor.org/info/rfc8287">
       <front>
         <title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing
		 (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS
		 Data Planes</title>
         <author initials="N." surname="Kumar" fullname="N. Kumar"
		 role="editor"/>
         <author initials="C." surname="Pignataro" fullname="C. Pignataro"
		 role="editor"/>
         <author initials="G." surname="Swallow" fullname="G. Swallow"/>
         <author initials="N." surname="Akiya" fullname="N. Akiya"/>
         <author initials="S." surname="Kini" fullname="S. Kini"/>
         <author initials="M." surname="Chen" fullname="M. Chen"/>
         <date year="2017" month="December"/>
         <abstract>
           <t>A Segment Routing (SR) architecture leverages source routing and
		   tunneling paradigms and can be directly applied to the use of a
		   Multiprotocol Label Switching (MPLS) data plane. A node steers a
		   packet through a controlled set of instructions called "segments" by
		   prepending the packet with an SR header.
		   </t>
           <t>The segment assignment and forwarding semantic nature of SR raises
		   additional considerations for connectivity verification and fault
		   isolation for a Label Switched Path (LSP) within an SR architecture.
		   This document illustrates the problem and defines extensions to
		   perform LSP ping and traceroute for Segment Routing IGP-Prefix and
		   IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.
		   </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="8287"/>
       <seriesInfo name="DOI" value="10.17487/RFC8287"/>
     </reference>
     <reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256">
       <front>
         <title>Segment Routing Policy Architecture</title>
         <author initials="C." surname="Filsfils" fullname="C. Filsfils"/>
         <author initials="K." surname="Talaulikar " fullname="K. Talaulikar"
		 role="editor"/>
         <author initials="A." surname="Bogdanov" fullname="A. Bogdanov"/>
         <author initials="P." surname="Mattes" fullname="P. Mattes"/>
         <author initials="D." surname="Voyer" fullname="D. Voyer"/>
         <date year="2020" month="July"/>
         <abstract>
           <t>Segment Routing (SR) allows a headend node to steer a packet flow
		   along any path. Intermediate per-flow states are eliminated thanks to
		   source routing. The headend node steers a flow into an SR Policy. The
		   header of a packet steered in an SR Policy is augmented with an
		   ordered list of segments associated with that SR Policy.
		   This document details the concepts of SR Policy and steering into an
		   SR Policy.
		   </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="9256"/>
       <seriesInfo name="DOI" value="10.17487/RFC9256"/>
     </reference>
    <displayreference target="I-D.ietf-idr-sr-policy-safi" to="SR-POLICY-BGP"/>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9041.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8287.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
      </references>
   <references title='Informative References'>
      <references>
        <name>Informative References</name>

        <reference anchor="IANA" anchor="IANA-MPLS-LSP" target="http://www.iana.org/assignments/mpls-lsp-ping-parameters">
          <front>
            <title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
		 Ping Parameters</title>
		 <author fullname="IANA"/>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
         <abstract>
           <t></t>
         </abstract>
          </front>
        </reference>

<!-- [I-D.ietf-idr-sr-policy-safi] IESG state: I-D Exists as of 9/5/24; Updated to long way to add "Ed." for K. Talaulikar-->

<reference anchor="I.D-ietf-idr-sr-policy-safi"
	 target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-04"> anchor="I-D.ietf-idr-sr-policy-safi" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-09">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils"
		 role="editor"/>
         <author initials="S." surname="Previdi" fullname="S. Previdi"
		 role="editor"/> fullname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar " fullname="K. Talaulikar"/> surname="Talaulikar" fullname="Ketan Talaulikar" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mattes" fullname="P. Mattes"/>
         <author initials="E." surname="Rosen" fullname="Eric C. Rosen"/> fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="D. Jain"/>
         <author initials="S." surname="Lin" fullname="S. Lin"/> fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date year="2024" month="April"/>
         <abstract>
           <t>A Segment Routing (SR) Policy is an ordered list of segments
		   (i.e., instructions) that represent a source-routed policy.
		   An SR Policy consists of one or more candidate paths, each consisting
		   of one or more segment lists. A headend may be provisioned with candidate
		   paths for an SR Policy via several different mechanisms, e.g., CLI, NETCONF,
		   PCEP, or BGP.This document specifies how BGP may be used to distribute SR
		   Policy candidate paths. It introduces a BGP SAFI to advertise a candidate
		   path of a Segment Routing (SR) Policy and defines sub-TLVs for the Tunnel
		   Encapsulation Attribute for signaling information about these candidate
		   paths.This documents updates RFC9012 with extensions to the Color Extended
		   Community to support additional steering modes over SR Policy.
		   </t>
         </abstract> month="October" day="3" year="2024"/>
</front>
<seriesInfo name="" value="draft-ietf-idr-sr-policy-safi-04"/>
       <seriesInfo name="" value="work in progress"/> name="Internet-Draft" value="draft-ietf-idr-sr-policy-safi-09"/>
</reference>
	 &RFC7942;

      </references>
    </references>
    <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t> The authors would like to thank <contact fullname="Stewart
      Bryant"/>, <contact fullname="Greg Mirsky"/>, <contact
      fullname="Alexander Vainshtein"/>, <contact fullname="Sanga Mitra
      Rajgopal"/>, and <contact fullname="Adrian Farrel"/> for their careful
      review and comments.</t>
    </section>
  </back>

</rfc>