<?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="September"/>
    <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 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"
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
<!-- [rfced] Will readers know what "its" refers to in this document the phrase "of its
domain"?

Original:
   Controllers are often deployed
   to construct paths across multi-domain networks.  In such
   deployments, the head-end routers may have the link state database of
   its domain and may not be interpreted as described in BCP 14
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, aware of the FEC associated with labels
   that are used by the controller to build paths across multiple
   domains.

Perhaps:
   Controllers are often deployed
   to construct paths across multi-domain networks.  In such
   deployments, the headend routers may have the link-state database of
   their domain and only when,
	they appear in all capitals, as shown here.
	</t>
  </note>

</front>

<middle>
  <section title="Introduction" anchor='intro'> may not be aware of the FEC associated with labels
   that are used by the controller to build paths across multiple
   domains.
-->

      <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 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>

<!-- [rfced] Is "Target FEC" correct here, or should this be updated to either
"the Target FEC Stack TLV" or "Target FEC Stack"?

Original:
   The use of
   Target FEC requires all nodes in the network to have implemented the
   validation procedures.
-->

	<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 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>

<!-- [rfced] The third paragraph in Section 1 mentions "Generic FEC" several
times. Does "Generic FEC" mean "Generic IPv4 prefix" and "Generic
IPv6 prefix", which are defined in RFC 8029? If so, would it be helpful
to clarify this in the first mention and update "Generic FEC" to "Generic
FECs" (plural) elsewhere? Please review and let us know if any updates
are needed.

Original:
   [RFC8029] supports this mechanism with FECs like Nil FEC and Generic
   FEC.

Perhaps:
   [RFC8029] supports this mechanism with FECs like the Nil FEC and the Generic
   FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix).
-->

<!-- [rfced] How may we revise this sentence to avoid "details...are not very
detailed"?

Original:
   However, the details of Generic FEC and validation procedures are not
   very detailed in the [RFC8029].

Perhaps:
   However, the Generic FEC and relevant validation procedures are not thoroughly
   detailed in [RFC8029].
-->

      <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 Generic FEC.  However, there are challenges in reusing
      the Generic Nil FEC and Nil Generic FEC 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 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 the Generic
      FEC and validation procedures are not very detailed in the <xref target="RFC8029"/>.
      target="RFC8029" format="default"/>.

<!-- [rfced] FYI - We updated "when the Nil FEC is used where the Nil FEC is
intermediate" as follows to improve readability and align with similar
text in the abstract.

Original:
  The procedures described in [RFC8029] are
  mostly applicable when the Nil FEC is used where the Nil FEC is
  intermediate in the label stack.  When all labels in the label stack
  are represented using Nil FEC, it poses some challenges.

Current:
   The procedures described in [RFC8029] are mostly applicable when the
   Nil FEC is used as an intermediate FEC in the label stack.
   Challenges arise when all labels in the label stack are represented
   using the Nil FEC.
-->
	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 may not be widely
	supported
	supported, and if transit routers are not upgraded to support validation of Generic
	FEC, 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 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>
<!-- [rfced] May we update this sentence as follows to improve clarity?

Current:
   To mitigate this issue, it is necessary to include additional
   information in the MPLS Echo Request echo request message in both ping and
   traceroute modes, along with the Nil FEC, to perform minimal
   validation on the egress/destination router.

Perhaps (moved "along with the Nil FEC" and added "and" before "to perform"):
   To mitigate this issue, it is necessary to include additional information,
   along with the Nil FEC, in the MPLS echo request message in both ping and
   traceroute modes and to perform minimal validation on the egress/destination
   router.
-->
	To mitigate this issue, it is necessary to include additional
	information in the MPLS echo request message in both ping and traceroute
	modes, along with the Nil FEC, 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>
<!-- [rfced] Will readers understand what "It" refers to here?

Original:
   It can be employed to verify any combination of
   segments on any path without requiring upgrades to transit nodes.

Perhaps:
   Egress information can be employed to verify any combination of
   segments on any path without requiring upgrades to transit nodes.
-->

<!-- [rfced] We updated the first sentence below for clarity. Would it be
helpful to further update this text by combining the first and second
sentences? Please review the suggestion below and let us know your
thoughts.

