<?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"> [
  <!ENTITY RFC8287 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8287.xml"> nbsp    "&#160;">
  <!ENTITY RFC8029 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8029.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8403 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8403.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8402 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8604 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8604.xml">
<!ENTITY RFC7743 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7743.xml">
<!ENTITY RFC3107 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3107.xml">
<!ENTITY RFC8660 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8660.xml">
<!ENTITY RFC7110 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7110.xml">
<!ENTITY RFC9087 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9087.xml">
<!ENTITY RFC8277 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8277.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC9086 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9086.xml">
<!ENTITY RFC9256 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9256.xml">
<!ENTITY RFC9552 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9552.xml">
<!ENTITY RFC7942 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7942.xml">
<!ENTITY RFC9350 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9350.xml">
<!ENTITY RFC3032 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3032.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" category="std" docName="draft-ietf-mpls-spring-inter-domain-oam-20" ipr="trust200902"> number="9716" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <front>
    <title abbrev="Inter-as-OAM">Path abbrev="MPLS Ping and Traceroute in Inter-Domain SR Networks">Path Monitoring System/Head-End Based MPLS
    Ping and Traceroute in Inter-Domain Segment Routing Networks</title>

<!-- [rfced] Title

a.) As "Path Monitoring System/Head-end" is not mentioned in the
abstract, may we clarify the title as follows so that it aligns more
closely with the abstract? It will also help avoid the awkward
hyphenation of "Path Monitoring System/Head-end based".

Original:

Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter-domain Inter-
                    domain Segment Routing Networks</title> Networks

Perhaps:

Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain
Segment Routing Networks

b.) Note that we have updated the short title, which appears in the
running header in the PDF output. Please review.

Original:
Inter-as-OAM

Current:
MPLS Ping and Traceroute in Inter-Domain SR Networks

-->

    <seriesInfo name="RFC" value="9716"/>
    <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
      <organization>Juniper Networks Networks, Inc.</organization>
      <address>
        <postal>
          <street>Exora Business Park</street>
          <city>Bangalore</city>
          <region>KA</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>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>kapil.it@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Srivastava" fullname="Mukul Srivastava">
      <organization>Juniper Networks Networks, Inc.</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>msri@juniper.net</email>
      </address>
    </author>
    <author initials="S." surname="Ninan" fullname="Samson Ninan">
      <organization>Ciena</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>samson.cse@gmail.com</email>
      </address>
    </author>
    <author initials="N." surname="Kumar" fullname="Nagendra Kumar">
      <organization>Oracle</organization>
      <address>
      <postal>
        <street></street>
        <city></city>
        <region></region>
        <code></code>
        <country></country>
      </postal>
        <email>nagendrakumar.nainar@gmail.com</email>
      </address>
    </author>
    <date year="2024"/>
  <area>Routing</area>
  <workgroup>Routing area</workgroup> year="2025" month="January"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>
    <keyword>OAM</keyword>
    <keyword>EPE</keyword>
    <keyword>BGP-LS</keyword>
    <keyword>BGP</keyword>
    <keyword>SPRING</keyword>
    <keyword>SDN</keyword>

    <abstract>

      <t>The Segment Routing (SR) architecture leverages source routing and
      can be directly applied to the use of an MPLS data plane. An SR-MPLS A Segment
      Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains
      or multiple Autonomous Systems (ASes) under the control of the same
      organization.  It is useful to have the Label Switched Path (LSP) ping
      and traceroute procedures when an SR end-to-end path traverses multiple
      ASes or IGP domains.  This document outlines mechanisms to enable
      efficient LSP ping and traceroute procedures in inter-AS and
      inter-domain SR-MPLS networks networks. This is achieved through a
      straightforward extension to the Operations, Administration, and
      Maintenance (OAM) protocol, relying solely on data plane forwarding for
      handling echo replies on transit nodes.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor='intro'>

<t> Many anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>

      <t>Many network deployments have built their networks consisting of
      multiple ASes either for the ease of operations or as a result of
      network mergers and acquisitions. SR can be deployed in such scenarios
      to provide end-to-end paths, traversing multiple Autonomous systems (ASes). </t>
 <t>    <xref target='RFC8660'/> Systems
      (ASes).</t>

      <t><xref target="RFC8660" format="default"/> specifies SR with an MPLS
      data plane. <xref target='RFC8402'/> target="RFC8402" format="default"/> describes BGP Peering
Segments,
      peering segments, and <xref target='RFC9087'/> target="RFC9087" format="default"/>
      describes Centralized centralized BGP Egress Peer Engineering, which will help in
      steering packets from one AS to another.  By utilizing these SR
      capabilities, it is possible to create paths that span multiple ASes. </t>

<t>
      ASes.</t>

      <figure anchor="Topology_1" title="Inter-AS anchor="Topology_1">
        <name>Inter-AS Segment Routing Topology">

      <artwork> Topology</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                   +----------------+
                   | Controller/PMS |
                   +----------------+

|---AS1-----|                |------AS2------|                |----AS2----|             |----AS3---|

               ASBR2----ASBR3             ASBR5------ASBR7
              /             \             /            \
             /               \           /              \
PE1----P1---P2               P3---P4---PE4             P5---P6--PE5
             \               /           \               /
              \             /             \             /
               ASBR1----ASBR4             ASBR6------ASBR8

    Autonomous System: AS1,
]]></artwork>
      </figure>

<!-- [rfced] FYI - We have slightly adjusted Figure 1 to reduce the width of
the artwork in order to fit the 72-character limit. Please review. -->

      <dl>
	<dt>Autonomous System:</dt><dd>AS1, AS2, AS3
    Provider Edge: PE1, AS3</dd>
	<dt>Provider Edge:</dt><dd>PE1, PE4, PE5
    Provider: P1, PE5</dd>
	<dt>Provider:</dt><dd>P1, P2, P3, P4, P5, P6
    AS P6</dd>
	<dt>Autonomous System Boundary Router: ASBR1, Router:</dt><dd>ASBR1, ASBR2, ASBR3, ASBR4, ASBR5, ASBR6, ASBR7, ASBR8
       </artwork>
</figure>
</t> ASBR8</dd>
      </dl>

<!-- [rfced] Please review the following questions regarding the text below:

a.) To improve readability, may we remove the "/" characters and update
the text as follows?

b.) In addition, may we expand "SID" as follows (as Section 3.6 of RFC 7322
suggests that abbreviations should be expanded upon first use)?

Original:

   AS1, AS2, and AS3 are SR enabled and the egress links have PeerNode
   SID/PeerAdj SID/ PeerSet SID configured and advertised via [RFC9086].
   PeerNode SID/PeerAdj SID/PeerSet SID are referred to as Egress Peer
   Engineering SIDs (EPE- SIDs) in this document.

Perhaps:

   AS1, AS2, and AS3 are SR enabled, and the egress links have the following
   Segment Identifiers (SIDs) configured and advertised via [RFC9086]:
   PeerNode SID, PeerAdj SID, and PeerSet SID. The PeerNode SID, PeerAdj
   SID, and PeerSet SID are referred to as Egress Peer Engineering SIDs (EPE-
   SIDs) in this document.

-->

      <t>For example, <xref target="Topology_1"/> target="Topology_1" format="default"/> describes
      an inter-AS network scenario consisting of ASes AS1, AS2 AS2, and AS3.  AS1,
      AS2, and AS3 are SR enabled enabled, and the egress links have PeerNode
      SID/PeerAdj SID/ PeerSet SID configured and advertised via <xref target="RFC9086"/>.
      target="RFC9086" format="default"/>. PeerNode SID/PeerAdj SID/PeerSet
      SID are referred to as Egress Peer Engineering SIDs (EPE-SIDs) in this
      document.  The controller or the head-end can build an end-to-end Traffic-Engineered
      traffic-engineered path consisting of Node-SIDs, Adjacency-SIDs, and
      EPE-SIDs.  It is useful for operators to be able to perform LSP ping and
      traceroute procedures on these inter-AS SR-MPLS paths, to detect and
      diagnose failed deliveries deliveries, and to determine the actual path that
      traffic takes through the network. LSP ping/traceroute ping and traceroute procedures
      use IP connectivity for echo reply replies to reach the head-end. In inter-AS
      networks, IP connectivity may not be there from each router in the
      path. For example, in <xref target="Topology_1"/>, target="Topology_1" format="default"/>, P3
      and P4 may not have IP connectivity for PE1.</t>

      <t>It is not always possible to carry out LSP ping and traceroute
      functionality on these paths to verify basic connectivity and fault
      isolation using existing LSP ping and traceroute mechanisms(<xref target="RFC8287"/> mechanisms (see <xref
      target="RFC8287" format="default"/> and <xref target="RFC8029"/>). target="RFC8029"
      format="default"/>).  That is because there might not always be IP
      connectivity from a responding node back to the source address of the
      ping packet when the responding node is in a different AS from the
      source of the ping.

 </t> ping.</t>

      <t><xref target ="RFC8403"/> target="RFC8403" format="default"/> describes mechanisms to
      carry out MPLS ping/traceroute ping and traceroute from a Path Monitoring System (PMS).  It
      is possible to build GRE tunnels or static routes to each router in the
      network to get IP connectivity for the reverse path.  This mechanism is
      operationally very heavy and requires the PMS to be capable of building
      a huge number of GRE tunnels or installing the necessary static routes,
      which may not be feasible.</t>

<t>  <xref target="RFC7743"/>

<!--[rfced] To avoid the repetition of "based", may we update this sentence
as follows?

Original:

   [RFC7743] describes an Echo-relay based solution based on advertising
   a new Relay Node Address Stack TLV containing a stack of Echo-relay
   IP addresses.

