rfc9716xml2.original.xml   rfc9716.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [<!ENTITY RFC2119 PUBLIC "" "http://xml.resou <!DOCTYPE rfc [
rce.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC8287 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY zwsp "&#8203;">
RFC.8287.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC8029 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!ENTITY wj "&#8288;">
RFC.8029.xml">
<!ENTITY RFC8403 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8403.xml">
<!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">
]> ]>
<?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 category="std" docName="draft-ietf-mpls-spring-inter-domain-oam-20" ipr="tr
ust200902">
<front>
<title abbrev="Inter-as-OAM">Path Monitoring System/Head-end based MPLS
Ping and Traceroute in Inter-domain
Segment Routing Networks</title>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<organization>Juniper Networks Inc.</organization> tf-mpls-spring-inter-domain-oam-20" number="9716" consensus="true" ipr="trust200
<address> 902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="tru
<postal> e" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<street>Exora Business Park</street> <front>
<city>Bangalore</city> <title abbrev="MPLS Ping and Traceroute in Inter-Domain SR Networks">Mechani
<region>KA</region> sms for MPLS Ping and Traceroute Procedures in Inter-Domain
<code>560103</code> Segment Routing Networks</title>
<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 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>
<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 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 in inter-AS and inter-domain
SR-MPLS networks 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> <seriesInfo name="RFC" value="9716"/>
<section title="Introduction" anchor='intro'> <author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper 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>
<email>kapil.it@gmail.com</email>
</address>
</author>
<author initials="M." surname="Srivastava" fullname="Mukul Srivastava">
<organization>Juniper Networks, Inc.</organization>
<address>
<email>msri@juniper.net</email>
</address>
</author>
<author initials="S." surname="Ninan" fullname="Samson Ninan">
<organization>Ciena</organization>
<address>
<email>samson.cse@gmail.com</email>
</address>
</author>
<author initials="N." surname="Kumar" fullname="Nagendra Kumar">
<organization>Oracle</organization>
<address>
<email>nagendrakumar.nainar@gmail.com</email>
</address>
</author>
<date 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>
<t> Many network deployments have built their networks consisting of multiple <abstract>
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'/> specifies SR with
an MPLS data plane. <xref target='RFC8402'/> describes BGP Peering
Segments, and
<xref target='RFC9087'/> describes 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> <t>The Segment Routing (SR) architecture leverages source routing and
can be directly applied to the use of an MPLS data plane. 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. 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>
<figure anchor="Topology_1" title="Inter-AS Segment Routing Topology"> <middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<artwork> <t>Many network deployments have built their networks consisting of
+----------------+ multiple ASes either for the ease of operations or as a result of
| Controller/PMS | network mergers and acquisitions. SR can be deployed in such scenarios
+----------------+ to provide end-to-end paths, traversing multiple Autonomous Systems
(ASes).</t>
|---AS1-----| |------AS2------| |----AS3---| <t><xref target="RFC8660" format="default"/> specifies SR with an MPLS
data plane. <xref target="RFC8402" format="default"/> describes BGP
peering segments, and <xref target="RFC9087" format="default"/>
describes 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>
ASBR2----ASBR3 ASBR5------ASBR7 <figure anchor="Topology_1">
/ \ / \ <name>Inter-AS Segment Routing Topology</name>
/ \ / \ <artwork name="" type="" align="left" alt=""><![CDATA[
PE1----P1---P2 P3---P4---PE4 P5---P6--PE5 +----------------+
\ / \ / | Controller/PMS |
\ / \ / +----------------+
ASBR1----ASBR4 ASBR6------ASBR8
Autonomous System: AS1, AS2, AS3 |---AS1-----| |----AS2----| |----AS3---|
Provider Edge: PE1, PE4, PE5
Provider: P1, P2, P3, P4, P5, P6
AS Boundary Router: ASBR1, ASBR2, ASBR3, ASBR4,
ASBR5, ASBR6, ASBR7, ASBR8
</artwork>
</figure>
</t>
<t>For example, <xref target="Topology_1"/>
describes an inter-AS network scenario consisting of ASes AS1, AS2 and AS3.
AS1, AS2, and AS3 are SR enabled and the egress links
have PeerNode SID/PeerAdj SID/ PeerSet SID configured
and advertised via <xref target="RFC9086"/>. PeerNode SID/PeerAdj SID/PeerSet SI
D 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 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 and to determine the actual path that traffic takes
through the network. LSP ping/traceroute procedures use IP
connectivity for echo reply 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"/>, 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 ASBR2----ASBR3 ASBR5------ASBR7
on these paths to verify basic connectivity and fault isolation using existing / \ / \
LSP ping and traceroute mechanisms(<xref target="RFC8287"/> and / \ / \
<xref target="RFC8029"/>). PE1----P1---P2 P3---P4---PE4 P5---P6--PE5
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. ASBR1----ASBR4 ASBR6------ASBR8
]]></artwork>
</figure>
</t> <dl>
<dt>Autonomous System:</dt><dd>AS1, AS2, AS3</dd>
<dt>Provider Edge:</dt><dd>PE1, PE4, PE5</dd>
<dt>Provider:</dt><dd>P1, P2, P3, P4, P5, P6</dd>
<dt>Autonomous System Boundary Router:</dt><dd>ASBR1, ASBR2, ASBR3, ASBR4
, ASBR5, ASBR6, ASBR7, ASBR8</dd>
</dl>
<t><xref target ="RFC8403"/> describes mechanisms to carry out <t>For example, <xref target="Topology_1" format="default"/> describes
MPLS ping/traceroute from a Path Monitoring System (PMS). an inter-AS network scenario consisting of ASes AS1, AS2, and AS3. AS1,
It is possible to build GRE tunnels or static routes to each router AS2, and AS3 are SR enabled, and the egress links have the following
in the network Segment Identifiers (SIDs) configured and advertised via <xref
to get IP connectivity for the reverse path. target="RFC9086" format="default"/>: PeerNode
This mechanism is operationally SID, PeerAdj SID, and PeerSet SID. The PeerNode SID, PeerAdj SID, and Peer
very heavy and requires the PMS to be capable of building a huge Set
number of GRE tunnels or installing the necessary static routes, SID are referred to as Egress Peer Engineering SIDs (EPE-SIDs) in this
which may not be feasible.</t> document. The controller or the head-end can build an end-to-end
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, and to determine the actual path that
traffic takes through the network. LSP ping and traceroute procedures
use IP connectivity for echo 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" format="default"/>, P3
and P4 may not have IP connectivity for PE1.</t>
<t> <xref target="RFC7743"/> describes an Echo-relay based solution <t>It is not always possible to carry out LSP ping and traceroute
based on advertising a new Relay Node Address Stack TLV containing functionality on these paths to verify basic connectivity and fault
a stack of Echo-relay IP addresses. These mechanisms can be applied to isolation using existing LSP ping and traceroute mechanisms (see <xref
SR networks as well. The <xref target="RFC7743"/> target="RFC8287" format="default"/> and <xref target="RFC8029"
mechanism requires the return ping packet to be processed on the slow format="default"/>). That is because there might not always be IP
path or as a bump-in-the-wire connectivity from a responding node back to the source address of the
on every relay node. The motivation of the current document ping packet when the responding node is in a different AS from the
is to provide an alternate mechanism for ping/traceroute in source of the ping.</t>
inter-domain SR networks. The definition of the term "domain"
as applicable to this document is defined in <xref target="domain_definition"/>.
</t> <t><xref target="RFC8403" format="default"/> describes mechanisms to
<t> carry out MPLS ping and traceroute from a Path Monitoring System (PMS). I
This document describes a new mechanism that is efficient and simple t
and can be easily deployed in SR-MPLS networks. This mechanism uses is possible to build GRE tunnels or static routes to each router in the
MPLS paths and network to get IP connectivity for the reverse path. This mechanism is
no changes are required in the forwarding path. operationally very heavy and requires the PMS to be capable of building
Any MPLS-capable node will be able to forward a huge number of GRE tunnels or installing the necessary static routes,
the echo-reply packet in the fast path. which may not be feasible.</t>
The current document describes a mechanism that uses the Reply Path TLV <t><xref target="RFC7743" format="default"/> describes an Echo-relay-based
<xref target="RFC7110"/> solution that is predicated on advertising a new Relay Node Address Stack TLV
to convey the reverse path. Three new sub-TLVs are defined for the Reply path containing a stack of Echo-relay IP addresses. These mechanisms can be
TLV that facilitate encoding SR label stack. applied to SR networks as well. The mechanism from <xref target="RFC7743"
The return path can either be derived by a smart application format="default"/> requires the return ping packet to be
or a controller that has a full processed on the slow path or as a bump-in-the-wire on every relay
topology view or node. The motivation of the current document is to provide an alternate
end-to-end view of a section of the topology. mechanism for ping and traceroute in inter-domain SR networks. The
This document also proposes mechanisms to derive definition of the term "domain" as applicable to this document is
the return path dynamically during traceroute procedures. defined in <xref target="domain_definition" format="default"/>.</t>
</t>
<t> This document focuses on the inter-domain use case. The protocol <t>This document describes a new mechanism that is efficient and simple
extensions described may also indicate the return path for other and can be easily deployed in SR-MPLS networks. This mechanism uses MPLS
use cases, which are outside the scope of this document and are paths, and no changes are required in the forwarding path. Any
not further detailed here. The SRv6 data plane is also not MPLS-capable node will be able to forward the echo-reply packet in the
covered in this document</t> fast path. The current document describes a mechanism that uses the
Reply Path TLV <xref target="RFC7110" format="default"/> to convey the
reverse path. Three new sub-TLVs are defined for the Reply Path TLV that
facilitate encoding SR label 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>
<section anchor='domain_definition' title='Definition of Domain'> <t>This document focuses on the inter-domain use case. The protocol
<t> In this document, the term "domain" refers to an extensions described may also indicate the return path for other use
IGP domain where every node is visible to every cases, which are outside the scope of this document and are not further
other node for the purpose of shortest path computation, detailed here. The SRv6 data plane is also not covered in this
implying an IGP area or level. An Autonomous System (AS) document.</t>
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. 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>
</section>
<section anchor='reqs' title='Requirements Language'>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <section anchor="domain_definition" numbered="true" toc="default">
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <name>Definition of Domain</name>
"MAY", and "OPTIONAL" in this document are to be interpreted as <t>In this document, the term "domain" refers to an IGP domain where
described in BCP 14 <xref target ="RFC2119"/> every node is visible to every other node for the purpose of shortest
<xref target ="RFC8174"/> when, and only when, they path computation, implying an IGP area or level. An Autonomous System
appear in all capitals, as shown here.</t> (AS) comprises one or more IGP domains. The procedures described
</section> 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. 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>
</section>
</section> <section anchor="reqs" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section>
</section>
<section anchor='inter_domain' <section anchor="inter_domain" numbered="true" toc="default">
title='Inter-domain Networks with Multiple IGPs'> <name>Inter-Domain Networks with Multiple IGPs</name>
<t>When the network consists of a large number of nodes, <t>When the network consists of a large number of nodes, the nodes are
the nodes are segregated into multiple IGP domains as shown in <xref
segregated into multiple IGP domains as shown in <xref target="Topology_2"/>. target="Topology_2" format="default"/>. The connectivity to the remote
The connectivity to the remote PEs can be achieved using PEs can be achieved by BGP advertisements with an MPLS label bound to
BGP-Labeled Unicast (BGP-LU) the prefix as described in <xref target="RFC8277" format="default"/> or
<xref target="RFC8277"/> or by stacking the labels by building paths using a list of segments as described in <xref
for each domain as described in <xref target="RFC8604"/>. target="RFC8604" format="default"/>.
</t>
<figure anchor="Topology_2" <figure anchor="Topology_2">
title="Inter-domain Networks with Multiple IGPs"> <name>Inter-Domain Networks with Multiple IGPs</name>
<artwork>
|-Domain 1|-------Domain 2-----|--Domain 3-| <artwork name="" type="" align="left" alt=""><![CDATA[
|-Domain 1|-------Domain 2-----|--Domain 3-|
PE1------ABR1--------P--------ABR2------PE4 PE1------ABR1--------P--------ABR2------PE4
\ / \ /\ / \ / \ /\ /
-------- ----------------- ------- -------- ----------------- -------
BGP-LU BGP-LU BGP-LU BGP-LU BGP-LU BGP-LU
]]></artwork>
</figure>
</artwork> <t>It is useful to support MPLS ping and traceroute mechanisms for these
</figure> networks. The procedures described in this document for constructing the
Reply Path TLV and its use in echo replies are equally applicable to
networks consisting of multiple IGP domains that use BGP-Labeled Unicast (
BGP-LU) or label
stacking.</t>
</section>
It is useful to support MPLS ping and traceroute <section anchor="Reply_path_TLV" numbered="true" toc="default">
mechanisms for these networks. The procedures described in <name>Reply Path TLV</name>
this document for constructing Reply Path TLV and its use <t>The Reply Path (RP) TLV is defined in <xref target="RFC7110"
in echo reply are equally applicable to networks consisting format="default"/>. SR networks statically assign the labels to nodes,
of multiple IGP domains that use BGP-LU or label stacking. 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 i
n
<xref target="RFC7110" format="default"/> is used to carry the return
path. Reply Mode 5 (Reply via Specified Path) is defined in <xref
target="RFC7110" sectionFormat="of" section="4.1"/>. While using the
procedures described in this document, the Reply Mode is set to 5 (Reply
via Specified Path), and the Reply Path TLV is included in the echo reques
t
message as described in <xref target="RFC7110" format="default"/>. The
Reply Path TLV is constructed as per <xref target="RFC7110"
sectionFormat="of" section="4.2"/>. This document defines three new
sub-TLVs to encode the SR Path.</t>
</t> <t>The type of segment that the head-end chooses to send in the Reply
</section> Path TLV is governed by local policy. Implementations may provide
<section anchor='Reply_path_TLV' title='Reply Path TLV'> Command Line Interface (CLI) input parameters in the form of labels, IPv4
<t>Reply Path (RP) TLV is defined in <xref target="RFC7110"/>. addresses, IPv6 addresses, or a combination of these, which get encoded in
SR networks statically assign the labels to the Reply Path TLV. Implementations may also provide mechanisms to
nodes and a PMS/head-end acquire the LSDB of remote domains and compute the return path based on
may know the entire Link State Database (LSDB) the acquired LSDB. For traceroute purposes, the return path will have to
along with assigned SIDs. The reverse path can be built consider the reply being sent from every node along the path. The
from the PMS/head-end by stacking return path changes when the traceroute progresses and crosses each
segments for the reverse path. Reply Path TLV as defined in domain. One of the ways this can be implemented on the head-end is to
<xref target="RFC7110"/> is used acquire the entire LSDB (of all domains) and build a return path for
to carry the return path. 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" format="default"/>.</t>
Reply mode 5, Reply via Specified Path is defined in section 4.1 <t>Some networks may consist of IPv4-only domains and IPv6-only domains.
of <xref target="RFC7110"/>. Handling end-to-end MPLS OAM for such networks is out of the scope of
While using the procedures described in this document, the this document. It is recommended to use dual-stack in such cases and use
reply mode is set to 5 (Reply via Specified Path), and Reply Path end-to-end IPv6 addresses for MPLS ping and traceroute procedures.</t>
TLV is included in the echo request message as described in </section>
<xref target="RFC7110"/>. The Reply Path TLV is constructed
as per Section 4.2 of
<xref target="RFC7110"/>. This document defines three new sub-TLVs
to encode the SR path.</t>
<t> <section anchor="segment_sub_tlv" numbered="true" toc="default">
The type of segment that the head-end <name>Segment Sub-TLV</name>
chooses to send in the Reply Path TLV is governed <t><xref target="RFC9256" sectionFormat="of" section="4"/> defines
by local policy. Implementations may provide Command Line Interface (CLI) various Segment Types. The types of segments applicable to this
input parameters in the form of Labels/IPv4 addresses/IPv6 addresses document have been defined in this section for the use of MPLS OAM. The
or a combination of these which get encoded intention was to keep the definitions as close to those in <xref
in the Reply Path TLV. Implementations may also provide mechanisms to target="RFC9256" format="default"/> as possible, with modifications only
acquire the LSDB of remote domains and compute the return path based when needed. One or more Segment sub-TLVs can be included in the Reply
on the acquired LSDB. For traceroute purposes, the return path will Path TLV. The Segment sub-TLVs included in a Reply Path TLV
have to consider the reply being sent from every node along the path. <bcp14>MAY</bcp14> be of different types.</t>
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 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>
</section>
<section anchor='segment_sub_tlv' title='Segment Sub-TLV'>
<t> Section 4 of <xref target="RFC9256"/> 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"/> as 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 be of different types.</t>
<t> The below types of Segment sub-TLVs apply to the <t>The below types of Segment sub-TLVs apply to the Reply Path TLV. The
Reply Path TLV. The code points for the sub-TLVs are taken from the IANA registr code points for the sub-TLVs are taken from the IANA registry common to
y TLVs 1, 16, and 21. This document defines the usage and processing of the
common to TLVs 1, 16, and 21. This document defines the Type-A, Type-C, and Type-D
Type-A, Type-C, and Type-D Segment sub-TLVs Segment sub-TLVs when they appear in TLV 21 (Reply
usage and processing when it appears in TLV 21(Reply Path TLV). Path TLV). If these sub-TLVs appear in TLVs 1 or 16, appropriate error
If these sub-TLVs appear in codes <bcp14>MUST</bcp14> be returned as defined in <xref
TLVs 1 or 16, appropriate error codes MUST be returned target="RFC8029" format="default"/>.</t>
as defined in <xref target="RFC8029"/>.</t>
<t>Type-A: SID only, in the form of MPLS Label</t> <dl>
<t>Type-C: IPv4 Node Address with optional SID</t> <dt>Type-A:</dt><dd>SID only, in the form of an MPLS label</dd>
<t>Type-D: IPv6 Node Address with optional SID for SR MPLS</t> <dt>Type-C:</dt><dd>IPv4 Node Address with an optional SID</dd>
<dt>Type-D:</dt><dd>IPv6 Node Address with an optional SID for SR-MPLS</dd
>
</dl>
<section anchor='type1' title='Type-A: SID only, in the form of MPLS Label'> <section anchor="type1" numbered="true" toc="default">
<name>Type-A: SID Only, in the Form of an MPLS Label</name>
<t>The Type-A Segment sub-TLV encodes a single SID in the form of an
MPLS label. The format is as follows:</t>
<figure anchor="type1_tlv">
<name>Type-A Segment 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>
</figure>
<t>The Type A Segment Sub-TLV encodes a single SID in the form of an <t>Where:</t>
MPLS label. The format is as follows:</t> <dl>
<dt>Type:</dt><dd>2 octets. Carries value 46 (assigned by
IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).</dd>
<figure anchor="type1_tlv" title="Type-A Segment Sub-TLV"> <dt>Length:</dt><dd>2 octets. Carries value 8. The length value
<artwork> excludes the length of the Type and Length fields.</dd>
0 1 2 3 <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
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 target="flags" format="default"/>.</dd>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> <dt>RESERVED:</dt><dd>3 octets of reserved bits. <bcp14>MUST</bcp14> b
</figure> e set to
<t> zero when sending; <bcp14>MUST</bcp14> be ignored on receipt.</dd>
where:</t>
<t> Type: 2 octects. Carries value TBD1(to be assigned by IANA from the regi <dt>Label:</dt><dd>20 bits of label value.</dd>
stry
"Sub-TLVs for TLV Types 1, 16, and 21").</t>
<t> Length: 2 octets. Carries value 8. The length value <dt>TC:</dt><dd>3 bits of Traffic Class (TC). If the originator wants
excludes the length of the Type and the receiver
Length Fields.</t> to choose the TC value, it <bcp14>MUST</bcp14> set the TC field to zer
o.</dd>
<t> Flags: 1 octet of flags as defined in <dt>S:</dt><dd>1 bit Reserved. The S bit <bcp14>MUST</bcp14> be zero
<xref target="flags"/>.</t> upon
transmission and <bcp14>MUST</bcp14> be ignored upon reception.</dd>
<t> RESERVED: 3 octets of reserved bits. <dt>TTL:</dt><dd>1 octet of TTL. If the originator wants the
MUST be set to zero when sending; receiver to choose the TTL value, it <bcp14>MUST</bcp14> set the TTL
MUST be ignored on receipt.</t> field to 255.</dd>
</dl>
<t> Label: 20 bits of label value.</t> <t>The labels, TC, S, and TTL are collectively referred to as a SID.</t>
<t>The following applies to the Type-A Segment sub-TLV:</t>
<t>The receiver <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>
<t> TC: 3 bits of traffic class. <section anchor="type3" numbered="true" toc="default">
If the originator wants the receiver to choose the TC value, <name>Type-C: IPv4 Node Address with an Optional SID for SR-MPLS</name>
it MUST set the Traffic Class (TC) field to zero.</t> <t>The Type-C Segment sub-TLV encodes an IPv4 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">
<name>Type-C Segment 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>
</figure>
<t> S: 1 bit Reserved.The S bit MUST be zero upon transmission, <t>Where:</t>
and MUST be ignored upon reception. </t> <dl>
<dt>Type:</dt><dd>47 (assigned by IANA from the
"Sub-TLVs for TLV Types 1, 16, and 21" registry).</dd>
<t> TTL: 1 octet of TTL. <dt>Length:</dt><dd>2 octets. Carries value 8 when no optional SID is
If the originator wants the receiver to choose the TTL value, it MU included
ST or value 12 when the optional SID is included.</dd>
set the TTL field to 255.</t>
<t> The label, TC, S, and TTL collectively referred to as SID.</t>
<t> The following applies to the Type-A Segment sub-TLV:</t> <dt>Flags:</dt><dd>1 octet of flags as defined in <xref target="flags"
format="default"/>.</dd>
<t> The receiver MAY override the originator's values for these <dt>RESERVED:</dt><dd>2 octets of reserved bits. <bcp14>MUST</bcp14> b
fields. This would be determined by local policy at the receiver. e set to
One possible policy would be to override the fields only if the zero when sending; <bcp14>MUST</bcp14> be ignored on receipt.</dd>
fields have the default values specified above.</t>
</section> <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 <xref target="RFC8402"
sectionFormat="of" section="3.1.1"/> or the Flexible Algorithm as
defined in <xref 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
<bcp14>MUST</bcp14> be set to zero (MBZ) on transmission and ignored o
n
receipt.</dd>
<section anchor='type3' <dt>IPv4 Node Address:</dt><dd>4-octet IPv4 address representing a nod
title='Type-C: IPv4 Node Address with Optional SID for SR-MPLS'> e. The
IPv4 Node Address <bcp14>MUST</bcp14> be present. It should be a
stable address belonging to the node (e.g., loopback address).</dd>
<t>The Type-C Segment sub-TLV encodes an IPv4 node address, SR Algorithm, <dt>SID:</dt><dd>Optional 4-octet field containing the labels TC,
and an optional SID in the form of an MPLS label. The format is as S, and TTL as defined in <xref target="type1" format="default"/>.
follows:</t> When the SID field is present, it <bcp14>MUST</bcp14> be used for
<figure anchor="type3_tlv" title="Type-C Segment Sub-TLV"> constructing the Reply Path.</dd>
<artwork> </dl>
0 1 2 3 </section>
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> <section anchor="type4" numbered="true" toc="default">
</figure> <name>Type-D: IPv6 Node Address with an Optional SID for SR-MPLS</name>
<t>where:</t>
<t> Type: TBD2 (to be assigned by IANA from the registry <t>The Type-D Segment sub-TLV encodes an IPv6 Node Address, SR
"Sub-TLVs for TLV Types 1, 16, and 21").</t> Algorithm, and an optional SID in the form of an MPLS label. The
format is as follows:</t>
<figure anchor="type4_tlv">
<name>Type-D Segment 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t> Length: 2 octets. Caries value 8 when no optional SID <t>Where:</t>
is included or value 12 when optional SID is included.</t> <dl>
<dt>Type:</dt><dd>48 (assigned by IANA from the "Sub-TLVs for
TLV Types 1, 16, and 21" registry).</dd>
<t> Flags: 1 octet of flags as defined in <xref target="flags"/>.</t> <dt>Length:</dt><dd>2 octets. Carries value 20 when no optional SID is
included
or value 24 when the optional SID is included.</dd>
<t> RESERVED: 2 octets of reserved bits. MUST be set to zero when sending; <dt>Flags:</dt><dd>1 octet of flags as defined in <xref
MUST be ignored on receipt.</t> target="flags" format="default"/>.</dd>
<t> SR Algorithm: 1 octet specifying SR Algorithm as described in <dt>RESERVED:</dt><dd>2 octets of reserved bits. <bcp14>MUST</bcp14> b
section 3.1.1 in <xref target="RFC8402"/> or Flexible algorithm e set to
as defined in <xref target="RFC9350"/>, when A-Flag as zero when sending; <bcp14>MUST</bcp14> be ignored on receipt.</dd>
defined in <xref target="flags"/> is present. SR Algorithm is used
by the receiver to derive the Label. 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> IPv4 Node Address: 4-octet IPv4 address representing a node. <dt>SR Algorithm:</dt><dd>1 octet. When the A-Flag (as defined in
The IPv4 Node Address MUST be present. <xref target="flags" format="default"/>) is present, this specifies
It should be a stable address the SR Algorithm as described in <xref target="RFC8402"
belonging sectionFormat="of" section="3.1.1"/> or the Flexible Algorithm as
to the node (eg:loopback defined in <xref target="RFC9350" format="default"/>. The SR Algorithm
address).</t> is used by the receiver to derive the label. When the A-Flag is unset,
this field has no meaning and thus <bcp14>MUST</bcp14> be set to
zero (MBZ) on transmission and ignored on receipt.</dd>
<t> SID: optional: 4-octet field containing label, TC, S and <dt>IPv6 Node Address:</dt><dd>16-octet IPv6 address of one interface
TTL as defined in <xref target="type1"/>. of a
When the SID field is present, it MUST be used for node. The IPv6 Node Address <bcp14>MUST</bcp14> be present. It
constructing the Reply Path.</t> should be a stable address belonging to the node (e.g., loopback
address).</dd>
</section> <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>
<section anchor='type4' </dl>
title='Type D: IPv6 Node Address with Optional SID for SR MPLS'> </section>
<t>The Type-D Segment sub-TLV encodes an IPv6 node address, SR Algorithm <section anchor="flags" numbered="true" toc="default">
and an optional SID in the form of an MPLS label. The format is as <name>Segment Flags</name>
follows:</t> <t>The Segment Types described above contain the following flags in
<figure anchor="type4_tlv" title="Type-D Segment Sub-TLV"> the Flags field (codes assigned by IANA from the
<artwork> "Segment ID Sub-TLV Flags" registry): </t>
0 1 2 3 <figure anchor="flags_field">
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 <name>Flags</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="left" alt=""><![CDATA[
| Type | Length | 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Flags | RESERVED(MBZ) | SR Algorithm | | |A| | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // ]]></artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </figure>
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>where:</t>
<t> Type: TBD3 (to be assigned by IANA from the registry <t>Where:</t>
"Sub-TLVs for TLV Types 1, 16, and 21").</t> <dl>
<dt>A-Flag:</dt><dd>This flag indicates the presence of an SR Algorith
m
ID in the SR Algorithm field applicable to various Segment
Types.</dd>
</dl>
<t> Length: 2 Octets. Caries value 20 when no optional SID is <t>Unused bits in the Flag octet <bcp14>MUST</bcp14> be set to zero upon
included or value 24 when optional SID is included.</t> transmission and <bcp14>MUST</bcp14> be ignored upon receipt.</t>
<t> Flags: 1 octet of flags as defined in <xref target="flags"/>.</t> <t>The following applies to the Segment Flags:</t>
<t>The A-Flag applies to Segment Type-C and Type-D. If the A-Flag appear
s
with the Type-A Segment Type, it <bcp14>MUST</bcp14> be ignored.</t>
</section>
</section>
<t> RESERVED: 2-octets of reserved bits. MUST be set to zero when sending; <section anchor="procedure" numbered="true" toc="default">
MUST be ignored on receipt.</t> <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 us
ed
for the node that receives the echo request and sends the echo reply.
The term "egress node" is used to identify the last node where the MPLS
ping or traceroute is destined to. In an MPLS network, any node can be
an initiator, responder, or egress.</t>
<t> SR Algorithm: 1 octet specifying SR-Algorithm as described in <section anchor="initiator_procedure" numbered="true" toc="default">
section 3.1.1 in <xref target="RFC8402"/> or Flexible algorithm <name>Sending an Echo Request</name>
as defined in <xref target="RFC9350"/>, when A-Flag as <t>In the inter-AS scenario, the procedures outlined in this document
defined in <xref target="flags"/> is present. SR-Algorithm is are employed to specify the return path when IP connectivity to the
used by the receiver to derive the label. When A-flag is unset, initiator is unavailable. These procedures may also be utilized
this field has no regardless of the availability of IP connectivity. The LSP ping
meaning and thus MUST be set to zero (MBZ) on transmission and initiator <bcp14>MUST</bcp14> set the Reply Mode of the echo request
ignored on receipt.</t> to 5 (Reply via Specified Path), and a Reply Path TLV
<bcp14>MUST</bcp14> be carried in the echo request message
correspondingly. The Reply Path TLV <bcp14>MUST</bcp14> contain the
SR Path in the reverse direction encoded as an ordered list of
segments. The first segment <bcp14>MUST</bcp14> correspond to the top
segment in the MPLS header that the responder <bcp14>MUST</bcp14> use
while sending the echo reply.
</t>
</section>
<t> IPv6 Node Address: 16-octet IPv6 address of one interface of a node. <section anchor="responder_procedure" numbered="true" toc="default">
The IPv6 Node Address MUST be present. <name>Receiving an Echo Request</name>
It should be a stable address b
elonging
to the node (eg:loopback
address).</t>
<t> SID: optional: 4-octet field containing label, TC, S and <t>As described in <xref target="RFC7110" format="default"/>, when the
TTL as defined in <xref target="type1"/>. Reply Mode is set to 5 (Reply via Specified Path), the echo request
The SID is optional and specifies a 4-octet MPLS SID containing must contain the Reply Path TLV. The absence of the Reply Path TLV is
label, TC, S, and TTL as defined in <xref target="type1"/>. When the treated as a malformed echo request. When an echo request is
SID field is present, it MUST be used for received, if the responder does not support the Reply Mode 5 defined
constructing the Reply Path.</t> in <xref 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" 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.</t>
<t>When a Reply Path TLV is received, the responder that supports
processing it <bcp14>MUST</bcp14> use the segments in Reply Path TLV
to build the echo reply. The responder <bcp14>MUST</bcp14> follow the
normal Forwarding Equivalence Class (FEC) validation procedures as descr
ibed in <xref
target="RFC8029" format="default"/> and <xref target="RFC8287"
format="default"/> and this document does not suggest any change to
those procedures. When the echo reply has to be sent out, the Reply
Path TLV <bcp14>MUST</bcp14> be used to construct the MPLS packet to
send out.</t>
</section> </section>
<section anchor='flags' title='Segment Flags'> <section anchor="sending_echo_reply" numbered="true" toc="default">
<name>Sending an Echo Reply</name>
<t>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"): </t>
<figure anchor="flags_field" title="Flags">
<artwork>
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A| | | | | | |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>where:</t>
<t>A-Flag: This flag indicates the presence of SR Algorithm ID in the
"SR-Algorithm" field applicable to various segment Types. </t>
<t>Unused bits in the Flag octet MUST be set to zero upon <t>The echo reply message is sent as an MPLS packet with an MPLS label
transmission and MUST be ignored upon receipt.</t> stack. The echo reply message <bcp14>MUST</bcp14> be constructed as
described in <xref target="RFC8029" format="default"/>. An MPLS packet
is constructed with an echo reply in the payload. The top label
<bcp14>MUST</bcp14> be constructed from the first segment of the Reply
Path TLV. The remaining labels <bcp14>MUST</bcp14> be constructed by
following the order of the segments from the Reply Path TLV. The MPLS
header of the echo reply <bcp14>MUST</bcp14> be constructed from the
segments in the Reply Path TLV and <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" format="default"/>. The
responder <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
<bcp14>SHOULD</bcp14> send the appropriate Return Code and follow the
procedures as per <xref 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, it may not be
possible to send an echo reply at all. Even if sent (by following a
default route present on the responder, for example), the echo reply
might not reach the originator. The node <bcp14>MAY</bcp14> provide
necessary log information in case of unreachability. In certain
scenarios, the head-end <bcp14>MAY</bcp14> choose to send
Type-C/Type-D segments consisting of IPv4 addresses or IPv6 addresses
when it is unable to derive the SID from available topology
information. 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 <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, the SID <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 following applies to the Segment Flags:</t> <t>The Reply Path Return Code is set as described in <xref
target="RFC7110" sectionFormat="of" section="7.4"/>. According to
<xref 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> A-Flag applies to Segment Type-C and Type-D. If A-Flag <t>When the node is configured to dynamically create a return path for
appears with Type-A Segment Type, it MUST be ignored.</t> the next echo request, the procedures described in <xref
</section> target="Dynamic_TLV_building" format="default"/> <bcp14>MUST</bcp14>
be used. The Reply Path Return Code <bcp14>MUST</bcp14> be set to
0x0006, and the same Reply Path TLV or a new Reply Path TLV
<bcp14>MUST</bcp14> be included in the echo reply.</t>
</section>
</section> <section anchor="Receiving_echo_reply" numbered="true" toc="default">
<name>Receiving an Echo Reply</name>
<t>The rules and processes defined in <xref target="RFC8029"
sectionFormat="of" section="4.6"/> and <xref target="RFC7110"
sectionFormat="of" section="5.4"/> apply here. In addition, if the
Reply Path Return Code is "Use Reply Path TLV from this echo reply for
building the next echo request" (as defined in this document), the Reply
Path TLV from the echo reply <bcp14>MUST</bcp14> be sent in the next
echo request with the TTL incremented by 1. If the initiator node does n
ot
support the Return Code "Use Reply Path TLV from this echo reply for
building the next echo request", log information should be generated
indicating the Return 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 0x0007 "Local policy does not allow
dynamic 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, 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 <bcp14>MUST</bcp14> be ended with an
appropriate log message.</t>
</section>
<section anchor="Dynamic_TLV_building" numbered="true" toc="default">
<name>Building a Reply Path TLV Dynamically</name>
<t>In some cases, the head-end may not have complete visibility of
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 from this echo reply for building the
next echo request" is defined in this document.
</t>
<section anchor='procedure' title='Detailed Procedures '> <table anchor="tba1-value">
<t> This section uses the term "initiator" for the node that initiates the <name></name>
MPLS ping or MPLS traceroute procedure. The term "responder" is used for the <thead>
node that receives the echo request and sends the echo reply. <tr>
The term egress node is used to identify the <th>Value</th>
last node where the MPLS ping or traceroute is destined to. In an MPLS network <th>Meaning</th>
any node can be initiator or responder or egress.</t> </tr>
</thead>
<tbody>
<tr>
<td>0x0006</td>
<td>Use Reply Path TLV from this echo reply for building the next echo req
uest</td>
</tr>
</tbody>
</table>
<section anchor='initiator_procedure' title='Sending an Echo Request'> <section anchor="TLV_build_procedures" numbered="true" toc="default">
<t>In the inter-AS scenario, the procedures outlined in this <name>Procedures to Build the Return Path</name>
document are employed to specify the return path when IP <t>To dynamically build the return path for the traceroute
connectivity to the initiator is unavailable. These procedures procedures, the domain border nodes along the path being traced
may also be utilized regardless of the availability of IP should support the procedures described in this section. Local
connectivity. policy on the domain border nodes should determine whether the
The LSP ping initiator MUST set the Reply Mode of the echo domain border node participates in building the return path
request to 5 "Reply via Specified Path", and a Reply Path dynamically during traceroute.</t>
TLV MUST be carried in the echo request message correspondingly.
The Reply Path TLV MUST contain the SR Path in the
reverse direction encoded as an ordered list
of segments. The first segment MUST correspond to the top segment in
the MPLS header that the responder MUST use while sending the echo reply.
</t>
</section>
<section anchor='responder_procedure' title='Receiving an Echo Request'>
<t>As described in <xref target="RFC7110"/>, when Reply mode is set
to 5 (Reply via Specified Path), the echo request must contain the Reply
path TLV. Absence of 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"/>, 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"/>. If the echo request message contains
a malformed Segment sub-TLV, such as incorrect length field,
an echo reply with return code set to
"Malformed echo request received" and the
Subcode set to zero must be sent back to the initiator.</t>
<t>When a Reply Path TLV is received, the responder that <t>The head-end/PMS node may include its node label while initiating
supports processing it, MUST use the segments in Reply Path TLV to build the traceroute procedure. When an Area Border Router (ABR) receives
the echo reply. The responder MUST follow the normal FEC validation the echo request, if the local policy implies building a dynamic
procedures as described in <xref target="RFC8029"/> return path, the ABR should include its node label in the Reply Path T
and <xref target="RFC8287"/> and this document does not suggest LV
any change to those procedures. When the echo reply has to be sent and send it in the echo reply. If there is a Reply Path TLV
out the Reply Path TLV MUST be used to construct the MPLS packet to send out. included in the received echo request message, the ABR's node label
</t> is added before the existing segments. The type of segment added is
</section> based on local policy. In cases when the Segment Routing Global
<section anchor='sending_echo_reply' title='Sending an Echo Reply'> Block (SRGB) is not uniform across the network, which can be
<t>The echo reply message is sent as an MPLS packet with an MPLS label stack. inferred from the LSDB, it is <bcp14>RECOMMENDED</bcp14> to add a
The echo reply message MUST be constructed Type-C or a Type-D segment. However, implementations <bcp14>MAY</bcp14
as described in the <xref target="RFC8029"/>. An MPLS packet is >
constructed with an echo reply in the payload. safely use other approaches if they see benefits in doing so. If the
The top label MUST be constructed from the first segment of the existing segment in the Reply Path TLV is a Type-C/Type-D segment,
Reply Path TLV. that segment should be converted to a Type-A segment based on the
The remaining labels MUST be constructed by ABR's own SRGB. This is because downstream nodes in the path will
following the order of the segments from the Reply Path TLV. not know what SRGB to use to translate the IP address to a label. As
The MPLS header of the Echo Reply MUST be constructed from the segments in Reply the ABR added its own node label, it is guaranteed that this ABR
Path TLV will be in the return path and will be forwarding the traffic based
and MUST NOT add any other label. on the next label after its label.</t>
The S bit is set for the bottom label as per MPLS specifications <xref target="R
FC3032"/>
The responder MAY 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 send the
appropriate return code and follow procedures as per section 5.2 of
<xref target="RFC7110"/>. The exception case is when the responder
does not have IP reachability to the originator, in which case it may
not be possible to send an Echo Reply at all. Even if sent (for
example by following a default route present on the responder), the
Echo Reply might not reach the originator. The node MAY provide
necessary log information in case of unreachability.
In certain scenarios, the head-end <t>When an ASBR receives an echo request from another AS, and the
MAY choose to send Type-C/Type-D segments consisting of IPv4 addresses or ASBR is configured to build the return path dynamically, the ASBR
IPv6 addresses, when it is unable to derive the SID from should build a Reply Path TLV and include it in the echo reply. The
available topology information. Optionally SID may also be associated with Reply Path TLV should consist of its node label and an EPE-SID to
the Type-C/Type-D segment, if such information is available the AS from where the traceroute message was received. A Reply Path
from the controller or via operator input. In such cases, the node sending the Return Code of 0x0006 <bcp14>MUST</bcp14> be set in the echo reply to
echo reply MUST derive the MPLS labels based on Node-SIDs associated with the indicate that the next echo request <bcp14>MUST</bcp14> use the
IPv4/IPv6 addresses. If optional MPLS SID is present in the Type-C/Type-D segmen return path from the Reply Path TLV in the echo reply. ASBR should
ts locally decide the outgoing interface for the echo reply
SID MUST be used to encode the echo reply with MPLS labels. If the MPLS SID does packet. Generally, remote ASBR will choose the interface on which
not the incoming OAM packet was received to send the echo reply out. In
match with the IPv4 or IPv6 address field in the Type-C or Type-D SID, case the ASBR identifies multiple paths to reach the initiator, it
log information should be generated.</t> <bcp14>MUST</bcp14> choose to send one such path in the Reply Path
<t> TLV. The Reply Path TLV is built by adding two Segment sub-TLVs. The
The reply path return code is set as described in section 7.4 of top Segment sub-TLV consists of the ASBR's Node-SID, and the second
<xref target="RFC7110"/>. According to section 5.3 of <xref target="RFC7110"/>, segment consists of the EPE-SID in the reverse direction to reach
the Reply Path TLV is included in an echo reply indicating the the AS from which the OAM packet was received. The type of segment
specified return path that the echo reply message is required to chosen to build the Reply Path TLV is a local policy. It is recommende
follow.</t> d
<t> to use the Type-C/Type-D segment for the top segment when the SRGB
When the node is configured to dynamically create a return path is not guaranteed to be uniform in the domain.</t>
for the next echo request,
the procedures described in <xref target="Dynamic_TLV_building"/> MUST be used.
The reply path return code MUST be set to TBA1 and the same Reply Path TLV
or a new Reply Path TLV MUST be included in the echo reply.
</t> <t>Irrespective of which type of segment is included in the Reply
</section> Path TLV, the responder to the echo requests <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>
<section anchor='Receiving_echo_reply' title='Receiving an Echo Reply'> <t>An ASBR that receives the echo request from a neighbor belonging
<t>The rules and processes defined in Section 4.6 of <xref target="RFC8029"/> to the same AS <bcp14>MUST</bcp14> look at the Reply Path TLV
and Section 5.4 of <xref target="RFC7110"/> apply here. In addition, received in the echo request. If the Reply Path TLV consists of a
if the Reply Path return code is "Use Reply Path TLV Type-C/Type-D segment, it <bcp14>MUST</bcp14> convert the
in the echo reply for building the next echo request" (defined in this document) Type-C/Type-D segment to a Type-A segment by deriving a label from
, its own SRGB. The ASBR <bcp14>MUST</bcp14> set the Reply Path Return
the Reply Path TLV from the Code to 0x0006 and send the newly constructed Reply Path TLV in the
echo Reply MUST be sent in the next echo request with TTL echo reply.</t>
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 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, "Local policy does not allow dynamic Return <t>Internal nodes or non-domain border nodes might not set the Reply
Path building", it indicates that the intermediate node does not support Path TLV Return Code to 0x0006 in the echo reply message as there is
building the dynamic return path. Log information should be generated no change in the return path. In these cases, the head-end node/PMS
on the initiator receiving that initiates the traceroute procedure <bcp14>MUST</bcp14> continue
this return code and the operator may choose to specify the to send the previously sent Reply Path TLV in the echo request
return path explicitly message in every subsequent echo request. </t>
or use other mechanisms to verify the SR Policy.
If the TTL is already 255, the traceroute procedure
MUST be ended with an appropriate log message.
</t>
</section>
<section anchor='Dynamic_TLV_building'
title='Building Reply Path TLV Dynamically'>
<t>In some cases, the head-end may not have complete visibility of
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> <t>Note that an ASBR's local policy may prohibit it from
Value Meaning participating in the dynamic traceroute procedures. If such an ASBR
------ ---------------------- is encountered in the forward path, dynamic return path building
TBA1 Use Reply Path TLV in the echo reply procedures will fail. In such cases, an ASBR that supports this
for building the next echo request. document <bcp14>MUST</bcp14> set the Return Code to 0x0007 to indicate
that
local policies do not allow the dynamic return path building.</t>
</artwork> <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</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
</t> <section 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
<bcp14>MUST</bcp14> deploy appropriate filter policies as described in
<xref target="RFC8029" format="default"/> to restrict the LSP ping and
traceroute packets based on origin. It is also
<bcp14>RECOMMENDED</bcp14> that an operator deploy security mechanisms
such as Media Access Control Security (MACsec) <xref target="IEEE-802.1AE"
format="default"/> on
inter-domain links or security-vulnerable links to prevent spoofing
attacks.</t>
<section anchor='TLV_build_procedures' title='The Procedures to Build the Return <t>All the security considerations defined in <xref target="RFC8029"
Path'> format="default"/> will be applicable for this document. Appropriate
<t> To dynamically build the return Path for the traceroute procedures, filter policies <bcp14>SHOULD</bcp14> be applied at the edges to prevent
the domain border nodes along the path being traced should support the attackers from getting into the network. In the event of such a security
procedures described in this section. Local policy on the domain border nodes breach, the network devices <bcp14>MUST</bcp14> have mechanisms to
should determine whether the domain border node participates in building prevent denial-of-service attacks as described in <xref target="RFC8029"
the return path dynamically during traceroute.</t> format="default"/>.</t>
<t> The head-end/PMS node may include its node label while initiating the tracer </section>
oute
procedure. When an Area Border Router (ABR) receives the echo request,
if the local policy
implies building a dynamic return path, ABR should include its Node label
in the 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 is not
uniform across the
network which can be inferred from the LSDB, it is RECOMMENDED to add a Type-C o
r a Type-D segment,
but implementations MAY 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, <section anchor="IANA" numbered="true" toc="default">
that segment should be converted to a Type-A segment based on the ABR's <name>IANA Considerations</name>
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
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 <section anchor="iana_segment_sub_tlv" numbered="true" toc="default">
configured to build the return path dynamically, <name>Segment Sub-TLV</name>
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 be set in the echo reply to
indicate that the next echo request
MUST use the return 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 choos
e
to send one such path in the Reply Path TLV.
Reply Path TLV is built by adding two segment sub TLVs. The top segment
sub TLV consists of the ASBR's 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
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 of which type of segment is included in the Reply Path TLV,
the responder
to the echo requests MUST 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 ASBR that receives the echo request from a neighbor
belonging to the same AS,
MUST 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 convert the Type-C/Type-D
segment to a Type-A
segment by deriving a label from its own SRGB. The ASBR MUST set the
reply path return code to TBA1
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 <t>IANA has assigned three new sub-TLVs from the "Sub-TLVs for TLV
return code to TBA1 in the Types 1, 16, and 21" registry of the "Multiprotocol Label
echo reply message as there is no change in the return Path. In these cases, Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
the head-end node/PMS that initiates the traceroute procedure MUST continue registry group.</t>
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 <table anchor="segment-subTLVs">
in the dynamic <name></name>
traceroute procedures. If such an ASBR is encountered in the forward path, <thead>
dynamic return path-building procedures will fail. In such cases, <tr>
an ASBR that supports this document MUST set the <th>Sub-Type</th>
return code TBA2 to indicate local policies do not allow the dynamic <th>Sub-TLV Name</th>
return path building.</t> <th>Reference</th>
<t> </tr>
</thead>
<tbody>
<tr>
<td>46</td>
<td>SID only, in the form of MPLS label</td>
<td><xref target="type1"/> of RFC 9716</td>
</tr>
<tr>
<td>47</td>
<td>IPv4 Node Address with an optional SID for SR-MPLS</td>
<td><xref target="type3"/> of RFC 9716</td>
</tr>
<tr>
<td>48</td>
<td>IPv6 Node Address with an optional SID for SR-MPLS</td>
<td><xref target="type4"/> of RFC 9716</td>
</tr>
</tbody>
</table>
<artwork> <t>The allocation of code points for the Segment sub-TLVs should be
Value Meaning done from the Standards Action range (0-16383).</t>
------ --------------------------------------------------- </section>
TBA2 Local policy does not allow dynamic Return Path
building.
</artwork> <section anchor="segment_sub_tlv_flags" numbered="true" toc="default">
<name>New Registry for Segment ID Sub-TLV Flags</name>
<t>IANA has created a new "Segment ID Sub-TLV Flags" registry (see <xref
target="flags" format="default"/>) under the "Multiprotocol
Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters"
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 (the most significan
t
bit and transmitted first) to 7.</t>
<t>New entries are assigned by Standards Action. Initial entries in
the registry are as follows:</t>
</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 RFC 9716</td>
</tr>
</tbody>
</table>
</section>
</section> <section anchor="iana_return_code" numbered="true" toc="default">
</section> <name>Reply Path Return Codes Registry</name>
</section> <t>IANA has assigned new Return Codes in the "Reply Path Return
Codes" registry under the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" 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 from this echo reply for building the next e
cho request</td>
<td>RFC 9716</td>
</tr>
<tr>
<td>0x0007</td>
<td>Local policy does not allow dynamic return path building</td>
<td>RFC 9716</td>
</tr>
</tbody>
</table>
<section title='Security Considerations' anchor='sec-con'> <t>The Return Codes should be assigned from the Standards Action range (
<t> The procedures described in this document enable LSP ping and traceroute 0x0000-0xFFFB).</t>
to be </section>
executed across multiple IGP domains or multiple ASes that belong to the sam </section>
e administration
or closely cooperating administrations. It is assumed that sharing domain in
ternal
information across such domains does not pose a security risk.
However, procedures described in this document may be used by an attacker to
extract the
domain's internal information. An operator MUST deploy appropriate filter po
licies
as described in <xref target="RFC8029"/> to restrict the LSP ping/traceroute
packets based on origin.
It is also RECOMMENDED that an operator deploy security mechanisms such as M
ACsec
<xref target="IEEE-802.1AE"/>
on inter-domain links or security-vulnerable links to prevent spoofing attac
ks. </t>
<t> All the security considerations
defined in <xref target="RFC8029"/> will be applicable for this document.
Appropriate filter policies SHOULD be applied at the edges to prevent attacke
rs
from getting into the network. In the event of such a security breach, the n
etwork devices
MUST have mechanisms to prevent Denial-of-service attacks
as described in <xref target="RFC8029"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<section anchor="iana_segment_sub_tlv" title="Segment Sub-TLV"> </middle>
<t>IANA should assign three new sub-TLVs from the "sub-TLVs for TLV Types
1, 16, and 21" sub-registry of the "Multiprotocol Label Switching
(MPLS) Label Switched Paths (LSPs) Ping Parameters" registry.
<artwork> <back>
Sub-Type Sub-TLV Name Reference <references>
-------- ----------------- ------------ <name>References</name>
TBD1 SID only in the form of MPLS Section 4.1 <references>
label of this document <name>Normative References</name>
TBD2 IPv4 Node Address with Section 4.2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
optional SID for SR-MPLS of this document 174.xml"/>
TBD3 IPv6 Node Address with Section 4.3 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
optional SID for SR-MPLS of this document 119.xml"/>
</artwork> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
The allocation of code points for the segment sub-TLVs should be done from the 287.xml"/>
Standards Action range (0-16383) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</t> 029.xml"/>
</section> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<section anchor="segment_sub_tlv_flags" title="New Registry for Segment S 110.xml"/>
ub-TLV Flags"> </references>
<t>IANA should create a new "Segment ID Sub-TLV flags" <references>
(see <name>Informative References</name>
Section <xref target="flags"/>) registry under the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
"Multiprotocol Label Switching (MPLS) 032.xml"/>
Label Switched Paths (LSPs) Ping Parameters" registry. </t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>This registry tracks the assignment of 8 flags in the Segment ID 403.xml"/>
sub-TLV flags field. The flags are <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
numbered from 0 (most significant bit, transmitted first) to 7.</t> 402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
604.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
743.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
277.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
660.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
087.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<t>New entries are assigned by Standards Action. <reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/doc
ument/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>
Initial entries in the registry are as follows: </references>
</references>
<artwork> <section numbered="true" toc="default">
<name>Examples</name>
<t>This section elaborates examples of the inter-domain ping and
traceroute procedures described in this document.</t>
Bit number | Name | Reference <section anchor="Topology_description" numbered="true" toc="default">
------------+----------------------------+-------------- <name>Detailed Example</name>
1 | A Flag | Section 4.4 <t>The example topology given in <xref target="Topology_1"
| | of this document 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>
</artwork> <t>AS1 and AS2 have SR enabled. IGPs like OSPF/IS-IS are used to flood
SIDs in each AS. ASBR1, ASBR2, ASBR3, and ASBR4 advertise BGP
EPE-SIDs for the inter-AS links. The topologies of AS1 and AS2 are
advertised via 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" format="default"/>. The example
uses EPE-SIDs for the inter-AS links, but the same could be achieved
using Adjacency-SIDs advertised for a passive IGP link.</t>
</t> <t>The description in this document uses the notations below for SIDs.</
</section> t>
<section anchor="iana_return_code" title="Reply Path Return Codes Registry">
<t> IANA should assign new return codes in the "Reply path return codes" reg
istry
under the "Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry.
<artwork> <t>Node-SIDs: N-PE1, N-P1, N-ASBR1, etc.</t>
<t>Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2, etc.</t>
<t>EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2, etc.</t>
Value Meaning Reference <section anchor="Mpls_ping_procedures" numbered="true" toc="default">
-------- ----------------- ------------ <name>Procedures for Segment Routing LSP Ping</name>
TBA1 Use Reply Path TLV This document
from this echo reply
for building next
echo request.
TBA2 Local policy does This document <t>Consider an SR-MPLS path from PE1 to PE4 consisting of a label
not allow dynamic stack [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from <xref
return Path building. 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 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>
</artwork> <t>PE1 sends an echo request message to the endpoint PE4 along the
The return codes should be assigned from the Standards Action range (0x0000-0 path that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4,
xFFFB). N-PE4]. PE1 adds the return path from PE4 to PE1 in the echo
</t> request message in the Reply Path TLV. As an example, the Reply Path
</section> 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>
</section> <t>An implementation may also build a return path consisting of
<section title='Contributors'> labels to reach its own AS. Once the label stack is popped off, the
<t>Carlos Pignataro</t> echo reply message will be exposed. The further packet forwarding
<t>NC State University</t> will be based on IP lookup. An example return path for this case
<t>cpignata@gmail.com</t> could be [N-ASBR4, EPE-ASBR4-ASBR1].</t>
<t> </t> <t>On receiving an MPLS echo request, PE4 first validates the FEC in
<t>Zafar Ali</t> the echo request. PE4 then builds a label stack to send the
<t>Cisco Systems, Inc.</t> response from PE4 to PE1 by copying the labels from the Reply Path
<t>zali@cisco.com</t> TLV. PE4 builds the echo reply packet with the MPLS label stack
constructed, imposes MPLS headers on top of the echo reply packet,
and sends out the packet to PE1. This segment list stack can
successfully steer the reply back to the head-end node (PE1).</t>
</section> <t>Let us consider a case when the P3 node does not have a route to
<section title='Implementation Status'> reach N-PE4. On P3, a ping packet would be dropped, and the head-end
<t>This section is to be removed before publishing as an RFC.</t> node (PE1) will not receive an echo reply indicating failure.</t>
</section>
<t>RFC-Editor: Please clean up the references cited by this section <section anchor="Mpls_traceroute_procedures" numbered="true" toc="defaul
before publication.</t> t">
<t>This section records the status of known implementations of the <name>Procedures for SR LSP Traceroute</name>
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942
"/>.
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.</t>
<section title='Juniper Networks'>
<t>Organization: Juniper Networks</t>
<t>Implementation: JUNOS.</t>
<t>Description: Implementation for sending Return path TLV with Type-A segmen
t 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 the use of generic Segment sub-T
LV.
Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody,
Dongjie, for careful review 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>
<section title='APPENDIX'>
<t>This section elaborates examples of the inter-domain ping and Traceroute
procedures described in this document.</t>
<section anchor='Topology_description' title='Detailed Example '>
<t>The example topology given in <xref target="Topology_1"/> 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>
<t>AS1 and AS2 have SR enabled.
IGPs like OSPF/ISIS are used to flood
SIDs in each AS. The ASBR1,
ASBR2, ASBR3,and ASBR4 advertise BGP EPE-SIDs
for the inter-AS links.
Topology of AS1 and AS2 are advertised via 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"/>. The example uses EPE-SIDs for the inter-AS links
but the same could be achieved using adjacency-SIDs advertised for a passive
IGP link.</t>
<t>The description in the document uses below notations for
Segment Identifiers (SIDs).</t>
<t>Node-SIDs: N-PE1, N-P1, N-ASBR1 etc.</t>
<t>Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2 etc.</t>
<t>EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc.</t>
<section anchor='Mpls_ping_procedures' title='Procedures for Segment Routing LSP <section anchor="traceroute_same_srgb" numbered="true" toc="default">
ping'> <name>Procedures for SR LSP Traceroute with the Same SRGB on All Nod
<t>Consider an SR-MPLS path from PE1 to PE4 consisting of a label stack es</name>
[N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from <xref target="Topology_1"/>. <t>The traceroute procedure involves visiting every node on the
In order to perform MPLS ping procedures on this path, the remote end (PE4) path and obtaining echo replies from every node. In this section,
needs IP connectivity to head-end PE1, for the echo reply to travel back to PE1. we describe the traceroute mechanisms when the head-end/PMS has
In a deployment that uses a controller-computed inter-domain path, complete visibility of the LSDB. The head-end/PMS computes the
there may be no IP connectivity from PE4 to PE1 as they lie in return path from each node in the entire SR-MPLS path that is
different ASes.</t> being tracerouted. The return path computation is implementation
dependent. As the head-end/PMS completely controls the return
path, it can use proprietary computations to build the return
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>
<t> PE1 sends an echo request message to the endpoint PE4 along the <t>The inter-domain/inter-AS traceroute procedure uses the TTL
path that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. expiry mechanism as specified in <xref target="RFC8029"
PE1 adds the return path from PE4 to PE1 in the echo request message in the format="default"/> and <xref target="RFC8287" format="default"/>.
Reply Path TLV. As an example, the Reply Path TLV for PE1 to PE4 for Every echo request packet head-end/PMS will include the
LSP ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This example path appropriate return path in the Reply Path TLV. The node that
provides the entire return path up to the head-end node PE1. The mechanism receives the echo request will follow procedures described in
used to construct the return path is implementation-dependent. Sections <xref target="initiator_procedure" format="counter"/> and <
</t> xref
<t>An implementation may also build a return Path consisting of labels target="responder_procedure" format="counter"/> to send out an
to reach its own AS. Once the echo reply.</t>
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 for this case could be [N-ASBR4, EPE-ASBR4-ASBR1].</t>
<t>On receiving an MPLS echo request, PE4 first validates FEC in the echo reques <t>For example:</t>
t. <t>Let us consider the topology from <xref target="Topology_1"
PE4 then builds a label stack to send the response from PE4 to PE1 by copying format="default"/>. Let us consider an SR-MPLS path [N-P1,
the labels from the Reply Path TLV. PE4 builds the echo reply packet N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. The traceroute is being
with the MPLS label stack constructed and imposes MPLS headers executed for this inter-AS path for destination PE4. PE1 sends
on top of the echo reply packet and sends out the packet to PE1. the first echo request with the TTL set to 1 and includes a Reply Pa
This segment List stack can successfully steer the reply back to the head-end no th
de (PE1).</t> TLV consisting of a Type-A segment containing a label derived from
its own SRGB. Note that the type of segment
used in constructing the return 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, 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> Let us consider a case when P3 node does not have a route to reach N-PE4. <t>The TTL is set to 2, and the next echo request is sent
On P3 ping packet would be dropped and the head-end node (PE1) will out. Until the traceroute procedure reaches the domain border node
not receive Echo Reply indicating failure.</t> ASBR1, the same return path TLV consisting of a single label
(PE1's node 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"
format="default"/> and <xref target="RFC9086" format="default"/>)
and can derive the details of 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:
[EPE-ASBR4-ASBR1, N-PE1]. The echo reply from ASBR4 will use this
return path to send the reply.</t>
</section> <t>After visiting the border node ASBR4, the next echo request
<section anchor='Mpls_traceroute_procedures' title='Procedures for SR LSP tracer will update the return path with the Node-SID label of ASBR4. The
oute'> return path beyond ASBR4 will be [N-ASBR4, EPE-ASBR4-ASBR1,
<section anchor='traceroute_same_srgb' N-PE1]. This same return path is used until the traceroute
title='Procedures for SR LSP traceroute with the Same SRGB on All Nodes'> procedure reaches the next set of border nodes. When there are
<t>The traceroute procedure involves visiting every node on the path and multiple ASes, the traceroute procedure will continue by adding a
obtaining echo replies from every node. In this section, we describe the tracero set of Node-SIDs and EPE-SIDs as the border nodes are visited.</t>
ute 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.
As the head-end/PMS completely controls the return path, it can use proprietary
computations to build the return 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 progress
es.
For inter-AS networks, in addition to the border node's Node-SID, EPE-SID in the
reverse
direction also needs to be added to the label stack.
</t>
<t>The Inter-domain/inter-AS traceroute procedure uses the TTL expiry
mechanism as specified in <xref target="RFC8029"/> and
<xref target="RFC8287"/>. 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 <xref target="initiator_procedure"/> and
<xref target="responder_procedure"/> to send out an echo reply.
</t>
<t>For Example: </t> <t>Note that the above return path building procedure requires the
<t> Let us consider a topology from <xref target="Topology_1"/>. LSDB of all the domains to be available at the head-end/PMS.</t>
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 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).
Note that the type of segment used in constructing the return Path is determined
by
local policy. If the entire network has the same SRGB configured, Type-A segment
s
can be used. The TTL expires on 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 PE
1
is expected to be available inside the first domain.</t>
<t> The TTL is set to 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 (PE1's node 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 <xref target="RFC9552"/>
and <xref target="RFC9086"/> and can derive the details of Autonomous
System Boundary Router (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 [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 visiting the border node ASBR4 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 multip
le ASes
the traceroute procedure will continue by adding a set of Node-SIDs and
EPE-SIDs as the border nodes are visited.
</t>
<t>Note that the above return path-building procedure requires the LSDB of all t
he
domains to be available at the head-end/PMS. </t>
<t> Let us consider a case when P3 node does not have a route to reach N-PE4. <t>Let us consider a case when the P3 node does not have a route
When TTL of the packet is 5, the packet reaches P3 and the packet TTL become to reach N-PE4. When the TTL of the packet is 5, the packet
s reaches P3, its TTL becomes zero, and it is sent to the control
zero and the packet is sent to the control plane. The FEC validation Proc plane. The FEC validation procedures are executed, and the echo
edures reply is sent using the labels in the Reply Path TLV, which is [N-PE
are executed and the Echo Reply is sent using the labels in Reply Path TL 1,
V which is EPE-ASBR4-ASBR1, N-ASBR4]. The head-end PE1 increases the TTL to 6
[N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. and sends the next echo request. The packet is dropped at P3 as ther
Head-end PE1 increases the TTL to 6 and sends next Echo Request. The packet is d e
ropped is no route on P3 to forward to N-PE4. The traceroute identifies tha
at P3 as there is no route on P3 to forward to N-PE4. Traceroute identifies the t
path the path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at
[N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at P3.</t> P3.</t>
</section> </section>
<section anchor='traceroute_different_srgb'
title='Procedures for SR LSP Traceroute with the Different SRGBs'>
<t> <xref target="traceroute_same_srgb"/> assumes the same
SRGB is configured on all nodes along the path.
The SRGB may differ from one node to another node and the SR
architecture <xref target="RFC8402"/>
allows the nodes to use different SRGBs. In such scenarios, PE1
finds out the difference in SRGB by looking into the LSDB and sends Type-C
(or Type-D in the case of IPv6 networks) segment with the node address of PE1 a
nd
with 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. Th
is is
required because, ASBR4, P3, P4, etc. may not have the topology information to
derive SRGB for PE1. After the traceroute procedure reaches ASBR4 the return pat
h
will be [N-PE1 (Type-A with label based on ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASB
R4 (Type-C)].</t>
<t> If the packet needs to follow return path specific to an algorithm <section anchor="traceroute_different_srgb" numbered="true" toc="defau
(as defined in <xref target="RFC9350"/>), a Type-C Segment sub-TLV with correspo lt">
nding <name>Procedures for SR LSP Traceroute with Different SRGBs</name>
algorithm field set should be used. A-flag should be set to indicate that the
SID corresponding to the algorithm should be used.</t>
<t> To extend the example to 3 or more ASes, let us consider <t><xref target="traceroute_same_srgb" format="default"/> assumes
a traceroute from PE1 to PE5 in <xref target="Topology_1"/>. In this example, the same SRGB is configured on all nodes along the path. The SRGB
the PE1 to PE5 path has to cross 3 domains AS1, AS2, and AS3. Let us consider a may differ from one node to another node, and the SR architecture
path from PE1 <xref target="RFC8402" format="default"/> allows the nodes to use
to PE5 that goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, PE5]. different SRGBs. In such scenarios, PE1 finds out the difference
When the traceroute procedure is visiting the nodes in AS1, the Reply Path TLV in the SRGB by looking into the LSDB. Then, it sends the Type-C
sent from the head-end consists of [N-PE1]. When the traceroute procedure reache segment (or the Type-D segment, in the case of IPv6 networks) with
s the ASBR4, the node address of PE1 and with an optional MPLS SID associated
the return Path consists of [N-PE1, EPE-ASBR4-ASBR1]. While visiting nodes in AS with the node address. The receiving node derives the label for
2, the return path based on its own SRGB. When the traceroute
the traceroute procedure consists of Reply Path TLV [N-PE1, EPE-ASBR4-ASBR1, N-A procedure crosses the border ASBR1, head-end PE1 should send a
SBR4]. Type-A segment for N-PE1 based on the label derived from ASBR1's
Similarly, while visiting ASBR8, the EPE-SID from ASBR8 to ASBR6 is added to the SRGB. This is required because ASBR4, P3, P4, etc. may not have
Reply Path TLV. the topology information to derive SRGB for PE1. After the
While visiting nodes in AS3, the Node-SID of ASBR8 would also be added which mak traceroute procedure reaches ASBR4, the return path will be [N-PE1
es the (Type-A with the label based on ASBR1's SRGB), EPE-ASBR4-ASBR1,
return Path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE-ASBR8-ASBR6, N-ASBR8]</t> N-ASBR4 (Type-C)].</t>
<t>Let us consider another example from topology <xref target="Topology_2"/>. <t>If the packet needs to follow a return path specific to an
This topology consists of multi-domain IGP with a common border node between the algorithm (as defined in <xref target="RFC9350"
domains. format="default"/>), a Type-C Segment sub-TLV with a corresponding
This could be achieved with multi-area or multi-level IGP or multiple instances algorithm field set should be used. The A-Flag should be set to
of IGP indicate that the SID corresponding to the algorithm should be
deployed on the same node. used.</t>
The return path computation for this topology is similar to the multi-AS computa
tion
except that the return path consists of a single border node label. </t>
</section>
</section> <t>To extend the example to three or more ASes, let us consider a
<section anchor='TLV_build_procedure_example' traceroute from PE1 to PE5 in <xref target="Topology_1"
title='Procedures for building Reply Path TLV dynamically'> format="default"/>. In this example, the PE1 to PE5 path has to
<t>Let us consider a topology from <xref target="Topology_1"/>. cross three domains: AS1, AS2, and AS3. Let us consider a path from
Let us consider an SR policy path built from PE1 to PE4 PE1
with the label stack, to PE5 that goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, PE5].
N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. 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
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,
which makes the return path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4,
EPE-ASBR8-ASBR6, N-ASBR8].</t>
PE1 begins traceroute with the TTL set to 1 and includes [N-PE1] in the <t>Let us consider another example from the topology in <xref
Reply Path TLV. target="Topology_2" format="default"/>. This topology consists of
The traceroute packet TTL expires on P1 and P1 processes the multi-domain IGP with a common border node between the domains.
traceroute as per the This could be achieved with multi-area or multi-level IGP or with
procedures described in <xref target="RFC8029"/> and multiple instances of IGP deployed on the same node. The return
<xref target="RFC8287"/>. path computation for this topology is similar to multi-AS
P1 sends an echo reply with the same Reply Path TLV with the reply path computation, except that the return path consists of a single
return code set to 6. border node label.</t>
The return code of the echo reply itself is set to the return code as per </section>
<xref target="RFC8029"/> and <xref target="RFC8287"/>. </section>
This traceroute doesn't need any changes to the Reply Path TLV
till it leaves AS1. The same Reply Path TLV that is received may be
included in the
echo reply by P1 and P2 or no Reply Path TLV included so that head-end
continues to
use the same return path in the echo request that it used to
send the previous echo request.</t>
<t>When ASBR1 receives the echo request, in the case it receives the <section anchor="TLV_build_procedure_example" numbered="true" toc="defau
Type-C/Type-D segment lt">
in the Reply Path TLV in the echo request, it converts that <name>Procedures for Building Reply Path TLV Dynamically</name>
Type-C/Type-D segment to <t>Let us consider the topology from <xref target="Topology_1"
Type-A based on its own SRGB. format="default"/>. Let us consider an SR Policy path built from
When ASBR4 receives the echo request, it should form this Reply Path TLV PE1 to PE4 with the following label stack: N-P1, N-ASBR1, EPE-ASBR1-AS
using its Node-SID (N-ASBR4) BR4,
and EPE-SID (EPE-ASRB4-ASBR1) labels and set the reply path return code to TBA1 N-PE4. PE1 begins traceroute procedures with the TTL set to 1 and incl
. udes
Then PE1 should use this Reply Path TLV in subsequent echo requests. [N-PE1] in the Reply Path TLV. The traceroute packet TTL expires on
In this example, when the subsequent echo request reaches P3, it should use P1, and P1 processes the traceroute as per the procedures described
this Reply Path TLV for sending the in <xref target="RFC8029" format="default"/> and <xref
echo reply. The same Reply Path TLV is sufficient for any router target="RFC8287" format="default"/>. P1 sends an echo reply with
in AS2 to send the reply. the same Reply Path TLV with the Reply Path Return Code set to 6.
Because the first label(N-ASBR4) can direct echo reply to ASBR4 The Return Code of the echo reply itself is set to the Return Code
and the second one (EPE-ASBR4-ASBR1) to direct as per <xref target="RFC8029" format="default"/> and <xref
echo reply to AS1. Once the echo reply reaches AS1, normal IP forwarding or the target="RFC8287" format="default"/>. This traceroute doesn't need
N-PE1 helps any changes to the Reply Path TLV until it leaves AS1. The same Reply
it to reach PE1.</t> Path TLV that is received may be included in the echo reply by P1
<t> The example described in the above paragraphs can be extended to multiple and P2, or no Reply Path TLV is included so that the head-end continue
ASes by following s to
the same procedure of each ASBR adding Node-SID and EPE-SID on receiving use the same return path in the echo request that it used to send
echo requests from the previous echo request.</t>
neighboring AS.</t>
<t>Let us consider a topology from <xref target="Topology_2"/>. <t>When ASBR1 receives the echo request, in the case it receives the
It consists of multiple IGP domains with multiple areas/levels or Type-C/Type-D segment in the Reply Path TLV in the echo request, it
separate IGP instances. converts that Type-C/Type-D segment to Type-A based on its own SRGB.
There is a single border node that separates the two domains. In this case, When ASBR4 receives the echo request, it should form this Reply Path
PE1 sends a traceroute packet with TTL set to 1 and includes N-PE1 in the TLV using its Node-SID (N-ASBR4) and EPE-SID (EPE-ASRB4-ASBR1)
Reply Path TLV. labels and set the Reply Path Return Code to 0x0006. Then, PE1 should
ABR1 receives the echo request and while sending the echo reply adds its use this Reply Path TLV in subsequent echo requests. In this
node Label example, when the subsequent echo request reaches P3, it should use
to the Reply Path TLV and sets the Reply path return code to TBA1. this Reply Path TLV for sending the echo reply. The same Reply Path
The Reply Path TLV TLV is sufficient for any router in AS2 to send the reply. This is
in the echo reply from ABR1 consists of [N-ABR1, N-PE1]. The next echo request because the first label (N-ASBR4) can direct the echo reply to ASBR4
with TTL 2 reaches the and the second one (EPE-ASBR4-ASBR1) can direct the echo reply to
P node. It is an internal node so it does not change the return Path. AS1. Once the echo reply reaches AS1, normal IP forwarding or the
The echo request with TTL 3 N-PE1 helps it to reach PE1.</t>
reaches 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]. echo request with TTL 4 reaches PE4 and it
sends an echo reply return code
as Egress. PE4 does not include any Reply Path TLV 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> <t>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>
</section> <t>Let us consider the topology from <xref target="Topology_2"
</section> 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, adds its node label
to the Reply Path TLV (while sending the echo reply), and sets
the Reply Path Return Code to 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, so
it does not change the return path. The echo request with a TTL of 3
reaches 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 wi
th a
TTL of 4 reaches PE4, and it sends an echo reply Return Code as an
egress. PE4 does not include any Reply Path 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> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Bruno Decraene"/> for 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 <contact fullname="Dongjie"/> for their care
ful
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>
<back> <section numbered="false" toc="default">
<references title='Normative References'> <name>Contributors</name>
&RFC8174;
&RFC2119;
&RFC8287;
&RFC8029;
&RFC7110;
</references> <contact fullname="Carlos Pignataro">
<references title='Informative References'> <organization>NC State University</organization>
&RFC3032; <address>
&RFC8403; <email>cpignata@gmail.com</email>
&RFC8402; </address>
&RFC8604; </contact>
&RFC7743;
&RFC8277;
&RFC8660;
&RFC9086;
&RFC9256;
&RFC9552;
&RFC7942;
&RFC9087;
&RFC9350;
<reference anchor='IEEE-802.1AE'>
<front>
<title> IEEE Standard for Local and metropolitan area networks–Media Acc
ess Control (MAC) Security</title>
<author>
<organization>
IEEE
</organization>
</author>
<date month="Aug" year="2023"/>
</front>
</reference>
</references> <contact fullname="Zafar Ali">
</back> <organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 131 change blocks. 
1222 lines changed or deleted 1194 lines changed or added

This html diff was produced by rfcdiff 1.48.