Original:
   The code point used for the Egress TLV is from the range 32768-65535
   and can be silently dropped if not recognized as per [RFC8029] and
   the clarifications from [RFC9041]. Alternately, the unrecognized TLV
   may be stepped over or an error message may be sent.

Current:
   The Egress TLV can be silently dropped if not recognized, as per
   [RFC8029] and the clarifications in [RFC9041] regarding code points
   in the range 32768-65535.  Alternately, the unrecognized TLV
   may be stepped over, or an error message may be sent.

Perhaps:
   The Egress TLV can be silently dropped if not recognized; alternately,
   it may be stepped over, or an error message may be sent (per
   [RFC8029] and the clarifications in [RFC9041] regarding code points
   in the range 32768-65535).
-->

      <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 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 recognized, as per <xref target="RFC8029"/> target="RFC8029" format="default"/> and as per the clarifications from in
	<xref target="RFC9041"/>. target="RFC9041" format="default"/> regarding code points in the range 32768-65535. Alternately, the un-recognized unrecognized TLV may be stepped over over, or
	an error message may be sent. </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>

<!-- [rfced] The following sentences discuss how the address field is
derived. Is "address field" correct, or should these instances be updated
to simply "address"?

Original:
   The address field of the Egress TLV must be
   derived from the path egress/destination.
   ...
   Some specific cases on how to derive the
   address field in the Egress TLV are listed below:
   ...
   a.  If the last SID in the SR policy is an Adj-SID, the address
   field in the Egress TLV is derived from the node at the remote end
   of the corresponding adjacency.

   b.  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
   represented by the Binding SID.

Perhaps:
   The address in the Egress TLV
   must be derived from the path egress/destination.
   ...
   Some specific cases on how to derive the
   address in the Egress TLV are listed below:
   ...
   *  If the last SID in the SR Policy is an Adj-SID, the address
      in the Egress TLV is derived from the node at the remote end of
      the corresponding adjacency.

   *  If the last SID in the SR Policy is a Binding SID, the address
      in the Egress TLV is derived from the last node of the path
      represented by the Binding SID.
-->

      <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 target="tlv" format="default"/>)</dd>

<!-- [rfced] May we update this definition as follows to be more concise by
combining "based on IPV4/IPV6 address" and "Length will be 4 octets for
IPv4 and 16 octets for IPv6"?

Original:
   Length : variable based on IPV4/IPV6 address.  Length excludes the
   length of the Type and Length fields.  Length will be is 4 octets for
   IPv4 and 16 octets for IPv6.</t>

        <t>Address          : This IPv6.

Perhaps:
   Length:  Variable (4 octets for IPv4 addresses and 16 octets for IPv6
      addresses).  Length excludes the length of the Type and Length fields.
-->

  <dt>Length:</dt>
  <dd>Variable, based on IPv4/IPv6 address.  Length excludes the length of the
  Type and Length fields. Length is 4 octets for IPv4 and 16 octets for
  IPv6.</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>

<!-- [rfced] We updated the "i.e." phrase in this sentence as follows. Please
review and let us know any concerns.

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

Current:
   If the endpoint is not
   specified or is equal to zero (Section 8.8.1 of [RFC9256]), the
   sender MUST use the address corresponding to the last segment
   endpoint of the SR Policy path (i.e., the ultimate egress is used as the address
   in the Egress TLV).
-->

	  <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>
<!-- [rfced] We updated "will be 4 or 16" to "will be either 4 or 16
octets". Let us know any concerns.

Original:
   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
   address type.
   ...
   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 type of address X.

Current:
   X could be an IPv4 or IPv6 address, and the Length
   field in the Egress TLV will be either 4 or 16 octets, based on the
   address type of address X.
   ...
   X could be an IPv4 or IPv6
   address, and the Length field in the Egress TLV will be either 4 or 16
   octets, based on the address type of address X.
-->

          <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.
<!-- [rfced] How may we clarify "in the Target Stack TLV Node that receives an
MPLS echo request"?

Original:
  This document does not propose any change in the processing for Nil FEC as
  defined in [RFC8029] in the Target FEC Stack TLV Node that receives an MPLS
  echo request.