Perhaps:

   [RFC7743] describes an Echo-relay-based solution that is predicated on
   advertising a new Relay Node Address Stack TLV containing a stack of
   Echo-relay IP addresses.

-->
      <t><xref target="RFC7743" format="default"/> describes an Echo-relay
      based solution that is based on advertising a new Relay Node Address Stack TLV
      containing a stack of Echo-relay IP addresses. These mechanisms can be
      applied to SR networks as well. The <xref target="RFC7743"/> mechanism from <xref target="RFC7743"
      format="default"/> requires the return ping packet to be
      processed on the slow path or as a bump-in-the-wire on every relay
      node. The motivation of the current document is to provide an alternate
      mechanism for ping/traceroute ping and traceroute in inter-domain SR networks. The
      definition of the term "domain" as applicable to this document is
      defined in <xref target="domain_definition"/>.

</t>
<t>
This target="domain_definition" format="default"/>.</t>

      <t>This document describes a new mechanism that is efficient and simple
      and can be easily deployed in SR-MPLS networks. This mechanism uses MPLS paths
      paths, and no changes are required in the forwarding path.  Any
      MPLS-capable node will be able to forward the echo-reply packet in the
      fast path. The current document describes a mechanism that uses the
      Reply Path TLV <xref target="RFC7110"/> target="RFC7110" format="default"/> to convey the
      reverse path. Three new sub-TLVs are defined for the Reply path Path TLV that
      facilitate encoding SR label stack. stacks.  The return path can either be
      derived by a smart application or a controller that has a full topology
      view or end-to-end view of a section of the topology.  This document
      also proposes mechanisms to derive the return path dynamically during
      traceroute procedures.
</t>

<t> This procedures.</t>

      <t>This document focuses on the inter-domain use case. The protocol
      extensions described may also indicate the return path for other use
      cases, which are outside the scope of this document and are not further
      detailed here. The SRv6 data plane is also not covered in this document</t>
      document.</t>

      <section anchor='domain_definition' title='Definition anchor="domain_definition" numbered="true" toc="default">
        <name>Definition of Domain'>
<t> In Domain</name>
        <t>In this document, the term "domain" refers to an IGP domain where
        every node is visible to every other node for the purpose of shortest
        path computation, implying an IGP area or level. An Autonomous System
        (AS) comprises one or more IGP domains. The procedures described
        herein are applicable to paths constructed across multiple domains,
        including both inter-area and inter-AS paths. These procedures and
        deployment scenarios are relevant for inter-AS paths where the
        participating ASes are under closely coordinating administrations or
        single ownership. This document pertains to SR-MPLS networks where all
        nodes within each domain are SR-capable. SR capable. It also applies to SR-MPLS
        networks where SR functions as an overlay with SR-incapable underlay
        nodes. In such networks, the traceroute procedure is executed only on
        the overlay SR nodes. </t> nodes.</t>
      </section>

      <section anchor='reqs' title='Requirements Language'> anchor="reqs" numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target ="RFC2119"/> target="RFC2119"/> <xref target ="RFC8174"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
    </section>

    <section anchor='inter_domain'
title='Inter-domain anchor="inter_domain" numbered="true" toc="default">
      <name>Inter-Domain Networks with Multiple IGPs'> IGPs</name>

<!-- [rfced] Please review our questions regarding the citations in the text below:

Original:

   The connectivity to the remote PEs can be achieved using BGP-Labeled
   Unicast (BGP-LU) [RFC8277] or by stacking the labels for each domain
   as described in [RFC8604].

a.) We were unable to find the term "BGP-Labeled Unicast (BGP-LU)" used in
RFC 8277 or other previous RFCs. How may we update this citation accordingly?

b.) We were unable to find content about "stacking labels" in RFC 8064. Please
review and let us know if any updates are needed.

-->

      <t>When the network consists of a large number of nodes, the nodes are
      segregated into multiple IGP domains as shown in <xref target="Topology_2"/>.
      target="Topology_2" format="default"/>.  The connectivity to the remote
      PEs can be achieved using BGP-Labeled Unicast (BGP-LU) <xref target="RFC8277"/>
      target="RFC8277" format="default"/> or by stacking the labels for each
      domain as described in <xref target="RFC8604"/>. target="RFC8604" format="default"/>.
      </t>

      <figure anchor="Topology_2"
title="Inter-domain anchor="Topology_2">
        <name>Inter-Domain Networks with Multiple IGPs">
      <artwork> IGPs</name>

        <artwork name="" type="" align="left" alt=""><![CDATA[
|-Domain 1|-------Domain 2-----|--Domain 3-|

PE1------ABR1--------P--------ABR2------PE4
 \        / \                  /\        /
  --------   -----------------   -------
   BGP-LU         BGP-LU          BGP-LU

       </artwork>
]]></artwork>
      </figure>

It

      <t>It is useful to support MPLS ping and traceroute mechanisms for these
      networks. The procedures described in this document for constructing the
      Reply Path TLV and its use in echo reply replies are equally applicable to
      networks consisting of multiple IGP domains that use BGP-LU or label stacking.

</t>
      stacking.</t>
    </section>

    <section anchor='Reply_path_TLV' title='Reply anchor="Reply_path_TLV" numbered="true" toc="default">
      <name>Reply Path TLV'>
<t>Reply TLV</name>
      <t>The Reply Path (RP) TLV is defined in <xref target="RFC7110"/>. target="RFC7110"
      format="default"/>.  SR networks statically assign the labels to
nodes nodes,
      and a PMS/head-end may know the entire Link State Database (LSDB) along
      with assigned SIDs. The reverse path can be built from the PMS/head-end
      by stacking segments for the reverse path. The Reply Path TLV as defined in
      <xref target="RFC7110"/> target="RFC7110" format="default"/> is used to carry the return
      path. Reply mode 5, Reply Mode 5 (Reply via Specified Path Path) is defined in section 4.1
 of <xref target="RFC7110"/>.
      target="RFC7110" sectionFormat="of" section="4.1"/>.  While using the
      procedures described in this document, the
reply mode Reply Mode is set to 5 (Reply
      via Specified Path), and the Reply Path TLV is included in the echo request
      message as described in <xref target="RFC7110"/>. target="RFC7110" format="default"/>. The
      Reply Path TLV is constructed as per Section 4.2 of <xref target="RFC7110"/>. target="RFC7110"
      sectionFormat="of" section="4.2"/>. This document defines three new
      sub-TLVs to encode the SR path.</t>

<t>
The

      <t>The type of segment that the head-end chooses to send in the Reply
      Path TLV is governed by local policy. Implementations may provide
      Command Line Interface (CLI) input parameters in the form of Labels/IPv4 addresses/IPv6 addresses labels, IPv4
      addresses, IPv6 addresses, or a combination of these these, which get encoded in
      the Reply Path TLV. Implementations may also provide mechanisms to
      acquire the LSDB of remote domains and compute the return path based on
      the acquired LSDB. For traceroute purposes, the return path will have to
      consider the reply being sent from every node along the path.  The
      return path changes when the traceroute progresses and crosses each
      domain. One of the ways this can be implemented on the head-end is to
      acquire the entire LSDB (of all domains) and build a return path for
      every node along the SR-MPLS path based on the knowledge of the LSDB.
      Another mechanism is to use a dynamically computed return path as
      described in <xref target="Dynamic_TLV_building"/>
</t>
<t>
Some target="Dynamic_TLV_building" format="default"/>.</t>

      <t>Some networks may consist of IPv4-only domains and IPv6-only domains.
      Handling end-to-end MPLS OAM for such networks is out of the scope of
      this document. It is recommended to use dual-stack in such cases and use
      end-to-end IPv6 addresses for MPLS ping and traceroute procedures.
</t> procedures.</t>
    </section>

    <section anchor='segment_sub_tlv' title='Segment Sub-TLV'>
<t> Section 4 of <xref target="RFC9256"/> anchor="segment_sub_tlv" numbered="true" toc="default">
      <name>Segment Sub-TLV</name>
      <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines
      various segment types.  The types of segments applicable to this
      document have been defined in this section for the use of MPLS OAM.  The
      intention was to keep the definitions as close to those in <xref target="RFC9256"/>
      target="RFC9256" format="default"/> as possible possible, with modifications only
      when needed.  One or more Segment sub-TLVs can be included in the Reply
      Path TLV.  The Segment sub-TLVs included in a Reply Path TLV MAY
      <bcp14>MAY</bcp14> be of different types.</t>

<t> The

<!-- [rfced] Please review our updates to the text below to ensure these
changes do not alter your intended meaning.

Original:

   This document defines the Type-A, Type-C, and Type-D Segment sub-TLVs
   usage and processing when it appears in TLV 21(Reply Path TLV).

Current:

   This document defines the usage and processing of the Type-A, Type-C, and
   Type-D Segment sub-TLVs when they appear in TLV 21 (Reply Path TLV).

-->

      <t>The below types of Segment sub-TLVs apply to the Reply Path TLV. The
      code points for the sub-TLVs are taken from the IANA registry common to
      TLVs 1, 16, and 21. This document defines the usage and processing of the Type-A, Type-C, and Type-D
      Segment sub-TLVs
usage and processing when it appears they appear in TLV 21(Reply 21 (Reply
      Path TLV).  If these sub-TLVs appear in TLVs 1 or 16, appropriate error
      codes MUST <bcp14>MUST</bcp14> be returned as defined in <xref target="RFC8029"/>.</t>

<t>Type-A: SID
      target="RFC8029" format="default"/>.</t>

    <dl>
      <dt>Type-A:</dt><dd>SID only, in the form of an MPLS Label</t>
<t>Type-C: IPv4 label</dd>
      <dt>Type-C:</dt><dd>IPv4 Node Address with an optional SID</t>
<t>Type-D: IPv6 SID</dd>
      <dt>Type-D:</dt><dd>IPv6 Node Address with an optional SID for SR MPLS</t> SR-MPLS</dd>
    </dl>

      <section anchor='type1' title='Type-A: anchor="type1" numbered="true" toc="default">
        <name>Type-A: SID only, Only, in the form Form of an MPLS Label'> Label</name>
        <t>The Type A Type-A Segment Sub-TLV sub-TLV encodes a single SID in the form of an
        MPLS label.  The format is as follows:</t>
        <figure anchor="type1_tlv" title="Type-A anchor="type1_tlv">
          <name>Type-A Segment Sub-TLV">
    <artwork> Sub-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                      |   Length                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |   RESERVED                                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   </artwork>
]]></artwork>
        </figure>
   <t>
   where:</t>

   <t>  Type: 2 octects.

        <t>Where:</t>
	<dl>
          <dt>Type:</dt><dd>2 octets. Carries value TBD1(to be assigned 46 (assigned by
          IANA from the registry "Sub-TLVs for TLV Types 1, 16, and 21").</t>

   <t> Length: 2 21" registry).</dd>

          <dt>Length:</dt><dd>2 octets. Carries value 8. The length value
          excludes the length of the Type and Length Fields.</t>

   <t> Flags: 1 fields.</dd>

          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target="flags"/>.</t>

   <t> RESERVED: 3
          target="flags" format="default"/>.</dd>

          <dt>RESERVED:</dt><dd>3 octets of reserved bits.
                MUST <bcp14>MUST</bcp14> be set to
          zero when sending;
                MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

   <t>  Label: 20 receipt.</dd>

          <dt>Label:</dt><dd>20 bits of label value.</t>

   <t>  TC: 3 value.</dd>

          <dt>TC:</dt><dd>3 bits of traffic class. Traffic Class (TC).  If the originator wants the receiver
          to choose the TC value, it MUST <bcp14>MUST</bcp14> set the Traffic Class (TC) TC field to zero.</t>

   <t>  S: 1 zero.</dd>

          <dt>S:</dt><dd>1 bit Reserved.The Reserved.  The S bit MUST <bcp14>MUST</bcp14> be zero upon transmission,
          transmission and MUST <bcp14>MUST</bcp14> be ignored upon reception. </t>

   <t>  TTL: 1 reception.</dd>

          <dt>TTL:</dt><dd>1 octet of TTL.  If the originator wants the
          receiver to choose the TTL value, it MUST <bcp14>MUST</bcp14> set the TTL
          field to 255.</t>
	<t> The label, 255.</dd>
        </dl>

	<t>The labels, TC, S, and TTL are collectively referred to as a SID.</t>

  <t> The
        <t>The following applies to the Type-A Segment sub-TLV:</t>

   <t>  The
        <t>The receiver MAY <bcp14>MAY</bcp14> override the originator's values
        for these fields.  This would be determined by local policy at the
        receiver.  One possible policy would be to override the fields only if
        the fields have the default values specified above.</t>
      </section>

      <section anchor='type3'
title='Type-C: anchor="type3" numbered="true" toc="default">
        <name>Type-C: IPv4 Node Address with an Optional SID for SR-MPLS'> SR-MPLS</name>
        <t>The Type-C Segment sub-TLV encodes an IPv4 node address, Node Address, SR
        Algorithm, and an optional SID in the form of an MPLS label.  The
        format is as follows:</t>
        <figure anchor="type3_tlv" title="Type-C anchor="type3_tlv">
          <name>Type-C Segment Sub-TLV">
    <artwork> Sub-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                      |   Length                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |  RESERVED (MBZ)             | SR Algorithm    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SID (optional, 4 octets)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    </artwork>
]]></artwork>
        </figure>
   <t>where:</t>

   <t>  Type: TBD2 (to be assigned

        <t>Where:</t>
	<dl>
          <dt>Type:</dt><dd>47 (assigned by IANA from the registry
	  "Sub-TLVs for TLV Types 1, 16, and 21").</t>

   <t> Length: 2 21" registry).</dd>

          <dt>Length:</dt><dd>2 octets. Caries Carries value 8 when no optional SID is included
          or value 12 when the optional SID is included.</t>

   <t>  Flags: 1 included.</dd>

          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target="flags"/>.</t>

   <t> RESERVED: 2 target="flags"
          format="default"/>.</dd>

          <dt>RESERVED:</dt><dd>2 octets of reserved bits. MUST <bcp14>MUST</bcp14> be set to
          zero when sending; <bcp14>MUST</bcp14> be ignored on receipt.</dd>

<!-- [rfced] May we add "(MBZ)" to the text following Figure 4 to reflect
similar text that appears following Figure 5?

Original (appears after Figure 4):

   When A-flag is unset, this
   field has no meaning and thus MUST be set to zero on transmission and
   ignored on receipt.</t>

   <t>  SR Algorithm: 1 octet specifying receipt.

Original (appears after Figure 5):

   When A-flag is unset, this
   field has no meaning and thus MUST be set to zero (MBZ) on transmission and
   ignored on receipt.

-->

          <dt>SR Algorithm:</dt><dd>1 octet. When the A-Flag (as defined in
          <xref target="flags" format="default"/>) is present, this specifies
          the SR Algorithm as described in
      section 3.1.1 in <xref target="RFC8402"/> target="RFC8402"
          sectionFormat="of" section="3.1.1"/> or the Flexible algorithm
	  as defined in <xref target="RFC9350"/>, when A-Flag Algorithm as
          defined in <xref target="flags"/> is present. target="RFC9350" format="default"/>. The SR
          Algorithm is used by the receiver to derive the Label. label. When the
          A-flag is unset, this field has no meaning and thus MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and ignored on receipt.</t>

   <t>  IPv4
          receipt.</dd>

          <dt>IPv4 Node Address: 4-octet Address:</dt><dd>4-octet IPv4 address representing a node.  The
          IPv4 Node Address MUST <bcp14>MUST</bcp14> be present.  It should be a
          stable address belonging to the node (eg:loopback address).</t>

   <t>  SID: optional: (e.g., loopback address).</dd>

          <dt>SID:</dt><dd>Optional 4-octet field containing label, the labels TC, S
          S, and TTL as defined in <xref target="type1"/>. target="type1" format="default"/>.
          When the SID field is present, it MUST <bcp14>MUST</bcp14> be used for
          constructing the Reply Path.</t> Path.</dd>
	</dl>
      </section>

      <section anchor='type4'
title='Type D: anchor="type4" numbered="true" toc="default">
        <name>Type-D: IPv6 Node Address with an Optional SID for SR MPLS'> SR-MPLS</name>

        <t>The Type-D Segment sub-TLV encodes an IPv6 node address, Node Address, SR Algorithm
        Algorithm, and an optional SID in the form of an MPLS label.  The
        format is as follows:</t>
        <figure anchor="type4_tlv" title="Type-D anchor="type4_tlv">
          <name>Type-D Segment Sub-TLV">
    <artwork> Sub-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                      |   Length                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |       RESERVED(MBZ)       RESERVED (MBZ)          | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Node Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SID (optional, 4 octets)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      </artwork>
]]></artwork>
        </figure>
   <t>where:</t>

   <t>  Type: TBD3 (to be assigned

        <t>Where:</t>
	<dl>
          <dt>Type:</dt><dd>48 (assigned by IANA from the registry "Sub-TLVs for
          TLV Types 1, 16, and 21").</t>

   <t>  Length: 2 Octets. Caries 21" registry).</dd>

          <dt>Length:</dt><dd>2 octets. Carries value 20 when no optional SID is included
          or value 24 when the optional SID is included.</t>

   <t>  Flags: 1 included.</dd>

          <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target="flags"/>.</t>

   <t> RESERVED: 2-octets
          target="flags" format="default"/>.</dd>

          <dt>RESERVED:</dt><dd>2 octets of reserved bits. MUST <bcp14>MUST</bcp14> be set to
          zero when sending;
                MUST <bcp14>MUST</bcp14> be ignored on receipt.</t>

   <t> receipt.</dd>

          <dt>SR Algorithm:</dt><dd>1 octet. When the A-Flag (as defined in
          <xref target="flags" format="default"/>) is present, this specifies
          the SR Algorithm: 1 octet specifying SR-Algorithm Algorithm as described in
      section 3.1.1 in <xref target="RFC8402"/> target="RFC8402"
          sectionFormat="of" section="3.1.1"/> or the Flexible algorithm
	  as defined in <xref target="RFC9350"/>, when A-Flag Algorithm as
          defined in <xref target="flags"/> is present.  SR-Algorithm target="RFC9350" format="default"/>. The SR Algorithm
          is used by the receiver to derive the label. When the A-flag is unset,
          this field has no meaning and thus MUST <bcp14>MUST</bcp14> be set to
          zero (MBZ) on transmission and ignored on receipt.</t>

   <t> IPv6 receipt.</dd>

          <dt>IPv6 Node Address: 16-octet Address:</dt><dd>16-octet IPv6 address of one interface of a
          node.  The IPv6 Node Address MUST <bcp14>MUST</bcp14> be present.  It
          should be a stable address belonging to the node (eg:loopback address).</t>

   <t> (e.g., loopback
          address).</dd>

<!-- [rfced] FYI - We have removed the second sentence from the definition
below as it repeats information from the first sentence. Please review and
let us know if further updates are needed.

Original:

   SID: optional: 4-octet field containing label, TC, S and TTL as
   defined in  <xref target="type1"/>. Section 4.1.  The SID is optional and specifies a 4-octet
   MPLS SID containing label, TC, S, and TTL as defined in  <xref target="type1"/>. Section 4.1.
   When the SID field is present, it MUST be used for constructing the
   Reply Path.</t> Path.

Current:

   SID: Optional 4-octet field containing the labels TC, S, and TTL as
   defined in Section 4.1.  When the SID field is present, it MUST be
   used for constructing the Reply Path.

-->

          <dt>SID:</dt><dd>Optional 4-octet field containing the labels TC,
          S, and TTL as defined in <xref target="type1" format="default"/>.
          When the SID field is present, it
          <bcp14>MUST</bcp14> be used for constructing the Reply Path.</dd>

	</dl>
      </section>

      <section anchor='flags' title='Segment Flags'> anchor="flags" numbered="true" toc="default">
        <name>Segment Flags</name>
        <t>The Segment Types described above contain the following flags in
        the
   "Flags" Flags field (codes to be assigned by IANA from the
   new registry
        "Segment ID Sub-TLV Flags"): Flags" registry): </t>
        <figure anchor="flags_field" title="Flags">
    <artwork> anchor="flags_field">
          <name>Flags</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A| | | | | | |
+-+-+-+-+-+-+-+-+
   </artwork>
]]></artwork>
        </figure>
   <t>where:</t>

      <t>A-Flag: This

        <t>Where:</t>
	<dl>
          <dt>A-Flag:</dt><dd>This flag indicates the presence of an SR Algorithm
          ID in the
      "SR-Algorithm" "SR Algorithm" field applicable to various segment Types.  </t>
          Types.</dd>
	</dl>

        <t>Unused bits in the Flag octet MUST <bcp14>MUST</bcp14> be set to zero upon
      transmission and MUST <bcp14>MUST</bcp14> be ignored upon receipt.</t>

        <t>The following applies to the Segment Flags:</t>

   <t>
        <t>The A-Flag applies to Segment Type-C and Type-D. If the A-Flag appears
        with the Type-A Segment Type, it MUST <bcp14>MUST</bcp14> be ignored.</t>
      </section>
    </section>

    <section anchor='procedure' title='Detailed Procedures '>