Perhaps:
  This document does not propose any change in the processing of the Nil FEC (as
  defined in [RFC8029]) in the node that receives an MPLS echo request with a
  Target FEC Stack TLV.
-->

	  This document does not propose any change in the processing
	  of the Nil FEC (as defined in
	  <xref target="RFC8029"/> target="RFC8029" format="default"/>) in the Target FEC stack Stack TLV Node that receives
	  an MPLS echo request. 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:
        </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")
	  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")

	  (<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> RSC").</li>
	  </ol>
	</li>
<!-- 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 in such cases, 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. In addition, 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 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") 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") 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 numbered="true" toc="default">
      <name>IANA Considerations</name>

<!-- [rfced] IANA Considerations

a) In Table 1, we updated "Egress TLV" to "Egress" as the majority of entries
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>
    <section anchor="tlv" title="New TLV">

	  <t> <xref target="IANA"/> is requested the "TLVs" registry do not include "TLV" as part of the name. If no
objections, we will ask IANA to update the entry in the registry accordingly
prior to publication.

Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#tlvs

b) Should "RSC" be updated to "<RSC>" in the Meaning column of Table 2? We ask
because angle brackets are used in a few other entries in the "Return Codes"
registry.

Also, note that we added "the" before "Egress TLV". We will ask IANA to update
the early
	  allocation entry in the "Return Codes" registry accordingly prior to publication.

Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#return-codes

Original:
   Replying router is an egress for the
   address in Egress TLV for the FEC at stack depth RSC

Current:
   Replying router is an egress for the
   address in the
	  "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
	  Parameters" Egress TLV for the FEC at stack depth RSC

Perhaps:
   Replying router is an egress for the
   address in the "TLVs" sub-registry Egress TLV for the FEC at stack depth <RSC>
-->

<!-- [rfced] Return Codes

a) FYI - We updated "Best-return-subcode" to reference "Best-rtn-subcode" per RFC 8029.

b) Is "stack-depth" correct here, or should it be updated to either
"Label-stack-depth" or "FEC-stack-depth"?

Original:
   When the egress node in the path does not support the extensions
   defined in this document when published egress validation will not be done and Best-
   return-code as an RFC.
	  </t>
	  <texttable 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>
    </section>
    <section anchor="ret_code" title="New Return code">

	  <t> <xref target="IANA"/> 3 ("Replying router is requested an egress for the FEC at stack-
   depth") and Best-return- subcode set to update stack-depth to will be set in
   the
	  early allocation of MPLS Echo Reply message.

c) In the "Return Codes" registry, "<RSC>" is included in the meaning for
Return Code Codes 8, 10, and 3. Should "<RSC>" be included in the text below? Or
are these okay as is?

Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml#return-codes