<t> This anchor="procedure" numbered="true" toc="default">
      <name>Detailed Procedures</name>
      <t>This section uses the term "initiator" for the node that initiates
      the MPLS ping or the MPLS traceroute procedure. The term "responder" is used
      for the node that receives the echo request and sends the echo reply.
      The term egress node "egress node" is used to identify the last node where the MPLS
      ping or traceroute is destined to. In an MPLS network network, any node can be initiator or responder
      an initiator, responder, or egress.</t>

      <section anchor='initiator_procedure' title='Sending anchor="initiator_procedure" numbered="true" toc="default">
        <name>Sending an Echo Request'> Request</name>
        <t>In the inter-AS scenario, the procedures outlined in this document
        are employed to specify the return path when IP connectivity to the
        initiator is unavailable. These procedures may also be utilized
        regardless of the availability of IP connectivity.  The LSP ping
        initiator MUST <bcp14>MUST</bcp14> set the Reply Mode of the echo request
        to 5 "Reply (Reply via Specified Path", Path), and a Reply Path TLV MUST
        <bcp14>MUST</bcp14> be carried in the echo request message
        correspondingly.  The Reply Path TLV MUST <bcp14>MUST</bcp14> contain the
        SR Path in the reverse direction encoded as an ordered list of
        segments. The first segment MUST <bcp14>MUST</bcp14> correspond to the top
        segment in the MPLS header that the responder MUST <bcp14>MUST</bcp14> use
        while sending the echo reply.
        </t>
      </section>

      <section anchor='responder_procedure' title='Receiving anchor="responder_procedure" numbered="true" toc="default">
        <name>Receiving an Echo Request'> Request</name>

        <t>As described in <xref target="RFC7110"/>, target="RFC7110" format="default"/>, when the
        Reply mode Mode is set to 5 (Reply via Specified Path), the echo request
        must contain the Reply
path Path TLV. Absence The absence of the Reply Path TLV is
        treated as a malformed echo request.  When an echo request is
        received, if the responder does not support the Reply Mode 5 defined
        in <xref target="RFC7110"/>, target="RFC7110" format="default"/>, an echo reply with the
        return code set to "Malformed echo request received" and the Subcode
        set to zero must be sent back to the initiator according to the rules
        of <xref target="RFC8029"/>. target="RFC8029" format="default"/>. If the echo request
        message contains a malformed Segment sub-TLV, such as an incorrect
        length field, an echo reply must be sent back to the initiator with
        the return code set to "Malformed echo request received" and the
        Subcode set to zero must be sent back to the initiator.</t> zero.</t>

        <t>When a Reply Path TLV is received, the responder that supports
        processing it, MUST it <bcp14>MUST</bcp14> use the segments in Reply Path TLV
        to build the echo reply. The responder MUST <bcp14>MUST</bcp14> follow the
        normal FEC Forwarding Equivalence Class (FEC) validation procedures as described in <xref target="RFC8029"/>
        target="RFC8029" format="default"/> and <xref target="RFC8287"/> target="RFC8287"
        format="default"/> and this document does not suggest any change to
        those procedures. When the echo reply has to be sent
out out, the Reply
        Path TLV MUST <bcp14>MUST</bcp14> be used to construct the MPLS packet to
        send out.
</t> out.</t>
      </section>

      <section anchor='sending_echo_reply' title='Sending anchor="sending_echo_reply" numbered="true" toc="default">
        <name>Sending an Echo Reply'> Reply</name>

<!-- [rfced] FYI - We have updated the text below for clarity; please review.

Original:

   If optional MPLS SID is present in the Type-C/Type-D segments SID
   MUST be used to encode the echo reply with MPLS labels.

Current:

   If an optional MPLS SID is present in the Type-C/Type-D segments, the SID
   MUST be used to encode the echo reply with MPLS labels.

-->

        <t>The echo reply message is sent as an MPLS packet with an MPLS label
        stack.  The echo reply message MUST <bcp14>MUST</bcp14> be constructed as
        described in the <xref target="RFC8029"/>. target="RFC8029" format="default"/>. An MPLS packet
        is constructed with an echo reply in the payload.  The top label MUST
        <bcp14>MUST</bcp14> be constructed from the first segment of the Reply
        Path TLV.  The remaining labels MUST <bcp14>MUST</bcp14> be constructed by
        following the order of the segments from the Reply Path TLV.  The MPLS
        header of the Echo Reply MUST echo reply <bcp14>MUST</bcp14> be constructed from the
        segments in the Reply Path TLV and MUST NOT <bcp14>MUST NOT</bcp14> add any
        other label.  The S bit is set for the bottom label as per the MPLS
        specifications <xref target="RFC3032"/> target="RFC3032" format="default"/>.  The
        responder MAY <bcp14>MAY</bcp14> check the reachability of the top label
        in its own Label Forwarding Information Base (LFIB) before sending the
        echo reply.  If the top label is unreachable, the responder SHOULD
        <bcp14>SHOULD</bcp14> send the appropriate return code and follow the
        procedures as per section 5.2 of <xref target="RFC7110"/>. target="RFC7110" sectionFormat="of"
        section="5.2"/>. The exception case is when the responder does not
        have IP reachability to the originator, in which case case, it may not be
        possible to send an Echo Reply echo reply at all. Even if sent (for
   example by (by following a
        default route present on the responder), responder, for example), the
   Echo Reply echo reply
        might not reach the originator. The node MAY <bcp14>MAY</bcp14> provide
        necessary log information in case of unreachability.  In certain
        scenarios, the head-end
MAY <bcp14>MAY</bcp14> choose to send
        Type-C/Type-D segments consisting of IPv4 addresses or IPv6 addresses, addresses
        when it is unable to derive the SID from available topology
        information. Optionally Optionally, the SID may also be associated with the
        Type-C/Type-D segment, if such information is available from the
        controller or via operator input. In such cases, the node sending the
        echo reply MUST <bcp14>MUST</bcp14> derive the MPLS labels based on the
        Node-SIDs associated with the IPv4/IPv6 addresses. If an optional MPLS
        SID is present in the Type-C/Type-D segments segments, the SID MUST <bcp14>MUST</bcp14>
        be used to encode the echo reply with MPLS labels. If the MPLS SID
        does not match with the IPv4 or IPv6 address field in the Type-C or
        Type-D SID, log information should be generated.</t>
<t>
The

        <t>The reply path return code is set as described in section 7.4 of <xref target="RFC7110"/>.
        target="RFC7110" sectionFormat="of" section="7.4"/>. According to section 5.3 of
        <xref target="RFC7110"/>, target="RFC7110" sectionFormat="of" section="5.3"/>, the Reply
        Path TLV is included in an echo reply indicating the specified return
        path that the echo reply message is required to follow.</t>
<t>
When

        <t>When the node is configured to dynamically create a return path for
        the next echo request, the procedures described in <xref target="Dynamic_TLV_building"/> MUST
        target="Dynamic_TLV_building" format="default"/> <bcp14>MUST</bcp14>
        be used.  The reply path return code MUST <bcp14>MUST</bcp14> be set to TBA1
        0x0006, and the same Reply Path TLV or a new Reply Path TLV MUST
        <bcp14>MUST</bcp14> be included in the echo reply.

</t> reply.</t>
      </section>

      <section anchor='Receiving_echo_reply' title='Receiving anchor="Receiving_echo_reply" numbered="true" toc="default">
        <name>Receiving an Echo Reply'> Reply</name>
        <t>The rules and processes defined in Section 4.6 of <xref target="RFC8029"/> target="RFC8029"
        sectionFormat="of" section="4.6"/> and Section 5.4 of <xref target="RFC7110"/> target="RFC7110"
        sectionFormat="of" section="5.4"/> apply here. In addition, if the
        Reply Path return code is "Use Reply Path TLV in the echo reply for
        building the next echo request" (defined (as defined in this document), the Reply
        Path TLV from the echo Reply MUST reply <bcp14>MUST</bcp14> be sent in the next
        echo request with the TTL incremented by 1. If the initiator node does not
        support the return code "Use Reply Path TLV in the echo reply for
        building the next echo request", log information should be generated
        indicating the return code code, and the operator may choose to specify the
        return path explicitly or use other mechanisms to verify the SR
        policy. If the return code is  TBA2, 0x0007 "Local policy does not allow
        dynamic Return
Path return path building", it indicates that the intermediate node
        does not support building the dynamic return path. Log information
        should be generated on the initiator receiving this return code code, and
        the operator may choose to specify the return path explicitly or use
        other mechanisms to verify the SR Policy.  If the TTL is already 255,
        the traceroute procedure
MUST <bcp14>MUST</bcp14> be ended with an
        appropriate log message.
</t> message.</t>
      </section>
      <section anchor='Dynamic_TLV_building'
title='Building anchor="Dynamic_TLV_building" numbered="true" toc="default">
        <name>Building a Reply Path TLV Dynamically'> Dynamically</name>
        <t>In some cases, the head-end may not have complete visibility of
Inter-AS/Inter-domain
        inter-AS/inter-domain topology.  In such cases, it can rely on routers
        in the path to build the reverse path for MPLS traceroute procedures.
        For this purpose, the Reply Path TLV in the echo reply corresponds to
        the return path to be used in building the next echo request. A new
        return code "Use Reply Path TLV in the echo reply for building the
        next echo request" is defined in this document.

    <artwork>
   Value         Meaning
   ------        ----------------------
   TBA1        Use
        </t>

<table anchor="tba1-value">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x0006</td>
      <td>Use Reply Path TLV in the echo reply for building the next echo request.

</artwork>

</t> request</td>
    </tr>
  </tbody>
</table>

        <section anchor='TLV_build_procedures' title='The Procedures anchor="TLV_build_procedures" numbered="true" toc="default">
          <name>Procedures to Build the Return Path'>
<t> To Path</name>
          <t>To dynamically build the return Path path for the traceroute
          procedures, the domain border nodes along the path being traced
          should support the procedures described in this section. Local
          policy on the domain border nodes should determine whether the
          domain border node participates in building the return path
          dynamically during traceroute.</t>
<t> The

          <t>The head-end/PMS node may include its node label while initiating
          the traceroute procedure.  When an Area Border Router (ABR) receives
          the echo request, if the local policy implies building a dynamic
          return path, the ABR should include its Node node label in the reply path Reply Path TLV
          and send it in the echo reply.  If there is a Reply Path TLV
          included in the received echo request message, the ABR's node label
          is added before the existing segments. The type of segment added is
          based on local policy. In cases when SRGB the Segment Routing Global
          Block (SRGB) is not uniform across the
network network, which can be
          inferred from the LSDB, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to add a
          Type-C or a Type-D segment,
but segment. However, implementations MAY <bcp14>MAY</bcp14>
          safely use other approaches if they see benefits in doing so. If the
          existing segment in the Reply Path TLV is a Type-C/Type-D segment,
          that segment should be converted to a Type-A segment based on the
          ABR's own SRGB. This is because downstream nodes in the path will
          not know what SRGB to use to translate the IP address to a label. As
          the ABR added its own Node node label, it is guaranteed that this ABR
          will be in the return path and will be forwarding the traffic based
          on the next label after its label.</t>

          <t>When an ASBR receives an echo request from another AS, and the
          ASBR is configured to build the return path dynamically, the ASBR
          should build a Reply Path TLV and include it in the echo reply.  The
          Reply Path TLV should consist of its node label and an EPE-SID to
          the AS from where the traceroute message was received.  A Reply path
          return code of TBA1 MUST 0x0006 <bcp14>MUST</bcp14> be set in the echo reply to
          indicate that the next echo request
 MUST <bcp14>MUST</bcp14> use the
          return Path path from the Reply Path TLV in the echo reply.  ASBR should
          locally decide the outgoing interface for the echo reply
          packet. Generally, remote ASBR will choose the interface on which
          the incoming OAM packet was received to send the echo reply out.  In
          case the ASBR identifies multiple paths to reach the initiator, it MUST
          <bcp14>MUST</bcp14> choose to send one such path in the Reply Path
          TLV.  The Reply Path TLV is built by adding two segment sub TLVs. Segment sub-TLVs. The
          top segment
 sub TLV Segment sub-TLV consists of the ASBR's Node SID Node-SID, and the second
          segment consists of the EPE-SID in the reverse direction to reach
          the AS from which the OAM packet was received. The type of segment
          chosen to build the Reply Path TLV is a local policy. It is recommended
          to use the Type-C/Type-D segment for the top segment when the SRGB
          is not guaranteed to be uniform in the domain.
</t>
<t> Irrespective domain.</t>

          <t>Irrespective of which type of segment is included in the Reply
          Path TLV, the responder to the echo requests MUST <bcp14>MUST</bcp14>
          always translate the Reply Path TLV to a label stack and build an
          MPLS header for the echo reply packet. This procedure can be applied
          to an end-to-end path consisting of multiple ASes.  Each ASBR that
          receives an echo request from another AS adds its Node-SID and
          EPE-SID on top of the existing segments in the Reply Path TLV.</t>
 <t> An

          <t>An ASBR that receives the echo request from a neighbor belonging
          to the same AS,
 MUST AS <bcp14>MUST</bcp14> look at the Reply Path TLV
          received in the echo request.  If the Reply Path TLV consists of a
          Type-C/Type-D segment, it MUST <bcp14>MUST</bcp14> convert the
          Type-C/Type-D segment to a Type-A segment by deriving a label from
          its own SRGB. The ASBR MUST <bcp14>MUST</bcp14> set the reply path return
          code to TBA1 0x0006 and send the newly constructed Reply Path TLV in the
          echo reply.</t>

          <t>Internal nodes or non-domain border nodes might not set the Reply
          Path TLV return code to TBA1 0x0006 in the echo reply message as there is
          no change in the return Path. path. In these cases, the head-end node/PMS
          that initiates the traceroute procedure MUST <bcp14>MUST</bcp14> continue
          to send the previously sent Reply Path TLV in the echo request
          message in every subsequent echo request. </t>

          <t>Note that an ASBR's local policy may prohibit it from
          participating in the dynamic traceroute procedures. If such an ASBR
          is encountered in the forward path, dynamic return path-building path building
          procedures will fail. In such cases, an ASBR that supports this
          document MUST <bcp14>MUST</bcp14> set the return code TBA2 to 0x0007 to indicate that
          local policies do not allow the dynamic return path building.</t>
<t>

    <artwork>
   Value         Meaning
   ------        ---------------------------------------------------
    TBA2        Local

<table anchor="tba2-value">
  <name></name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0x0007</td>
      <td>Local policy does not allow dynamic Return Path
                building.

</artwork>

</t> return path building</td>
    </tr>
  </tbody>
</table>
        </section>
      </section>
    </section>

    <section title='Security Considerations' anchor='sec-con'>
    <t> The anchor="sec-con" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The procedures described in this document enable LSP ping and
      traceroute procedures to be executed across multiple IGP domains or
      multiple ASes that belong to the same administration or closely
      cooperating administrations. It is assumed that sharing domain internal
      information across such domains does not pose a security risk.  However,
      the procedures described in this document may be used by an attacker to
      extract the domain's internal information. An operator MUST
      <bcp14>MUST</bcp14> deploy appropriate filter policies as described in
      <xref target="RFC8029"/> target="RFC8029" format="default"/> to restrict the LSP ping/traceroute ping and
      traceroute packets based on origin.  It is also RECOMMENDED
      <bcp14>RECOMMENDED</bcp14> that an operator deploy security mechanisms
      such as MACsec Media Access Control Security (MACsec) <xref target="IEEE-802.1AE"/> target="IEEE-802.1AE" format="default"/> on
      inter-domain links or security-vulnerable links to prevent spoofing attacks. </t>
    <t> All
      attacks.</t>

      <t>All the security considerations defined in <xref target="RFC8029"/> target="RFC8029"
      format="default"/> will be applicable for this document.  Appropriate
      filter policies SHOULD <bcp14>SHOULD</bcp14> be applied at the edges to prevent
      attackers from getting into the network. In the event of such a security
      breach, the network devices
    MUST <bcp14>MUST</bcp14> have mechanisms to
      prevent Denial-of-service denial-of-service attacks as described in <xref target="RFC8029"/>.</t> target="RFC8029"
      format="default"/>.</t>
    </section>

<!--[rfced] IANA queries

(Note: After this document completes AUTH48, we will ask IANA to update their
registry accordingly.)

a.) To reflect the definition of "Type-A", should a comma be added after
"SID only" in the Sub-TLV Name of Sub-Type 46?

Current:

   Type-A:  SID only, in the form of an MPLS label
   ...
   +==========+====================================+=============+
   | Sub-Type | Sub-TLV Name                       | Reference   |
   +==========+====================================+=============+
   | 46       | SID only in the form of MPLS label | Section 4.1 |
   |          |                                    | of RFC 9716 |

b.) As other values registered in the "Reply Path Return Codes" registry do
not include periods, we have removed the periods from the descriptions of
the following values registered by this document. Please let us know of
any objections.

Original:

   TBA1     Use Reply Path TLV from this echo
            reply for building next echo request.

   TBA2     Local policy does not allow dynamic
	    return Path building.