Original:
   ...set Best-return-code to 8 ("Label switched at stack-depth")

   ...set the Best-return-code to 10, "Mapping for this FEC is not the
   given label at stack-depth RSC"

   ...Best-return-code as 3 ("Replying router is an egress for the FEC at stack-
   depth")

Perhaps:
   ...set Best-return-code to 8 ("Label switched at stack-depth <RSC>")

   ...set the Best-return-code to 10, "Mapping for
	  "Replying this FEC is not the
   given label at stack-depth <RSC>"

   ...Best-return-code to 3 ("Replying router is an egress for the address FEC at stack-
   depth <RSC>")

d) "RSC" is not expanded/defined in Egress TLV" the document. May we add a sentence
before the list in Section 4.2 with the definition? RFC 8029 notes that "The
notation <RSC> refers to the
	  "Multi-Protocol Return Subcode."
-->

      <section anchor="tlv" numbered="true" toc="default">
        <name>New TLV</name>
        <t>IANA has added the following entry to the "TLVs" registry within
        the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in registry group <xref target="IANA-MPLS-LSP" format="default"/>:
        </t>
        <table anchor="iana_tlvs_tbl" 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</td>
              <td align="left">RFC 9655</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="ret_code" numbered="true" toc="default">
        <name>New Return Code</name>
        <t> IANA has added the following entry to the "Return Codes" sub-registry to reference this
   document when published as an RFC. registry
        within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" 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> RSC</td>
              <td align="left">RFC 9655</td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
    <section title='Security Considerations' anchor='sec-con'>
    <t>This anchor="sec-con" numbered="true" toc="default">
      <name>Security Considerations</name>
<!-- [rfced] We updated "TLVs" to "TLV" (singular) here as only one new TLV is
defined in this document (i.e., the Egress TLV). We also updated
"follows" to "conforms to". Let us know any concerns.

Original:
   This document defines additional MPLS LSP ping TLVs and follows the
   mechanisms defined in <xref target="RFC8029"/>. [RFC8029].

Perhaps:
   This document defines an additional TLV for MPLS LSP ping and conforms
   to the mechanisms defined in [RFC8029].
-->

<!-- [rfced] Does "they" here refer to "security considerations" or "this
document"? Also, would "introduce" rather than "impose" be a better word
choice?

Original:
   All the security considerations
   defined in <xref target="RFC8287"/> [RFC8287] will be applicable for this document and, in
   addition, they do not impose 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

Perhaps:
   All the references cited by security considerations
   defined in [RFC8287] apply to this section
   before publication.</t> document. This document does not
   introduce any additional security challenges to be considered.
-->

<t>This section records the status of known implementations of document defines an additional TLV for MPLS LSP ping and conforms to
	the
   protocol mechanisms 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 target="RFC8029" format="default"/>.
	All the IETF in its decision processes security considerations defined 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 <xref target="RFC8287" format="default"/>
	are applicable to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, this document, and must they do not
   be construed impose any
	additional security challenges to be, a catalog be considered.
      </t>
    </section>
  </middle>
  <back>
    <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>
        <name>Informative References</name>

        <reference 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>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>

<!-- [I-D.ietf-idr-sr-policy-safi] IESG state: I-D Exists as of available implementations or their
   features.  Readers are advised 9/5/24; Updated to note that other implementations may
   exist.</t>
   <section title='Juniper Networks'>
   <t>Organization: Juniper Networks</t>
   <t>Implementation: JUNOS</t>
   <t>Description: Implementation long way to add "Ed." for sending and validating Egress TLV</t>
   <t>Maturity Level: Released</t>
   <t>Coverage: Full</t>
   <t>Contact: shraddha@juniper.net</t>
   </section>
    </section> K. Talaulikar-->

<reference anchor="I-D.ietf-idr-sr-policy-safi" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-06">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author initials="S." surname="Previdi" 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="Ketan Talaulikar" role="editor">
<organization>Cisco Systems</organization>
</author>
<author initials="P." surname="Mattes" fullname="Paul Mattes">
<organization>Microsoft</organization>
</author>
<author initials="D." surname="Jain" fullname="Dhanendra Jain">
<organization>Google</organization>
</author>
<date month="July" day="26" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-sr-policy-safi-06"/>
</reference>

      </references>
    </references>
    <section title='Acknowledgements' anchor='ack'> anchor="ack" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t> The authors would like to thank Stewart Bryant, Greg Mirsky, Alexander Vainshtein,
	Sanga <contact fullname="Stewart
      Bryant"/>, <contact fullname="Greg Mirsky"/>, <contact
      fullname="Alexander Vainshtein"/>, <contact fullname="Sanga Mitra Rajgopal,
      Rajgopal"/>, and Adrian Farrel <contact fullname="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
  </back>

<!-- [rfced] Terminology

a) We note inconsistencies 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 terms listed below. We chose the specification.  These words are often
		   capitalized. This document defines these words as they should be
		   interpreted form on the
right. Please let us know any objections.

Target FEC stack TLV vs. target FEC Stack TLV vs. FEC stack TLV vs. Target FEC Stack TLV

SR policy vs. SR Policy
   Note: The capitalized form is more common 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 RFC Series (e.g., it is
   used in Multiprotocol Label Switching (MPLS) Label
		   Switched Paths (LSPs).  It defines a probe message called an "MPLS RFC 9256)

Echo Reply vs. echo request" reply
   Note: Per usage in RFCs 8029 and a response message called an "MPLS 8287.

Echo Request vs. echo reply" for
		   returning request
   Note: Per usage in RFCs 8029 and 8287.

head-end vs. headend

b) FYI - We updated "address field" to "Address field" (capitalized) per the result
name of the probe.  The MPLS echo request is intended
		   to contain sufficient information to check correct operation field in Figure 1. We also updated "endpoint field" to "Endpoint