Current:

   0x0006   Use Reply Path TLV from this echo
            reply for building the next echo request

   0x0007   Local policy does not allow dynamic
            return path building

-->

    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>

      <section anchor="iana_segment_sub_tlv" title="Segment Sub-TLV"> numbered="true" toc="default">
        <name>Segment Sub-TLV</name>

        <t>IANA should assign has assigned three new sub-TLVs from the "sub-TLVs "Sub-TLVs for TLV
        Types 1, 16, and 21" sub-registry registry of the "Multiprotocol Label
        Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.

    <artwork>
   Sub-Type    Sub-TLV Name                  Reference
   --------    -----------------            ------------
 TBD1          SID
        registry group.</t>

<table anchor="segment-subTLVs">
  <name></name>
  <thead>
    <tr>
      <th>Sub-Type</th>
      <th>Sub-TLV Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>46</td>
      <td>SID only in the form of MPLS   Section 4.1
               label                          of this document
 TBD2          IPv4 label</td>
      <td><xref target="type1"/> of RFC 9716</td>
    </tr>
    <tr>
      <td>47</td>
      <td>IPv4 Node Address with         Section 4.2 an optional SID for SR-MPLS       of this document
 TBD3          IPv6 SR-MPLS</td>
      <td><xref target="type3"/> of RFC 9716</td>
    </tr>
    <tr>
      <td>48</td>
      <td>IPv6 Node Address with         Section 4.3 an optional SID for SR-MPLS       of this document
    </artwork>
  The SR-MPLS</td>
      <td><xref target="type4"/> of RFC 9716</td>
    </tr>
  </tbody>
</table>

        <t>The allocation of code points for the segment Segment sub-TLVs should be
        done from the Standards Action range (0-16383)
</t> (0-16383).</t>
      </section>

      <section anchor="segment_sub_tlv_flags" title="New numbered="true" toc="default">
        <name>New Registry for Segment ID Sub-TLV Flags"> Flags</name>
        <t>IANA should create has created a new "Segment ID Sub-TLV flags" Flags" registry (see
   Section <xref target="flags"/>) registry
        target="flags" format="default"/>) under the "Multiprotocol
        Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
        registry group. </t>
        <t>This registry tracks the assignment of 8 flags in the Segment ID
        sub-TLV flags field.  The flags are numbered from 0 (most (the most significant bit,
        bit and transmitted first) to 7.</t>
        <t>New entries are assigned by Standards Action. Initial entries in
        the registry are as follows:

    <artwork>

      Bit number  |  Name                      | Reference
      ------------+----------------------------+--------------
        1         |  A Flag                    | Section 4.4
                  |                            | follows:</t>

<table anchor="segmentIDsubTLVflags">
  <name></name>
  <thead>
    <tr>
      <th>Bit number</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>A Flag</td>
      <td><xref target="flags"/> of this document

    </artwork>

    </t> RFC 9716</td>
    </tr>
  </tbody>
</table>
      </section>

      <section anchor="iana_return_code" title="Reply numbered="true" toc="default">
        <name>Reply Path Return Codes Registry">
    <t> IANA should assign Registry</name>
        <t>IANA has assigned new return codes in the "Reply path return codes" Path Return
        Codes" registry under the "Multiprotocol Label Switching (MPLS) Label
        Switched Paths (LSPs) Ping Parameters" registry.

    <artwork>

    Value            Meaning                  Reference
   --------         -----------------        ------------
 TBA1                Use registry group.</t>
	<table anchor="path-return-codes-registry">
	  <name></name>
	  <thead>
	    <tr>
	      <th>Value</th>
	      <th>Meaning</th>
	      <th>Reference</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
	      <td>0x0006</td>
	      <td>Use Reply Path TLV       This document from this echo reply for building the next echo request.

 TBA2                Local request</td>
	      <td>RFC 9716</td>
	    </tr>
	    <tr>
	      <td>0x0007</td>
	      <td>Local policy does        This document not allow dynamic return Path building.

    </artwork>
   The path building</td>
	      <td>RFC 9716</td>
	    </tr>
	  </tbody>
	</table>

        <t>The return codes should be assigned from the Standards Action range (0x0000-0xFFFB).
    </t>
    </section> (0x0000-0xFFFB).</t>
      </section>
    <section title='Contributors'>
    <t>Carlos Pignataro</t>
    <t>NC State University</t>
    <t>cpignata@gmail.com</t>

    <t>   </t>
    <t>Zafar Ali</t>
    <t>Cisco Systems, Inc.</t>
    <t>zali@cisco.com</t>
    </section>
   <section title='Implementation Status'>
   <t>This section is to be removed before publishing

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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.2119.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.8029.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7110.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8403.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.8604.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7743.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8277.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9086.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9552.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9087.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9350.xml"/>

<!-- [rfced] FYI - We have updated the [IEEE-802.1AE] reference entry as an RFC.</t>

   <t>RFC-Editor:
follows. 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, review.

Original:

   [IEEE-802.1AE]
              IEEE, "IEEE Standard for Local and is based on a proposal described in <xref target="RFC7942"/>. metropolitan area
              networks-Media Access Control (MAC) Security", August
              2023.

Current:

   [IEEE-802.1AE]
              IEEE, "IEEE Standard for Local and metropolitan area
              networks-Media Access Control (MAC) Security", IEEE Std
              8021.AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
              2018, <https://ieeexplore.ieee.org/document/8585421>.
-->

        <reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date month="December" year="2018"/>
          </front>
          <seriesInfo name="IEEE Std" value="8021.AE-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
        </reference>

      </references>
    </references>

<!--[rfced] FYI - 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 previously titled "APPENDIX" 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 Return path TLV with Type-A segment subTLV</t>
   <t>Maturity Level: Prototype</t>
   <t>Coverage: Partial. Type-A SIDs in Return Path TLV</t>
   <t>Contact: shraddha@juniper.net</t>
   </section>
    </section>
  <section title='Acknowledgments'>
    <t> Thanks to Bruno Decraene for suggesting moved after the use of generic Segment sub-TLV.
        Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody,
        Dongjie, for careful review references and comments.
        Thanks to Mach Chen
        for suggesting the use of Reply Path TLV. Thanks to Gregory
        Mirsky for the detailed review which helped improve the
        readability of the document to a great extent.
        </t>
  </section> is now titled as "Examples".
Please review.
-->

    <section title='APPENDIX'> numbered="true" toc="default">
      <name>Examples</name>
       <t>This section elaborates examples of the inter-domain ping and Traceroute
       traceroute procedures described in this document.</t>

      <section anchor='Topology_description' title='Detailed Example '> anchor="Topology_description" numbered="true" toc="default">
        <name>Detailed Example</name>
        <t>The example topology given in <xref target="Topology_1"/> target="Topology_1"
        format="default"/> will be used in the below sections to explain LSP
        ping and traceroute procedures. The PMS/head-end has a complete view
        of the topology. PE1, P1, P2, ASBR1, and ASBR2 are in AS1. Similarly,
        ASBR3, ASBR4, P3, P4, and PE4 are in AS2.</t>

<!--[rfced] As the "/" character can mean "and", "or", or "and/or",
"the controller/PMS or head-end node" is unclear in the sentence
below. Please review and let us know how this sentence may be clarified.

Original:

   Topology of AS1 and AS2 are
   advertised via BGP-Link State (BGP-LS) to the controller/PMS or head-
   end node.

-->

        <t>AS1 and AS2 have SR enabled.  IGPs like OSPF/ISIS OSPF/IS-IS are used to flood
        SIDs in each AS. The ASBR1, ASBR2, ASBR3,and ASBR3, and ASBR4 advertise BGP
        EPE-SIDs for the inter-AS links.
Topology  The topologies of AS1 and AS2 are
        advertised via BGP-Link BGP - Link State (BGP-LS) to the controller/PMS or
        head-end node.  The EPE-SIDs are also advertised via BGP-LS as
        described in <xref target="RFC9086"/>. target="RFC9086" format="default"/>. The example
        uses EPE-SIDs for the inter-AS links links, but the same could be achieved
        using adjacency-SIDs Adjacency-SIDs advertised for a passive IGP link.</t>

        <t>The description in the this document uses below the notations below for
Segment Identifiers (SIDs).</t> SIDs.</t>

        <t>Node-SIDs: N-PE1, N-P1, N-ASBR1 N-ASBR1, etc.</t>
        <t>Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2 Adj-P1-P2, etc.</t>
        <t>EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 EPE-ASBR3-ASBR2, etc.</t>

        <section anchor='Mpls_ping_procedures' title='Procedures anchor="Mpls_ping_procedures" numbered="true" toc="default">
          <name>Procedures for Segment Routing LSP ping'> Ping</name>

          <t>Consider an SR-MPLS path from PE1 to PE4 consisting of a label
          stack [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from <xref target="Topology_1"/>.
          target="Topology_1" format="default"/>.  In order to perform MPLS
          ping procedures on this path, the remote end (PE4) needs IP
          connectivity to head-end PE1, PE1 for the echo reply to travel back to
          PE1.  In a deployment that uses a controller-computed inter-domain
          path, there may be no IP connectivity from PE4 to PE1 as they lie in
          different ASes.</t>

<t> PE1

          <t>PE1 sends an echo request message to the endpoint PE4 along the
          path that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4,
          N-PE4].  PE1 adds the return path from PE4 to PE1 in the echo
          request message in the Reply Path TLV. As an example, the Reply Path
          TLV for PE1 to PE4 for LSP ping is [N-ASBR4, EPE-ASBR4-ASBR1,
          N-PE1]. This example path provides the entire return path up to the
          head-end node PE1. The mechanism used to construct the return path
          is implementation-dependent.
</t> implementation dependent.</t>

          <t>An implementation may also build a return Path path consisting of
          labels to reach its own AS. Once the label stack is popped off, the
          echo reply message will be exposed.  The further packet forwarding
          will be based on IP lookup.  An example return Path path for this case
          could be [N-ASBR4, EPE-ASBR4-ASBR1].</t>

          <t>On receiving an MPLS echo request, PE4 first validates the FEC in
          the echo request.  PE4 then builds a label stack to send the
          response from PE4 to PE1 by copying the labels from the Reply Path
          TLV. PE4 builds the echo reply packet with the MPLS label stack constructed and
          constructed, imposes MPLS headers on top of the echo reply packet packet,
          and sends out the packet to PE1.  This segment List list stack can
          successfully steer the reply back to the head-end node (PE1).</t>

<t> Let

          <t>Let us consider a case when the P3 node does not have a route to
          reach N-PE4.  On P3 P3, a ping packet would be dropped dropped, and the head-end
          node (PE1) will not receive Echo Reply an echo reply indicating failure.</t>
        </section>

        <section anchor='Mpls_traceroute_procedures' title='Procedures anchor="Mpls_traceroute_procedures" numbered="true" toc="default">
          <name>Procedures for SR LSP traceroute'> Traceroute</name>

          <section anchor='traceroute_same_srgb'
title='Procedures anchor="traceroute_same_srgb" numbered="true" toc="default">
            <name>Procedures for SR LSP traceroute Traceroute with the Same SRGB on All Nodes'> Nodes</name>
            <t>The traceroute procedure involves visiting every node on the
            path and obtaining echo replies from every node. In this section,
            we describe the traceroute mechanisms when the head-end/PMS has
            complete visibility of the LSDB. The head-end/PMS computes the
            return path from each node in the entire SR-MPLS path that is
            being tracerouted. The return path computation is implementation-dependent. implementation
            dependent.  As the head-end/PMS completely controls the return
            path, it can use proprietary computations to build the return path. </t>
            path.</t>
            <t>One of the ways the return path can be built is to use the
            principle of building label stacks by adding each domain border
            node's Node-SID on the return path label stack as the traceroute
            progresses.  For inter-AS networks, in addition to the border
            node's Node-SID, the EPE-SID in the reverse direction also needs to be
            added to the label stack.
</t> stack.</t>

            <t>The Inter-domain/inter-AS inter-domain/inter-AS traceroute procedure uses the TTL
            expiry mechanism as specified in <xref target="RFC8029"/> target="RFC8029"
            format="default"/> and <xref target="RFC8287"/>. target="RFC8287" format="default"/>.
            Every echo request packet head-end/PMS will include the
            appropriate return path in the Reply Path TLV.  The node that
            receives the echo request will follow procedures described in
            Sections <xref target="initiator_procedure"/> target="initiator_procedure" format="counter"/> and <xref target="responder_procedure"/>
            target="responder_procedure" format="counter"/> to send out an
            echo reply.
</t> reply.</t>

            <t>For Example: </t>
<t> Let example:</t>
            <t>Let us consider a the topology from <xref target="Topology_1"/>. target="Topology_1"
            format="default"/>.  Let us consider an SR-MPLS path [N-P1,
            N-ASBR1, EPE-ASBR1-ASBR4, N-PE4].  The traceroute is being
            executed for this inter-AS path for destination PE4.  PE1 sends
            the first echo request with the TTL set to 1 and includes a Reply Path
            TLV consisting of a Type-A segment containing a label derived from
            its own SR Global Block (SRGB). SRGB.  Note that the type of segment
            used in constructing the return Path path is determined by local
            policy. If the entire network has the same SRGB configured, Type-A
            segments can be used. The TTL expires on P1 P1, and P1 sends an echo
            reply using the return path. Note that implementations may choose
            to exclude the Reply Path TLV until the traceroute reaches the
            first domain border as the return IP path to PE1 is expected to be
            available inside the first domain.</t>
<t> The

            <t>The TTL is set to 2 2, and the next the echo request is sent
            out. Until the traceroute procedure reaches the domain border node
            ASBR1, the same return path TLV consisting of a single Label label
            (PE1's node Label) label) is used.  When an echo request reaches the
            border node ASBR1, and an echo reply is received from ASBR1, the
            next echo request needs to include an additional label as ASBR1 is
            a border node. The head-end node has complete visibility of the
            network LSDB learned via BGP-LS (see <xref target="RFC9552"/> target="RFC9552"
            format="default"/> and <xref target="RFC9086"/> target="RFC9086" format="default"/>)
            and can derive the details of Autonomous
System Boundary Router (ASBR) ASBR nodes.  The Reply Path TLV is
            built based on the forward path.  As the forward path consists of
            EPE-ASBR1-ASBR4, an EPE-SID in the reverse direction is included
            in the Reply Path TLV. The return path now consists of two
labels labels:
            [EPE-ASBR4-ASBR1, N-PE1]. The echo reply from ASBR4 will use this
            return path to send the reply.</t>
<t>
The next echo request after

            <t>After visiting the border node ASBR4 ASBR4, the next echo request
            will update the return path with the Node-SID label of ASBR4. The
            return path beyond ASBR4 will be [N-ASBR4, EPE-ASBR4-ASBR1,
            N-PE1]. This same return path is used until the traceroute
            procedure reaches the next set of border nodes. When there are
            multiple ASes ASes, the traceroute procedure will continue by adding a
            set of Node-SIDs and EPE-SIDs as the border nodes are visited.
</t> visited.</t>

            <t>Note that the above return path-building path building procedure requires the
            LSDB of all the domains to be available at the head-end/PMS. </t>

<t> Let head-end/PMS.</t>

            <t>Let us consider a case when the P3 node does not have a route
            to reach N-PE4.  When the TTL of the packet is 5, the packet
            reaches P3 and the packet P3, its TTL becomes
	zero zero, and the packet it is sent to the control
            plane. The FEC validation Procedures procedures are executed executed, and the Echo Reply echo
            reply is sent using the labels in the Reply Path TLV TLV, which is [N-PE1,
            EPE-ASBR4-ASBR1, N-ASBR4].
Head-end  The head-end PE1 increases the TTL to 6
            and sends the next Echo Request. echo request. The packet is dropped at P3 as there
            is no route on P3 to forward to N-PE4. Traceroute The traceroute identifies that
            the path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at
            P3.</t>
          </section>

          <section anchor='traceroute_different_srgb'
title='Procedures anchor="traceroute_different_srgb" numbered="true" toc="default">
            <name>Procedures for SR LSP Traceroute with the Different SRGBs'>
<t> <xref target="traceroute_same_srgb"/> SRGBs</name>

            <t><xref target="traceroute_same_srgb" format="default"/> assumes
            the same SRGB is configured on all nodes along the path.  The SRGB
            may differ from one node to another node node, and the SR architecture
            <xref target="RFC8402"/> target="RFC8402" format="default"/> allows the nodes to use
            different SRGBs. In such scenarios, PE1 finds out the difference
            in the SRGB by looking into the LSDB and LSDB. Then, it sends the Type-C
            segment (or the Type-D segment, in the case of IPv6 networks) segment with
            the node address of PE1 and with an optional MPLS SID associated
            with the node address. The receiving node derives the label for
            the return path based on its own SRGB. When the traceroute
            procedure crosses the border ASBR1, head-end PE1 should send a
            Type-A segment for N-PE1 based on the label derived from ASBR1's
            SRGB. This is required because, because ASBR4, P3, P4, etc. may not have
            the topology information to derive SRGB for PE1. After the
            traceroute procedure reaches ASBR4 ASBR4, the return path will be [N-PE1
            (Type-A with the label based on ASBR1's SRGB), EPE-ASBR4-ASBR1,
            N-ASBR4 (Type-C)].</t>

<t> If

            <t>If the packet needs to follow a return path specific to an
            algorithm (as defined in <xref target="RFC9350"/>), target="RFC9350"
            format="default"/>), a Type-C Segment sub-TLV with a corresponding
            algorithm field set should be used. The A-flag should be set to
            indicate that the SID corresponding to the algorithm should be
            used.</t>

<t> To

            <t>To extend the example to 3 three or more ASes, let us consider a
            traceroute from PE1 to PE5 in <xref target="Topology_1"/>. target="Topology_1"
            format="default"/>. In this example, the PE1 to PE5 path has to
            cross 3 domains three domains: AS1, AS2, and AS3. Let us consider a path from PE1
            to PE5 that goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, PE5].
            When the traceroute procedure is visiting the nodes in AS1, the
            Reply Path TLV sent from the head-end consists of [N-PE1]. When
            the traceroute procedure reaches the ASBR4, the return Path path
            consists of [N-PE1, EPE-ASBR4-ASBR1]. While visiting nodes in AS2,
            the traceroute procedure consists of the Reply Path TLV [N-PE1,
            EPE-ASBR4-ASBR1, N-ASBR4].  Similarly, while visiting ASBR8, the
            EPE-SID from ASBR8 to ASBR6 is added to the Reply Path TLV.  While
            visiting nodes in AS3, the Node-SID of ASBR8 would also be added added,
            which makes the return Path path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4,
            EPE-ASBR8-ASBR6, N-ASBR8]</t> N-ASBR8].</t>

            <t>Let us consider another example from the topology in <xref target="Topology_2"/>.
            target="Topology_2" format="default"/>.  This topology consists of
            multi-domain IGP with a common border node between the domains.
            This could be achieved with multi-area or multi-level IGP or with
            multiple instances of IGP deployed on the same node.  The return
            path computation for this topology is similar to the multi-AS computation
            computation, except that the return path consists of a single
            border node label. </t> label.</t>
          </section>
        </section>

        <section anchor='TLV_build_procedure_example'