field" (capitalized) per the name of the
		   data plane field in Figure 1 in
draft-ietf-idr-sr-policy-safi.

c) We see both "Nil FEC" and to verify the data plane against "Nil FEC sub-TLV" used in the control plane,
		   thereby localizing faults.</t>
           <t>This document obsoletes RFCs 4379, 6424, 6829, and 7537, document. Please
review and let us know if any 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 would be helpful.

d) Article usage (i.e, "the", "a", and "an") before "Nil FEC" and "General FEC"
is inconsistent. We added articles as there seems to be precedence 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
8029. Please review in the diff and confirm that may be these additions are
appropriate. Some examples:

Original:

With article ("the Nil FEC", "a Nil FEC"):
   The procedures outlined in
   [RFC8029] is primarily applicable when the Nil FEC is used as an
   intermediate FEC in protocol
		   specifications. the label stack.

   This document aims uses a Nil FEC to reduce the ambiguity by
		   clarifying that only UPPERCASE usage of the key words have represent 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 complete label stack in
   an 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 Echo Request message in ping 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 traceroute mode.

Without article ("Nil Fec"):
   [RFC8029] supports this mechanism with an SR header.
		   </t>
           <t>The segment assignment FECs like Nil FEC and forwarding semantic nature Generic
   FEC.

   On the other hand, Nil FEC consists 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
   label and defines extensions there is no other associated FEC information.  Nil FEC is
   used to
		   perform LSP ping and traceroute traverse the path without validation 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 cases where the FEC
   is not defined or routers are eliminated thanks not upgraded to
		   source routing. The headend node steers a flow into an SR Policy. The
		   header support the FECs.
-->

<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of a packet steered RFC 7322 ("RFC Style Guide"). Please review each
expansion 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 document carefully to ensure correctness.

SR Policy.
		   </t>
         </abstract>
       </front>
       <seriesInfo name="RFC" value="9256"/>
       <seriesInfo name="DOI" value="10.17487/RFC9256"/>
     </reference>

   </references>
   <references title='Informative References'>
     <reference anchor="IANA" 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"/>
         <date/>
         <abstract>
           <t></t>
         </abstract>
       </front>
	 </reference>
	 <reference anchor="I.D-ietf-idr-sr-policy-safi"
	 target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-safi-04">
       <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"/>
         <author initials="K." surname="Talaulikar " fullname="K. Talaulikar"/>
         <author initials="P." surname="Mattes" fullname="P. Mattes"/>
         <author initials="E." surname="Rosen" fullname="Eric C. Rosen"/>
         <author initials="D." surname="Jain" fullname="D. Jain"/>
         <author initials="S." surname="Lin" fullname="S. Lin"/>
         <date year="2024" month="April"/>
         <abstract>
           <t>A over IPv6 (SRv6)
Autonomous System (AS)
Segment Routing (SR) Policy is an ordered list of segments
		   (i.e., instructions) that represent a source-routed policy.
		   An SR Policy consists Identifier (SID)
-->

<!-- [rfced] Please review the "Inclusive Language" portion of one or more candidate paths, each consisting the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of one or this nature typically
result in more segment lists. A headend may be provisioned with candidate
		   paths precise language, which is helpful for an SR Policy via several different mechanisms, e.g., CLI, NETCONF,
		   PCEP, or BGP.This document specifies how BGP may readers.

Note that our script did not flag any words in particular, but this should
still be used to distribute SR
		   Policy candidate paths. It introduces a BGP SAFI to advertise a candidate
		   path of reviewed as 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>
       </front>
       <seriesInfo name="" value="draft-ietf-idr-sr-policy-safi-04"/>
       <seriesInfo name="" value="work in progress"/>
     </reference>
	 &RFC7942;
  </references>
</back> best practice.
-->
</rfc>