title='Procedures anchor="TLV_build_procedure_example" numbered="true" toc="default">
          <name>Procedures for building Building Reply Path TLV dynamically'> Dynamically</name>
          <t>Let us consider a the topology from <xref target="Topology_1"/>. target="Topology_1"
          format="default"/>.  Let us consider an SR policy path built from
          PE1 to PE4 with the following label stack, stack: N-P1, N-ASBR1, EPE-ASBR1-ASBR4,
          N-PE4. PE1 begins traceroute procedures with the TTL set to 1 and includes
          [N-PE1] in the Reply Path TLV. The traceroute packet TTL expires on P1
          P1, and P1 processes the traceroute as per the procedures described
          in <xref target="RFC8029"/> target="RFC8029" format="default"/> and <xref target="RFC8287"/>.
          target="RFC8287" format="default"/>.  P1 sends an echo reply with
          the same Reply Path TLV with the reply path return code set to 6.
          The return code of the echo reply itself is set to the return code
          as per <xref target="RFC8029"/> target="RFC8029" format="default"/> and <xref target="RFC8287"/>.
          target="RFC8287" format="default"/>.  This traceroute doesn't need
          any changes to the Reply Path TLV
till until it leaves AS1. The same Reply
          Path TLV that is received may be included in the echo reply by P1
          and P2 P2, or no Reply Path TLV is included so that the head-end continues to
          use the same return path in the echo request that it used to send
          the previous echo request.</t>

<!-- [rfced] Please review our changes to the text below to ensure these
updates do not alter your intended meaning.

Original:

   The same Reply Path TLV is sufficient for any router in AS2 to send the
   reply.  Because the first label(N-ASBR4) can direct echo reply to ASBR4 and
   the second one (EPE-ASBR4-ASBR1) to direct echo reply to AS1.
   ...
   The example described in the above paragraphs can be extended to
   multiple ASes by following the same procedure of each ASBR adding
   Node-SID and EPE-SID on receiving echo requests from neighboring AS.

Current:

   The same Reply Path TLV is sufficient for any router in AS2 to send the
   reply.  This is because the first label (N-ASBR4) can direct the echo reply
   to ASBR4 and the second one (EPE-ASBR4-ASBR1) can direct the echo reply to
   AS1.
   ...
   The example described in the above paragraphs can be extended to multiple
   ASes.  This is done by following the same procedure for each ASBR, i.e.,
   adding Node-SIDs and EPE-SIDs on receiving echo requests from neighboring
   ASes.

-->

<t>When ASBR1 receives the echo request, in the case it receives the
          Type-C/Type-D segment in the Reply Path TLV in the echo request, it
          converts that Type-C/Type-D segment to Type-A based on its own SRGB.
          When ASBR4 receives the echo request, it should form this Reply Path
          TLV using its Node-SID (N-ASBR4) and EPE-SID (EPE-ASRB4-ASBR1)
          labels and set the reply path return code to TBA1.
 Then 0x0006.  Then, PE1 should
          use this Reply Path TLV in subsequent echo requests.  In this
          example, when the subsequent echo request reaches P3, it should use
          this Reply Path TLV for sending the echo reply. The same Reply Path
          TLV is sufficient for any router in AS2 to send the reply.
 Because  This is
          because the first label(N-ASBR4) label (N-ASBR4) can direct the echo reply to ASBR4
          and the second one (EPE-ASBR4-ASBR1) to can direct the echo reply to
          AS1. Once the echo reply reaches AS1, normal IP forwarding or the
          N-PE1 helps it to reach PE1.</t>
 <t> The

	  <t>The example described in the above paragraphs can be extended to
	  multiple
 ASes ASes.  This is done by following the same procedure of for
	  each ASBR ASBR, i.e., adding Node-SID Node-SIDs and EPE-SID EPE-SIDs on receiving echo
	  requests from neighboring AS.</t> ASes.</t>

<!--[rfced] We are having some difficulty understanding how "while sending
the echo reply" fits into this sentence. May we clarify this sentence as
follows?

Original:

   ABR1 receives the echo request
   and while sending the echo reply adds its node Label to the Reply
   Path TLV and sets the Reply path return code to TBA1.

Perhaps:

   ABR1 receives the echo request, adds its node Label to the Reply
   Path TLV (while sending the echo reply), and sets the Reply path return
   code to 0x0006.

-->

          <t>Let us consider a the topology from <xref target="Topology_2"/>. target="Topology_2"
          format="default"/>.  It consists of multiple IGP domains with
          multiple areas/levels or separate IGP instances.  There is a single
          border node that separates the two domains. In this case, PE1 sends
          a traceroute packet with the TTL set to 1 and includes N-PE1 in the
          Reply Path TLV.  ABR1 receives the echo request and while sending
          the echo reply adds its node Label label to the Reply Path TLV and sets
          the Reply path return code to TBA1. 0x0006.  The Reply Path TLV in the echo
          reply from ABR1 consists of [N-ABR1, N-PE1]. The next echo request
          with a TTL of 2 reaches the P node. It is an internal node node, so
          it does not change the return Path. path.  The echo request with a TTL of 3
          reaches ABR2 ABR2, and it adds its node label so the Reply Path TLV sent
          in the echo reply will be [N-ABR2, N-ABR1, N-PE1]. The echo request with a
          TTL of 4 reaches PE4 PE4, and it sends an echo reply return code as Egress. an
          egress. PE4 does not include any Reply Path TLV TLVs in the echo
          reply. The above example assumes a uniform SRGB throughout the
          domain. In the case of different SRGBs, the top segment will be a
          Type-C/Type-D segment and all other segments will be Type-A. Each
          border node converts the Type-C/Type-D segment to Type-A before
          adding its segment to the Reply Path TLV.</t>
        </section>
      </section>
    </section>

</middle>

<back>
  <references title='Normative References'>
    &RFC8174;
    &RFC2119;
    &RFC8287;
    &RFC8029;
    &RFC7110;

  </references>
  <references title='Informative References'>
    &RFC3032;
    &RFC8403;
    &RFC8402;
    &RFC8604;
    &RFC7743;
    &RFC8277;
    &RFC8660;
    &RFC9086;
    &RFC9256;
    &RFC9552;
	&RFC7942;
	&RFC9087;
	&RFC9350;
	<reference anchor='IEEE-802.1AE'>
        <front>
        <title> IEEE Standard

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to <contact fullname="Bruno Decraene"/> for Local suggesting the use
      of the generic Segment sub-TLV.  Thanks to <contact fullname="Adrian
      Farrel"/>, <contact fullname="Huub van Helvoort"/>, <contact
      fullname="Dhruv Dhody"/>, and metropolitan area networks–Media <contact fullname="Dongjie"/> for their careful
      reviews and comments.  Thanks to <contact fullname="Mach Chen"/> for
      suggesting the use of the Reply Path TLV. Thanks to <contact
      fullname="Gregory Mirsky"/> for the detailed review, which helped
      improve the readability of the document to a great extent.
      </t>
    </section>

    <section numbered="false" toc="default">
      <name>Contributors</name>

      <contact fullname="Carlos Pignataro">
	<organization>NC State University</organization>
	<address>
	  <email>cpignata@gmail.com</email>
	</address>
      </contact>

      <contact fullname="Zafar Ali">
	<organization>Cisco Systems, Inc.</organization>
	<address>
	  <email>zali@cisco.com</email>
	</address>
      </contact>
    </section>
  </back>

<!-- [rfced] Terminology:

a.) The following terms appear to be capitalized inconsistently throughout this
document. Please review these different uses and let us know how to update for consistency.

A-Flag vs. A-flag vs. A Flag
Reply Path return code vs. reply path return code vs. Reply path return code
Segment Types vs. segment Types vs. segment types
SR path vs. SR Path
SR Policy vs. SR policy

b.) We note inconsistencies in the terms listed below. We updated to the form
on the right. Please let us know any concerns.

Inter-AS vs. inter-AS
Inter-domain vs. inter-domain
Sub-TLV vs. sub-TLV
Label vs. label (when used generally)
Segment Sub-TLV vs. segment sub-TLV vs. Segment sub-TLV
MPLS Label vs. MPLS label
IPv4 node address vs. IPv4 Node Address
IPv6 node address vs. IPv6 Node Address

c.) We have updated the following terms to reflect how they appear in
previously published RFCs. Please review and let us know of any objections.

BGP Peering Segments > BGP peering segments (per RFC 8402)
Centralized BGP Egress Peer Engineering > centralized BGP Egress Peer
  Engineering (per RFC 9087)

d.) FYI - We have removed quotation marks from around the following field
names to reflect how field names are more commonly used throughout the text.

Original:

   The Segment Types described above contain the following flags in the
   "Flags" field (codes to be assigned by IANA from the new registry
   "Segment Sub-TLV Flags"):
   ...
   A-Flag: This flag indicates the presence of SR Algorithm ID in the
   "SR-Algorithm" field applicable to various segment Types.

Current:

   The Segment Types described above contain the following flags in the
   Flags field (codes assigned by IANA from the "Segment ID Sub-TLV
   Flags" registry):
   ...
   A-Flag:  This flag indicates the presence of an SR Algorithm ID in
      the SR Algorithm field applicable to various segment Types.

e.) Per RFC 8029, may we capitalize all instances of "return code"?

-->

<!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
in the document carefully to ensure correctness.

Forwarding Equivalence Class (FEC)
Media Access Control (MAC) Security</title>
        <author>
        <organization>
        IEEE
        </organization>
        </author>
        <date month="Aug" year="2023"/>
        </front>
      </reference>

  </references>
</back> Security (MACsec)

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which[IEEE-802.1AE] is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>