rfc9716.original   rfc9716.txt 
Routing area S. Hegde Internet Engineering Task Force (IETF) S. Hegde
Internet-Draft Juniper Networks Inc. Request for Comments: 9716 Juniper Networks, Inc.
Intended status: Standards Track K. Arora Category: Standards Track K. Arora
Expires: 28 December 2024 Individual Contributor ISSN: 2070-1721 Individual Contributor
M. Srivastava M. Srivastava
Juniper Networks Inc. Juniper Networks, Inc.
S. Ninan S. Ninan
Ciena Ciena
N. Kumar N. Kumar
Oracle Oracle
26 June 2024 February 2025
Path Monitoring System/Head-end based MPLS Ping and Traceroute in Inter- Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain
domain Segment Routing Networks Segment Routing Networks
draft-ietf-mpls-spring-inter-domain-oam-20
Abstract Abstract
The Segment Routing (SR) architecture leverages source routing and The Segment Routing (SR) architecture leverages source routing and
can be directly applied to the use of an MPLS data plane. An SR-MPLS can be directly applied to the use of an MPLS data plane. A Segment
network may consist of multiple IGP domains or multiple Autonomous Routing over MPLS (SR-MPLS) network may consist of multiple IGP
Systems (ASes) under the control of the same organization. It is domains or multiple Autonomous Systems (ASes) under the control of
useful to have the Label Switched Path (LSP) ping and traceroute the same organization. It is useful to have the Label Switched Path
procedures when an SR end-to-end path traverses multiple ASes or IGP (LSP) ping and traceroute procedures when an SR end-to-end path
domains. This document outlines mechanisms to enable efficient LSP traverses multiple ASes or IGP domains. This document outlines
ping and traceroute in inter-AS and inter-domain SR-MPLS networks mechanisms to enable efficient LSP ping and traceroute procedures in
through a straightforward extension to the Operations, inter-AS and inter-domain SR-MPLS networks. This is achieved through
Administration, and Maintenance (OAM) protocol, relying solely on a straightforward extension to the Operations, Administration, and
data plane forwarding for handling echo replies on transit nodes. Maintenance (OAM) protocol, relying solely on data plane forwarding
for handling echo replies on transit nodes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 28 December 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9716.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Definition of Domain . . . . . . . . . . . . . . . . . . 5 1.1. Definition of Domain
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language
2. Inter-domain Networks with Multiple IGPs . . . . . . . . . . 5 2. Inter-Domain Networks with Multiple IGPs
3. Reply Path TLV . . . . . . . . . . . . . . . . . . . . . . . 6 3. Reply Path TLV
4. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 7 4. Segment Sub-TLV
4.1. Type-A: SID only, in the form of MPLS Label . . . . . . . 7 4.1. Type-A: SID Only, in the Form of an MPLS Label
4.2. Type-C: IPv4 Node Address with Optional SID for 4.2. Type-C: IPv4 Node Address with an Optional SID for SR-MPLS
SR-MPLS . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Type-D: IPv6 Node Address with an Optional SID for SR-MPLS
4.3. Type D: IPv6 Node Address with Optional SID for SR 4.4. Segment Flags
MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Detailed Procedures
4.4. Segment Flags . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Sending an Echo Request
5. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 11 5.2. Receiving an Echo Request
5.1. Sending an Echo Request . . . . . . . . . . . . . . . . . 11 5.3. Sending an Echo Reply
5.2. Receiving an Echo Request . . . . . . . . . . . . . . . . 12 5.4. Receiving an Echo Reply
5.3. Sending an Echo Reply . . . . . . . . . . . . . . . . . . 12 5.5. Building a Reply Path TLV Dynamically
5.4. Receiving an Echo Reply . . . . . . . . . . . . . . . . . 13 5.5.1. Procedures to Build the Return Path
5.5. Building Reply Path TLV Dynamically . . . . . . . . . . . 13 6. Security Considerations
5.5.1. The Procedures to Build the Return Path . . . . . . . 14 7. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.1. Segment Sub-TLV
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.2. New Registry for Segment ID Sub-TLV Flags
7.1. Segment Sub-TLV . . . . . . . . . . . . . . . . . . . . . 16 7.3. Reply Path Return Codes Registry
7.2. New Registry for Segment Sub-TLV Flags . . . . . . . . . 16 8. References
7.3. Reply Path Return Codes Registry . . . . . . . . . . . . 17 8.1. Normative References
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Examples
9.1. Juniper Networks . . . . . . . . . . . . . . . . . . . . 18 A.1. Detailed Example
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 A.1.1. Procedures for Segment Routing LSP Ping
11. APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . 18 A.1.2. Procedures for SR LSP Traceroute
11.1. Detailed Example . . . . . . . . . . . . . . . . . . . . 19 A.1.3. Procedures for Building Reply Path TLV Dynamically
11.1.1. Procedures for Segment Routing LSP ping . . . . . . 19 Acknowledgments
11.1.2. Procedures for SR LSP traceroute . . . . . . . . . . 20 Contributors
11.1.3. Procedures for building Reply Path TLV Authors' Addresses
dynamically . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Many network deployments have built their networks consisting of Many network deployments have built their networks consisting of
multiple ASes either for the ease of operations or as a result of multiple ASes either for the ease of operations or as a result of
network mergers and acquisitions. SR can be deployed in such network mergers and acquisitions. SR can be deployed in such
scenarios to provide end-to-end paths, traversing multiple Autonomous scenarios to provide end-to-end paths, traversing multiple Autonomous
systems (ASes). Systems (ASes).
[RFC8660] specifies SR with an MPLS data plane. [RFC8402] describes [RFC8660] specifies SR with an MPLS data plane. [RFC8402] describes
BGP Peering Segments, and [RFC9087] describes Centralized BGP Egress BGP peering segments, and [RFC9087] describes centralized BGP Egress
Peer Engineering, which will help in steering packets from one AS to Peer Engineering, which will help in steering packets from one AS to
another. By utilizing these SR capabilities, it is possible to another. By utilizing these SR capabilities, it is possible to
create paths that span multiple ASes. create paths that span multiple ASes.
+----------------+ +----------------+
| Controller/PMS | | Controller/PMS |
+----------------+ +----------------+
|---AS1-----| |------AS2------| |----AS3---| |---AS1-----| |----AS2----| |----AS3---|
ASBR2----ASBR3 ASBR5------ASBR7 ASBR2----ASBR3 ASBR5------ASBR7
/ \ / \ / \ / \
/ \ / \ / \ / \
PE1----P1---P2 P3---P4---PE4 P5---P6--PE5 PE1----P1---P2 P3---P4---PE4 P5---P6--PE5
\ / \ / \ / \ /
\ / \ / \ / \ /
ASBR1----ASBR4 ASBR6------ASBR8 ASBR1----ASBR4 ASBR6------ASBR8
Autonomous System: AS1, AS2, AS3 Figure 1: Inter-AS Segment Routing Topology
Provider Edge: PE1, PE4, PE5
Provider: P1, P2, P3, P4, P5, P6
AS Boundary Router: ASBR1, ASBR2, ASBR3, ASBR4,
ASBR5, ASBR6, ASBR7, ASBR8
Figure 1: Inter-AS Segment Routing Topology Autonomous System: AS1, AS2, AS3
Provider Edge: PE1, PE4, PE5
Provider: P1, P2, P3, P4, P5, P6
Autonomous System Boundary Router: ASBR1, ASBR2, ASBR3, ASBR4,
ASBR5, ASBR6, ASBR7, ASBR8
For example, Figure 1 describes an inter-AS network scenario For example, Figure 1 describes an inter-AS network scenario
consisting of ASes AS1, AS2 and AS3. AS1, AS2, and AS3 are SR consisting of ASes AS1, AS2, and AS3. AS1, AS2, and AS3 are SR
enabled and the egress links have PeerNode SID/PeerAdj SID/ PeerSet enabled, and the egress links have the following Segment Identifiers
SID configured and advertised via [RFC9086]. PeerNode SID/PeerAdj (SIDs) configured and advertised via [RFC9086]: PeerNode SID, PeerAdj
SID/PeerSet SID are referred to as Egress Peer Engineering SIDs (EPE- SID, and PeerSet SID. The PeerNode SID, PeerAdj SID, and PeerSet SID
SIDs) in this document. The controller or the head-end can build an are referred to as Egress Peer Engineering SIDs (EPE-SIDs) in this
end-to-end Traffic-Engineered path consisting of Node-SIDs, document. The controller or the head-end can build an end-to-end
Adjacency-SIDs, and EPE-SIDs. It is useful for operators to be able traffic-engineered path consisting of Node-SIDs, Adjacency-SIDs, and
to perform LSP ping and traceroute procedures on these inter-AS SR- EPE-SIDs. It is useful for operators to be able to perform LSP ping
MPLS paths, to detect and diagnose failed deliveries and to determine and traceroute procedures on these inter-AS SR-MPLS paths, to detect
the actual path that traffic takes through the network. LSP ping/ and diagnose failed deliveries, and to determine the actual path that
traceroute procedures use IP connectivity for echo reply to reach the traffic takes through the network. LSP ping and traceroute
head-end. In inter-AS networks, IP connectivity may not be there procedures use IP connectivity for echo replies to reach the head-
from each router in the path. For example, in Figure 1, P3 and P4 end. In inter-AS networks, IP connectivity may not be there from
may not have IP connectivity for PE1. each router in the path. For example, in Figure 1, P3 and P4 may not
have IP connectivity for PE1.
It is not always possible to carry out LSP ping and traceroute It is not always possible to carry out LSP ping and traceroute
functionality on these paths to verify basic connectivity and fault functionality on these paths to verify basic connectivity and fault
isolation using existing LSP ping and traceroute mechanisms([RFC8287] isolation using existing LSP ping and traceroute mechanisms (see
and [RFC8029]). That is because there might not always be IP [RFC8287] and [RFC8029]). That is because there might not always be
connectivity from a responding node back to the source address of the IP connectivity from a responding node back to the source address of
ping packet when the responding node is in a different AS from the the ping packet when the responding node is in a different AS from
source of the ping. the source of the ping.
[RFC8403] describes mechanisms to carry out MPLS ping/traceroute from [RFC8403] describes mechanisms to carry out MPLS ping and traceroute
a Path Monitoring System (PMS). It is possible to build GRE tunnels from a Path Monitoring System (PMS). It is possible to build GRE
or static routes to each router in the network to get IP connectivity tunnels or static routes to each router in the network to get IP
for the reverse path. This mechanism is operationally very heavy and connectivity for the reverse path. This mechanism is operationally
requires the PMS to be capable of building a huge number of GRE very heavy and requires the PMS to be capable of building a huge
tunnels or installing the necessary static routes, which may not be number of GRE tunnels or installing the necessary static routes,
feasible. which may not be feasible.
[RFC7743] describes an Echo-relay based solution based on advertising [RFC7743] describes an Echo-relay-based solution that is predicated
a new Relay Node Address Stack TLV containing a stack of Echo-relay on advertising a new Relay Node Address Stack TLV containing a stack
IP addresses. These mechanisms can be applied to SR networks as of Echo-relay IP addresses. These mechanisms can be applied to SR
well. The [RFC7743] mechanism requires the return ping packet to be networks as well. The mechanism from [RFC7743] requires the return
processed on the slow path or as a bump-in-the-wire on every relay ping packet to be processed on the slow path or as a bump-in-the-wire
node. The motivation of the current document is to provide an on every relay node. The motivation of the current document is to
alternate mechanism for ping/traceroute in inter-domain SR networks. provide an alternate mechanism for ping and traceroute in inter-
The definition of the term "domain" as applicable to this document is domain SR networks. The definition of the term "domain" as
defined in Section 1.1. applicable to this document is defined in Section 1.1.
This document describes a new mechanism that is efficient and simple This document describes a new mechanism that is efficient and simple
and can be easily deployed in SR-MPLS networks. This mechanism uses and can be easily deployed in SR-MPLS networks. This mechanism uses
MPLS paths and no changes are required in the forwarding path. Any MPLS paths, and no changes are required in the forwarding path. Any
MPLS-capable node will be able to forward the echo-reply packet in MPLS-capable node will be able to forward the echo-reply packet in
the fast path. The current document describes a mechanism that uses the fast path. The current document describes a mechanism that uses
the Reply Path TLV [RFC7110] to convey the reverse path. Three new the Reply Path TLV [RFC7110] to convey the reverse path. Three new
sub-TLVs are defined for the Reply path TLV that facilitate encoding sub-TLVs are defined for the Reply Path TLV that facilitate encoding
SR label stack. The return path can either be derived by a smart 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- 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 end view of a section of the topology. This document also proposes
mechanisms to derive the return path dynamically during traceroute mechanisms to derive the return path dynamically during traceroute
procedures. procedures.
This document focuses on the inter-domain use case. The protocol This document focuses on the inter-domain use case. The protocol
extensions described may also indicate the return path for other use extensions described may also indicate the return path for other use
cases, which are outside the scope of this document and are not cases, which are outside the scope of this document and are not
further detailed here. The SRv6 data plane is also not covered in further detailed here. The SRv6 data plane is also not covered in
this document this document.
1.1. Definition of Domain 1.1. Definition of Domain
In this document, the term "domain" refers to an IGP domain where In this document, the term "domain" refers to an IGP domain where
every node is visible to every other node for the purpose of shortest every node is visible to every other node for the purpose of shortest
path computation, implying an IGP area or level. An Autonomous path computation, implying an IGP area or level. An Autonomous
System (AS) comprises one or more IGP domains. The procedures System (AS) comprises one or more IGP domains. The procedures
described herein are applicable to paths constructed across multiple described herein are applicable to paths constructed across multiple
domains, including both inter-area and inter-AS paths. These domains, including both inter-area and inter-AS paths. These
procedures and deployment scenarios are relevant for inter-AS paths procedures and deployment scenarios are relevant for inter-AS paths
where the participating ASes are under closely coordinating where the participating ASes are under closely coordinating
administrations or single ownership. This document pertains to SR- administrations or single ownership. This document pertains to SR-
MPLS networks where all nodes within each domain are SR-capable. It MPLS networks where all nodes within each domain are SR capable. It
also applies to SR-MPLS networks where SR functions as an overlay also applies to SR-MPLS networks where SR functions as an overlay
with SR-incapable underlay nodes. In such networks, the traceroute with SR-incapable underlay nodes. In such networks, the traceroute
procedure is executed only on the overlay SR nodes. procedure is executed only on the overlay SR nodes.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Inter-domain Networks with Multiple IGPs 2. Inter-Domain Networks with Multiple IGPs
When the network consists of a large number of nodes, the nodes are When the network consists of a large number of nodes, the nodes are
segregated into multiple IGP domains as shown in Figure 2. The segregated into multiple IGP domains as shown in Figure 2. The
connectivity to the remote PEs can be achieved using BGP-Labeled connectivity to the remote PEs can be achieved by BGP advertisements
Unicast (BGP-LU) [RFC8277] or by stacking the labels for each domain with an MPLS label bound to the prefix as described in [RFC8277] or
as described in [RFC8604]. by building paths using a list of segments as described in [RFC8604].
|-Domain 1|-------Domain 2-----|--Domain 3-| |-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
Figure 2: Inter-domain Networks with Multiple IGPs Figure 2: Inter-Domain Networks with Multiple IGPs
It is useful to support MPLS ping and traceroute mechanisms for these It is useful to support MPLS ping and traceroute mechanisms for these
networks. The procedures described in this document for constructing networks. The procedures described in this document for constructing
Reply Path TLV and its use in echo reply are equally applicable to the Reply Path TLV and its use in echo replies are equally applicable
networks consisting of multiple IGP domains that use BGP-LU or label to networks consisting of multiple IGP domains that use BGP-Labeled
stacking. Unicast (BGP-LU) or label stacking.
3. Reply Path TLV 3. Reply Path TLV
Reply Path (RP) TLV is defined in [RFC7110]. SR networks statically The Reply Path (RP) TLV is defined in [RFC7110]. SR networks
assign the labels to nodes and a PMS/head-end may know the entire statically assign the labels to nodes, and a PMS/head-end may know
Link State Database (LSDB) along with assigned SIDs. The reverse the entire Link State Database (LSDB) along with assigned SIDs. The
path can be built from the PMS/head-end by stacking segments for the reverse path can be built from the PMS/head-end by stacking segments
reverse path. Reply Path TLV as defined in [RFC7110] is used to for the reverse path. The Reply Path TLV as defined in [RFC7110] is
carry the return path. Reply mode 5, Reply via Specified Path is used to carry the return path. Reply Mode 5 (Reply via Specified
defined in section 4.1 of [RFC7110]. While using the procedures Path) is defined in Section 4.1 of [RFC7110]. While using the
described in this document, the reply mode is set to 5 (Reply via procedures described in this document, the Reply Mode is set to 5
Specified Path), and Reply Path TLV is included in the echo request (Reply via Specified Path), and the Reply Path TLV is included in the
message as described in [RFC7110]. The Reply Path TLV is constructed echo request message as described in [RFC7110]. The Reply Path TLV
as per Section 4.2 of [RFC7110]. This document defines three new is constructed as per Section 4.2 of [RFC7110]. This document
sub-TLVs to encode the SR path. defines three new sub-TLVs to encode the SR Path.
The type of segment that the head-end chooses to send in the Reply The type of segment that the head-end chooses to send in the Reply
Path TLV is governed by local policy. Implementations may provide Path TLV is governed by local policy. Implementations may provide
Command Line Interface (CLI) input parameters in the form of Labels/ Command Line Interface (CLI) input parameters in the form of labels,
IPv4 addresses/IPv6 addresses or a combination of these which get IPv4 addresses, IPv6 addresses, or a combination of these, which get
encoded in the Reply Path TLV. Implementations may also provide encoded in the Reply Path TLV. Implementations may also provide
mechanisms to acquire the LSDB of remote domains and compute the mechanisms to acquire the LSDB of remote domains and compute the
return path based on the acquired LSDB. For traceroute purposes, the return path based on the acquired LSDB. For traceroute purposes, the
return path will have to consider the reply being sent from every return path will have to consider the reply being sent from every
node along the path. The return path changes when the traceroute node along the path. The return path changes when the traceroute
progresses and crosses each domain. One of the ways this can be 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 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 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 path based on the knowledge of the LSDB. Another mechanism is to use
a dynamically computed return path as described in Section 5.5 a dynamically computed return path as described in Section 5.5.
Some networks may consist of IPv4-only domains and IPv6-only domains. 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 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 this document. It is recommended to use dual-stack in such cases and
use end-to-end IPv6 addresses for MPLS ping and traceroute use end-to-end IPv6 addresses for MPLS ping and traceroute
procedures. procedures.
4. Segment Sub-TLV 4. Segment Sub-TLV
Section 4 of [RFC9256] defines various segment types. The types of Section 4 of [RFC9256] defines various Segment Types. The types of
segments applicable to this document have been defined in this segments applicable to this document have been defined in this
section for the use of MPLS OAM. The intention was to keep the section for the use of MPLS OAM. The intention was to keep the
definitions as close to those in [RFC9256] as possible with definitions as close to those in [RFC9256] as possible, with
modifications only when needed. One or more Segment sub-TLVs can be 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 included in the Reply Path TLV. The Segment sub-TLVs included in a
Reply Path TLV MAY be of different types. Reply Path TLV MAY be of different types.
The below types of Segment sub-TLVs apply to the Reply Path TLV. The The below types of Segment sub-TLVs apply to the Reply Path TLV. The
code points for the sub-TLVs are taken from the IANA registry common code points for the sub-TLVs are taken from the IANA registry common
to TLVs 1, 16, and 21. This document defines the Type-A, Type-C, and to TLVs 1, 16, and 21. This document defines the usage and
Type-D Segment sub-TLVs usage and processing when it appears in TLV processing of the Type-A, Type-C, and Type-D Segment sub-TLVs when
21(Reply Path TLV). If these sub-TLVs appear in TLVs 1 or 16, they appear in TLV 21 (Reply Path TLV). If these sub-TLVs appear in
appropriate error codes MUST be returned as defined in [RFC8029]. TLVs 1 or 16, appropriate error codes MUST be returned as defined in
[RFC8029].
Type-A: SID only, in the form of MPLS Label Type-A: SID only, in the form of an MPLS label
Type-C: IPv4 Node Address with optional SID Type-C: IPv4 Node Address with an optional SID
Type-D: IPv6 Node Address with optional SID for SR MPLS Type-D: IPv6 Node Address with an optional SID for SR-MPLS
4.1. Type-A: SID only, in the form of MPLS Label 4.1. Type-A: SID Only, in the Form of an MPLS Label
The Type A Segment Sub-TLV encodes a single SID in the form of an The Type-A Segment sub-TLV encodes a single SID in the form of an
MPLS label. The format is as follows: MPLS label. The format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Type-A Segment Sub-TLV Figure 3: Type-A Segment Sub-TLV
where: Where:
Type: 2 octects. Carries value TBD1(to be assigned by IANA from the Type: 2 octets. Carries value 46 (assigned by IANA from the "Sub-
registry "Sub-TLVs for TLV Types 1, 16, and 21"). TLVs for TLV Types 1, 16, and 21" registry).
Length: 2 octets. Carries value 8. The length value excludes the Length: 2 octets. Carries value 8. The length value excludes the
length of the Type and Length Fields. length of the Type and Length fields.
Flags: 1 octet of flags as defined in Section 4.4. Flags: 1 octet of flags as defined in Section 4.4.
RESERVED: 3 octets of reserved bits. MUST be set to zero when RESERVED: 3 octets of reserved bits. MUST be set to zero when
sending; MUST be ignored on receipt. sending; MUST be ignored on receipt.
Label: 20 bits of label value. Label: 20 bits of label value.
TC: 3 bits of traffic class. If the originator wants the receiver to TC: 3 bits of Traffic Class (TC). If the originator wants the
choose the TC value, it MUST set the Traffic Class (TC) field to receiver to choose the TC value, it MUST set the TC field to zero.
zero.
S: 1 bit Reserved.The S bit MUST be zero upon transmission, and MUST S: 1 bit Reserved. The S bit MUST be zero upon transmission and
be ignored upon reception. MUST be ignored upon reception.
TTL: 1 octet of TTL. If the originator wants the receiver to choose TTL: 1 octet of TTL. If the originator wants the receiver to choose
the TTL value, it MUST set the TTL field to 255. the TTL value, it MUST set the TTL field to 255.
The label, TC, S, and TTL collectively referred to as SID. The labels, TC, S, and TTL are collectively referred to as a SID.
The following applies to the Type-A Segment sub-TLV: The following applies to the Type-A Segment sub-TLV:
The receiver MAY override the originator's values for these fields. The receiver MAY override the originator's values for these fields.
This would be determined by local policy at the receiver. One This would be determined by local policy at the receiver. One
possible policy would be to override the fields only if the fields possible policy would be to override the fields only if the fields
have the default values specified above. have the default values specified above.
4.2. Type-C: IPv4 Node Address with Optional SID for SR-MPLS 4.2. Type-C: IPv4 Node Address with an Optional SID for SR-MPLS
The Type-C Segment sub-TLV encodes an IPv4 node address, SR 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 Algorithm, and an optional SID in the form of an MPLS label. The
format is as follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED (MBZ) | SR Algorithm | | Flags | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) | | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Type-C Segment Sub-TLV Figure 4: Type-C Segment Sub-TLV
where: Where:
Type: TBD2 (to be assigned by IANA from the registry "Sub-TLVs for Type: 47 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16,
TLV Types 1, 16, and 21"). and 21" registry).
Length: 2 octets. Caries value 8 when no optional SID is included or Length: 2 octets. Carries value 8 when no optional SID is included
value 12 when optional SID is included. or value 12 when the optional SID is included.
Flags: 1 octet of flags as defined in Section 4.4. Flags: 1 octet of flags as defined in Section 4.4.
RESERVED: 2 octets of reserved bits. MUST be set to zero when RESERVED: 2 octets of reserved bits. MUST be set to zero when
sending; MUST be ignored on receipt. sending; MUST be ignored on receipt.
SR Algorithm: 1 octet specifying SR Algorithm as described in section SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4)
3.1.1 in [RFC8402] or Flexible algorithm as defined in [RFC9350], is present, this specifies the SR Algorithm as described in
when A-Flag as defined in Section 4.4 is present. SR Algorithm is Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in
used by the receiver to derive the Label. When A-flag is unset, this [RFC9350]. The SR Algorithm is used by the receiver to derive the
field has no meaning and thus MUST be set to zero on transmission and label. When the A-Flag is unset, this field has no meaning and
ignored on receipt. thus MUST be set to zero (MBZ) on transmission and ignored on
receipt.
IPv4 Node Address: 4-octet IPv4 address representing a node. The IPv4 Node Address: 4-octet IPv4 address representing a node. The
IPv4 Node Address MUST be present. It should be a stable address IPv4 Node Address MUST be present. It should be a stable address
belonging to the node (eg:loopback address). belonging to the node (e.g., loopback address).
SID: optional: 4-octet field containing label, TC, S and TTL as SID: Optional 4-octet field containing the labels TC, S, and TTL as
defined in Section 4.1. When the SID field is present, it MUST be defined in Section 4.1. When the SID field is present, it MUST be
used for constructing the Reply Path. used for constructing the Reply Path.
4.3. Type D: IPv6 Node Address with Optional SID for SR MPLS 4.3. Type-D: IPv6 Node Address with an Optional SID for SR-MPLS
The Type-D Segment sub-TLV encodes an IPv6 node address, SR Algorithm The Type-D Segment sub-TLV encodes an IPv6 Node Address, SR
and an optional SID in the form of an MPLS label. The format is as Algorithm, and an optional SID in the form of an MPLS label. The
follows: format is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED(MBZ) | SR Algorithm | | Flags | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // // IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) | | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Type-D Segment Sub-TLV Figure 5: Type-D Segment Sub-TLV
where: Where:
Type: TBD3 (to be assigned by IANA from the registry "Sub-TLVs for Type: 48 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16,
TLV Types 1, 16, and 21"). and 21" registry).
Length: 2 Octets. Caries value 20 when no optional SID is included Length: 2 octets. Carries value 20 when no optional SID is included
or value 24 when optional SID is included. or value 24 when the optional SID is included.
Flags: 1 octet of flags as defined in Section 4.4. Flags: 1 octet of flags as defined in Section 4.4.
RESERVED: 2-octets of reserved bits. MUST be set to zero when RESERVED: 2 octets of reserved bits. MUST be set to zero when
sending; MUST be ignored on receipt. sending; MUST be ignored on receipt.
SR Algorithm: 1 octet specifying SR-Algorithm as described in section SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4)
3.1.1 in [RFC8402] or Flexible algorithm as defined in [RFC9350], is present, this specifies the SR Algorithm as described in
when A-Flag as defined in Section 4.4 is present. SR-Algorithm is Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in
used by the receiver to derive the label. When A-flag is unset, this [RFC9350]. The SR Algorithm is used by the receiver to derive the
field has no meaning and thus MUST be set to zero (MBZ) on label. When the A-Flag is unset, this field has no meaning and
transmission and ignored on receipt. thus MUST be set to zero (MBZ) on transmission and ignored on
receipt.
IPv6 Node Address: 16-octet IPv6 address of one interface of a node. IPv6 Node Address: 16-octet IPv6 address of one interface of a node.
The IPv6 Node Address MUST be present. It should be a stable address The IPv6 Node Address MUST be present. It should be a stable
belonging to the node (eg:loopback address). address belonging to the node (e.g., loopback address).
SID: optional: 4-octet field containing label, TC, S and TTL as SID: Optional 4-octet field containing the labels TC, S, and TTL as
defined in Section 4.1. The SID is optional and specifies a 4-octet defined in Section 4.1. When the SID field is present, it MUST be
MPLS SID containing label, TC, S, and TTL as defined in Section 4.1. used for constructing the Reply Path.
When the SID field is present, it MUST be used for constructing the
Reply Path.
4.4. Segment Flags 4.4. Segment Flags
The Segment Types described above contain the following flags in the The Segment Types described above contain the following flags in the
"Flags" field (codes to be assigned by IANA from the new registry Flags field (codes assigned by IANA from the "Segment ID Sub-TLV
"Segment Sub-TLV Flags"): Flags" registry):
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| |A| | | | | | | | |A| | | | | | |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: Flags Figure 6: Flags
where: Where:
A-Flag: This flag indicates the presence of SR Algorithm ID in the A-Flag: This flag indicates the presence of an SR Algorithm ID in
"SR-Algorithm" field applicable to various segment Types. the SR Algorithm field applicable to various Segment Types.
Unused bits in the Flag octet MUST be set to zero upon transmission Unused bits in the Flag octet MUST be set to zero upon transmission
and MUST be ignored upon receipt. and MUST be ignored upon receipt.
The following applies to the Segment Flags: The following applies to the Segment Flags:
A-Flag applies to Segment Type-C and Type-D. If A-Flag appears with The A-Flag applies to Segment Type-C and Type-D. If the A-Flag
Type-A Segment Type, it MUST be ignored. appears with the Type-A Segment Type, it MUST be ignored.
5. Detailed Procedures 5. Detailed Procedures
This section uses the term "initiator" for the node that initiates This section uses the term "initiator" for the node that initiates
the MPLS ping or MPLS traceroute procedure. The term "responder" is the MPLS ping or the MPLS traceroute procedure. The term "responder"
used for the node that receives the echo request and sends the echo is used for the node that receives the echo request and sends the
reply. The term egress node is used to identify the last node where echo reply. The term "egress node" is used to identify the last node
the MPLS ping or traceroute is destined to. In an MPLS network any where the MPLS ping or traceroute is destined to. In an MPLS
node can be initiator or responder or egress. network, any node can be an initiator, responder, or egress.
5.1. Sending an Echo Request 5.1. Sending an Echo Request
In the inter-AS scenario, the procedures outlined in this document In the inter-AS scenario, the procedures outlined in this document
are employed to specify the return path when IP connectivity to the are employed to specify the return path when IP connectivity to the
initiator is unavailable. These procedures may also be utilized initiator is unavailable. These procedures may also be utilized
regardless of the availability of IP connectivity. The LSP ping regardless of the availability of IP connectivity. The LSP ping
initiator MUST set the Reply Mode of the echo request to 5 "Reply via initiator MUST set the Reply Mode of the echo request to 5 (Reply via
Specified Path", and a Reply Path TLV MUST be carried in the echo Specified Path), and a Reply Path TLV MUST be carried in the echo
request message correspondingly. The Reply Path TLV MUST contain the request message correspondingly. The Reply Path TLV MUST contain the
SR Path in the reverse direction encoded as an ordered list of SR Path in the reverse direction encoded as an ordered list of
segments. The first segment MUST correspond to the top segment in segments. The first segment MUST correspond to the top segment in
the MPLS header that the responder MUST use while sending the echo the MPLS header that the responder MUST use while sending the echo
reply. reply.
5.2. Receiving an Echo Request 5.2. Receiving an Echo Request
As described in [RFC7110], when Reply mode is set to 5 (Reply via As described in [RFC7110], when the Reply Mode is set to 5 (Reply via
Specified Path), the echo request must contain the Reply path TLV. Specified Path), the echo request must contain the Reply Path TLV.
Absence of Reply Path TLV is treated as a malformed echo request. The absence of the Reply Path TLV is treated as a malformed echo
When an echo request is received, if the responder does not support request. When an echo request is received, if the responder does not
the Reply Mode 5 defined in [RFC7110], an echo reply with the return support the Reply Mode 5 defined in [RFC7110], an echo reply with the
code set to "Malformed echo request received" and the Subcode set to Return Code set to "Malformed echo request received" and the Subcode
zero must be sent back to the initiator according to the rules of set to zero must be sent back to the initiator according to the rules
[RFC8029]. If the echo request message contains a malformed Segment of [RFC8029]. If the echo request message contains a malformed
sub-TLV, such as incorrect length field, an echo reply with return Segment sub-TLV, such as an incorrect length field, an echo reply
code set to "Malformed echo request received" and the Subcode set to must be sent back to the initiator with the Return Code set to
zero must be sent back to the initiator. "Malformed echo request received" and the Subcode set to zero.
When a Reply Path TLV is received, the responder that supports When a Reply Path TLV is received, the responder that supports
processing it, MUST use the segments in Reply Path TLV to build the processing it MUST use the segments in Reply Path TLV to build the
echo reply. The responder MUST follow the normal FEC validation echo reply. The responder MUST follow the normal Forwarding
procedures as described in [RFC8029] and [RFC8287] and this document Equivalence Class (FEC) validation procedures as described in
does not suggest any change to those procedures. When the echo reply [RFC8029] and [RFC8287] and this document does not suggest any change
has to be sent out the Reply Path TLV MUST be used to construct the to those procedures. When the echo reply has to be sent out, the
MPLS packet to send out. Reply Path TLV MUST be used to construct the MPLS packet to send out.
5.3. Sending an Echo Reply 5.3. Sending an Echo Reply
The echo reply message is sent as an MPLS packet with an MPLS label The echo reply message is sent as an MPLS packet with an MPLS label
stack. The echo reply message MUST be constructed as described in stack. The echo reply message MUST be constructed as described in
the [RFC8029]. An MPLS packet is constructed with an echo reply in [RFC8029]. An MPLS packet is constructed with an echo reply in the
the payload. The top label MUST be constructed from the first payload. The top label MUST be constructed from the first segment of
segment of the Reply Path TLV. The remaining labels MUST be the Reply Path TLV. The remaining labels MUST be constructed by
constructed by following the order of the segments from the Reply following the order of the segments from the Reply Path TLV. The
Path TLV. The MPLS header of the Echo Reply MUST be constructed from MPLS header of the echo reply MUST be constructed from the segments
the segments in Reply Path TLV and MUST NOT add any other label. The in the Reply Path TLV and MUST NOT add any other label. The S bit is
S bit is set for the bottom label as per MPLS specifications set for the bottom label as per the MPLS specifications [RFC3032].
[RFC3032] The responder MAY check the reachability of the top label The responder MAY check the reachability of the top label in its own
in its own Label Forwarding Information Base (LFIB) before sending Label Forwarding Information Base (LFIB) before sending the echo
the echo reply. If the top label is unreachable, the responder reply. If the top label is unreachable, the responder SHOULD send
SHOULD send the appropriate return code and follow procedures as per the appropriate Return Code and follow the procedures as per
section 5.2 of [RFC7110]. The exception case is when the responder Section 5.2 of [RFC7110]. The exception case is when the responder
does not have IP reachability to the originator, in which case it may does not have IP reachability to the originator, in which case, it
not be possible to send an Echo Reply at all. Even if sent (for may not be possible to send an echo reply at all. Even if sent (by
example by following a default route present on the responder), the following a default route present on the responder, for example), the
Echo Reply might not reach the originator. The node MAY provide echo reply might not reach the originator. The node MAY provide
necessary log information in case of unreachability. In certain necessary log information in case of unreachability. In certain
scenarios, the head-end MAY choose to send Type-C/Type-D segments scenarios, the head-end MAY choose to send Type-C/Type-D segments
consisting of IPv4 addresses or IPv6 addresses, when it is unable to consisting of IPv4 addresses or IPv6 addresses when it is unable to
derive the SID from available topology information. Optionally SID derive the SID from available topology information. Optionally, the
may also be associated with the Type-C/Type-D segment, if such SID may also be associated with the Type-C/Type-D segment, if such
information is available from the controller or via operator input. information is available from the controller or via operator input.
In such cases, the node sending the echo reply MUST derive the MPLS In such cases, the node sending the echo reply MUST derive the MPLS
labels based on Node-SIDs associated with the IPv4/IPv6 addresses. labels based on the Node-SIDs associated with the IPv4/IPv6
If optional MPLS SID is present in the Type-C/Type-D segments SID addresses. If an optional MPLS SID is present in the Type-C/Type-D
MUST be used to encode the echo reply with MPLS labels. If the MPLS segments, the SID MUST be used to encode the echo reply with MPLS
SID does not match with the IPv4 or IPv6 address field in the Type-C labels. If the MPLS SID does not match with the IPv4 or IPv6 address
or Type-D SID, log information should be generated. field in the Type-C or Type-D SID, log information should be
generated.
The reply path return code is set as described in section 7.4 of The Reply Path Return Code is set as described in Section 7.4 of
[RFC7110]. According to section 5.3 of [RFC7110], the Reply Path TLV [RFC7110]. According to Section 5.3 of [RFC7110], the Reply Path TLV
is included in an echo reply indicating the specified return path is included in an echo reply indicating the specified return path
that the echo reply message is required to follow. that the echo reply message is required to follow.
When the node is configured to dynamically create a return path for When the node is configured to dynamically create a return path for
the next echo request, the procedures described in Section 5.5 MUST the next echo request, the procedures described in Section 5.5 MUST
be used. The reply path return code MUST be set to TBA1 and the same be used. The Reply Path Return Code MUST be set to 0x0006, and the
Reply Path TLV or a new Reply Path TLV MUST be included in the echo same Reply Path TLV or a new Reply Path TLV MUST be included in the
reply. echo reply.
5.4. Receiving an Echo Reply 5.4. Receiving an Echo Reply
The rules and processes defined in Section 4.6 of [RFC8029] and The rules and processes defined in Section 4.6 of [RFC8029] and
Section 5.4 of [RFC7110] apply here. In addition, if the Reply Path Section 5.4 of [RFC7110] apply here. In addition, if the Reply Path
return code is "Use Reply Path TLV in the echo reply for building the Return Code is "Use Reply Path TLV from this echo reply for building
next echo request" (defined in this document), the Reply Path TLV the next echo request" (as defined in this document), the Reply Path
from the echo Reply MUST be sent in the next echo request with TTL TLV from the echo reply MUST be sent in the next echo request with
incremented by 1. If the initiator node does not support the return the TTL incremented by 1. If the initiator node does not support the
code "Use Reply Path TLV in the echo reply for building the next echo Return Code "Use Reply Path TLV from this echo reply for building the
request", log information should be generated indicating the return next echo request", log information should be generated indicating
code and the operator may choose to specify the return path the Return Code, and the operator may choose to specify the return
explicitly or use other mechanisms to verify the SR policy. If the path explicitly or use other mechanisms to verify the SR Policy. If
return code is TBA2, "Local policy does not allow dynamic Return Path the Return Code is 0x0007 "Local policy does not allow dynamic return
building", it indicates that the intermediate node does not support path building", it indicates that the intermediate node does not
building the dynamic return path. Log information should be support building the dynamic return path. Log information should be
generated on the initiator receiving this return code and the generated on the initiator receiving this Return Code, and the
operator may choose to specify the return path explicitly or use operator may choose to specify the return path explicitly or use
other mechanisms to verify the SR Policy. If the TTL is already 255, other mechanisms to verify the SR Policy. If the TTL is already 255,
the traceroute procedure MUST be ended with an appropriate log the traceroute procedure MUST be ended with an appropriate log
message. message.
5.5. Building Reply Path TLV Dynamically 5.5. Building a Reply Path TLV Dynamically
In some cases, the head-end may not have complete visibility of In some cases, the head-end may not have complete visibility of
Inter-AS/Inter-domain topology. In such cases, it can rely on inter-AS/inter-domain topology. In such cases, it can rely on
routers in the path to build the reverse path for MPLS traceroute routers in the path to build the reverse path for MPLS traceroute
procedures. For this purpose, the Reply Path TLV in the echo reply 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 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 request. A new Return Code "Use Reply Path TLV from this echo reply
building the next echo request" is defined in this document. for building the next echo request" is defined in this document.
Value Meaning +========+=========================================+
------ ---------------------- | Value | Meaning |
TBA1 Use Reply Path TLV in the echo reply +========+=========================================+
for building the next echo request. | 0x0006 | Use Reply Path TLV from this echo reply |
| | for building the next echo request |
+--------+-----------------------------------------+
5.5.1. The Procedures to Build the Return Path Table 1
To dynamically build the return Path for the traceroute procedures, 5.5.1. Procedures to Build the Return Path
To dynamically build the return path for the traceroute procedures,
the domain border nodes along the path being traced should support the domain border nodes along the path being traced should support
the procedures described in this section. Local policy on the domain the procedures described in this section. Local policy on the domain
border nodes should determine whether the domain border node border nodes should determine whether the domain border node
participates in building the return path dynamically during participates in building the return path dynamically during
traceroute. traceroute.
The head-end/PMS node may include its node label while initiating the The head-end/PMS node may include its node label while initiating the
traceroute procedure. When an Area Border Router (ABR) receives the traceroute procedure. When an Area Border Router (ABR) receives the
echo request, if the local policy implies building a dynamic return echo request, if the local policy implies building a dynamic return
path, ABR should include its Node label in the reply path TLV and path, the 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 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 the received echo request message, the ABR's node label is added
before the existing segments. The type of segment added is based on before the existing segments. The type of segment added is based on
local policy. In cases when SRGB is not uniform across the network local policy. In cases when the Segment Routing Global Block (SRGB)
which can be inferred from the LSDB, it is RECOMMENDED to add a is not uniform across the network, which can be inferred from the
Type-C or a Type-D segment, but implementations MAY safely use other LSDB, it is RECOMMENDED to add a Type-C or a Type-D segment.
approaches if they see benefits in doing so. If the existing segment However, implementations MAY safely use other approaches if they see
in the Reply Path TLV is a Type-C/Type-D segment, that segment should benefits in doing so. If the existing segment in the Reply Path TLV
be converted to a Type-A segment based on the ABR's own SRGB. This is a Type-C/Type-D segment, that segment should be converted to a
is because downstream nodes in the path will not know what SRGB to Type-A segment based on the ABR's own SRGB. This is because
use to translate the IP address to a label. As the ABR added its own downstream nodes in the path will not know what SRGB to use to
Node label, it is guaranteed that this ABR will be in the return path translate the IP address to a label. As the ABR added its own node
and will be forwarding the traffic based on the next label after its 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. label.
When an ASBR receives an echo request from another AS, and the ASBR When an ASBR receives an echo request from another AS, and the ASBR
is configured to build the return path dynamically, the ASBR should is configured to build the return path dynamically, the ASBR should
build a Reply Path TLV and include it in the echo reply. The Reply 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 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 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 Code of 0x0006 MUST be set in the echo reply to indicate that the
echo request MUST use the return Path from the Reply Path TLV in the next echo request MUST use the return path from the Reply Path TLV in
echo reply. ASBR should locally decide the outgoing interface for the echo reply. ASBR should locally decide the outgoing interface
the echo reply packet. Generally, remote ASBR will choose the for the echo reply packet. Generally, remote ASBR will choose the
interface on which the incoming OAM packet was received to send 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 echo reply out. In case the ASBR identifies multiple paths to reach
the initiator, it MUST choose to send one such path in the Reply Path the initiator, it MUST choose to send one such path in the Reply Path
TLV. Reply Path TLV is built by adding two segment sub TLVs. The TLV. The Reply Path TLV is built by adding two Segment sub-TLVs.
top segment sub TLV consists of the ASBR's Node SID and the second The top Segment sub-TLV consists of the ASBR's Node-SID, and the
segment consists of the EPE-SID in the reverse direction to reach the second segment consists of the EPE-SID in the reverse direction to
AS from which the OAM packet was received. The type of segment reach the AS from which the OAM packet was received. The type of
chosen to build Reply Path TLV is a local policy. It is recommended segment chosen to build the Reply Path TLV is a local policy. It is
to use the Type-C/Type-D segment for the top segment when the SRGB is recommended to use the Type-C/Type-D segment for the top segment when
not guaranteed to be uniform in the domain. the SRGB is not guaranteed to be uniform in the domain.
Irrespective of which type of segment is included in the Reply Path Irrespective of which type of segment is included in the Reply Path
TLV, the responder to the echo requests MUST always translate the 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 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 reply packet. This procedure can be applied to an end-to-end path
consisting of multiple ASes. Each ASBR that receives an echo request 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 from another AS adds its Node-SID and EPE-SID on top of the existing
segments in the Reply Path TLV. segments in the Reply Path TLV.
An ASBR that receives the echo request from a neighbor belonging to 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 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, 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 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 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 Return Code to 0x0006 and send the newly constructed Reply Path TLV
the echo reply. in the echo reply.
Internal nodes or non-domain border nodes might not set the Reply Internal nodes or non-domain border nodes might not set the Reply
Path TLV return code to TBA1 in the echo reply message as there is no Path TLV Return Code to 0x0006 in the echo reply message as there is
change in the return Path. In these cases, the head-end node/PMS no change in the return path. In these cases, the head-end node/PMS
that initiates the traceroute procedure MUST continue to send the that initiates the traceroute procedure MUST continue to send the
previously sent Reply Path TLV in the echo request message in every previously sent Reply Path TLV in the echo request message in every
subsequent echo request. subsequent echo request.
Note that an ASBR's local policy may prohibit it from participating Note that an ASBR's local policy may prohibit it from participating
in the dynamic traceroute procedures. If such an ASBR is encountered in the dynamic traceroute procedures. If such an ASBR is encountered
in the forward path, dynamic return path-building procedures will in the forward path, dynamic return path building procedures will
fail. In such cases, an ASBR that supports this document MUST set fail. In such cases, an ASBR that supports this document MUST set
the return code TBA2 to indicate local policies do not allow the the Return Code to 0x0007 to indicate that local policies do not
dynamic return path building. allow the dynamic return path building.
Value Meaning +========+==========================================================+
------ --------------------------------------------------- | Value | Meaning |
TBA2 Local policy does not allow dynamic Return Path +========+==========================================================+
building. | 0x0007 | Local policy does not allow |
| | dynamic return path building |
+--------+----------------------------------------------------------+
Table 2
6. Security Considerations 6. Security Considerations
The procedures described in this document enable LSP ping and The procedures described in this document enable LSP ping and
traceroute to be executed across multiple IGP domains or multiple traceroute procedures to be executed across multiple IGP domains or
ASes that belong to the same administration or closely cooperating multiple ASes that belong to the same administration or closely
administrations. It is assumed that sharing domain internal cooperating administrations. It is assumed that sharing domain
information across such domains does not pose a security risk. internal information across such domains does not pose a security
However, procedures described in this document may be used by an risk. However, the procedures described in this document may be used
attacker to extract the domain's internal information. An operator by an attacker to extract the domain's internal information. An
MUST deploy appropriate filter policies as described in [RFC8029] to operator MUST deploy appropriate filter policies as described in
restrict the LSP ping/traceroute packets based on origin. It is also [RFC8029] to restrict the LSP ping and traceroute packets based on
RECOMMENDED that an operator deploy security mechanisms such as origin. It is also RECOMMENDED that an operator deploy security
MACsec [IEEE-802.1AE] on inter-domain links or security-vulnerable mechanisms such as Media Access Control Security (MACsec)
links to prevent spoofing attacks. [IEEE-802.1AE] on inter-domain links or security-vulnerable links to
prevent spoofing attacks.
All the security considerations defined in [RFC8029] will be All the security considerations defined in [RFC8029] will be
applicable for this document. Appropriate filter policies SHOULD be applicable for this document. Appropriate filter policies SHOULD be
applied at the edges to prevent attackers from getting into the applied at the edges to prevent attackers from getting into the
network. In the event of such a security breach, the network devices network. In the event of such a security breach, the network devices
MUST have mechanisms to prevent Denial-of-service attacks as MUST have mechanisms to prevent denial-of-service attacks as
described in [RFC8029]. described in [RFC8029].
7. IANA Considerations 7. IANA Considerations
7.1. Segment Sub-TLV 7.1. Segment Sub-TLV
IANA should assign three new sub-TLVs from the "sub-TLVs for TLV IANA has assigned three new sub-TLVs from the "Sub-TLVs for TLV Types
Types 1, 16, and 21" sub-registry of the "Multiprotocol Label 1, 16, and 21" registry of the "Multiprotocol Label Switching (MPLS)
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" Label Switched Paths (LSPs) Ping Parameters" registry group.
registry.
Sub-Type Sub-TLV Name Reference +==========+=====================================+=============+
-------- ----------------- ------------ | Sub-Type | Sub-TLV Name | Reference |
TBD1 SID only in the form of MPLS Section 4.1 +==========+=====================================+=============+
label of this document | 46 | SID only, in the form of MPLS label | Section 4.1 |
TBD2 IPv4 Node Address with Section 4.2 | | | of RFC 9716 |
optional SID for SR-MPLS of this document +----------+-------------------------------------+-------------+
TBD3 IPv6 Node Address with Section 4.3 | 47 | IPv4 Node Address with an optional | Section 4.2 |
optional SID for SR-MPLS of this document | | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+
| 48 | IPv6 Node Address with an optional | Section 4.3 |
| | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+
The allocation of code points for the segment sub-TLVs should be done Table 3
from the Standards Action range (0-16383)
7.2. New Registry for Segment Sub-TLV Flags The code points for the Segment sub-TLVs have been registered in the
Standards Action range (0-16383).
IANA should create a new "Segment ID Sub-TLV flags" (see 7.2. New Registry for Segment ID Sub-TLV Flags
Section Section 4.4) registry under the "Multiprotocol Label
Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" IANA has created a new "Segment ID Sub-TLV Flags" registry (see
registry. Section 4.4) under the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry group.
This registry tracks the assignment of 8 flags in the Segment ID sub- This registry tracks the assignment of 8 flags in the Segment ID sub-
TLV flags field. The flags are numbered from 0 (most significant TLV flags field. The flags are numbered from 0 (the most significant
bit, transmitted first) to 7. bit and transmitted first) to 7.
New entries are assigned by Standards Action. Initial entries in the New entries are assigned by Standards Action. Initial entries in the
registry are as follows: registry are as follows:
Bit number | Name | Reference +============+========+=========================+
------------+----------------------------+-------------- | Bit Number | Name | Reference |
1 | A Flag | Section 4.4 +============+========+=========================+
| | of this document | 1 | A-Flag | Section 4.4 of RFC 9716 |
+------------+--------+-------------------------+
Table 4
7.3. Reply Path Return Codes Registry 7.3. Reply Path Return Codes Registry
IANA should assign new return codes in the "Reply path return codes" IANA has assigned new Return Codes in the "Reply Path Return Codes"
registry under the "Multiprotocol Label Switching (MPLS) Label registry under the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry. Switched Paths (LSPs) Ping Parameters" registry group.
Value Meaning Reference +========+=========================================+===========+
-------- ----------------- ------------ | Value | Meaning | Reference |
TBA1 Use Reply Path TLV This document +========+=========================================+===========+
from this echo reply | 0x0006 | Use Reply Path TLV from this echo reply | RFC 9716 |
for building next | | for building the next echo request | |
echo request. +--------+-----------------------------------------+-----------+
| 0x0007 | Local policy does not allow dynamic | RFC 9716 |
| | return path building | |
+--------+-----------------------------------------+-----------+
TBA2 Local policy does This document Table 5
not allow dynamic
return Path building.
The return codes should be assigned from the Standards Action range The Return Codes have been assigned in the Standards Action range
(0x0000-0xFFFB). (0x0000-0xFFFB).
8. Contributors 8. References
Carlos Pignataro 8.1. Normative References
NC State University [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
cpignata@gmail.com [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
Zafar Ali [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
Cisco Systems, Inc. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
zali@cisco.com [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
9. Implementation Status 8.2. Informative References
This section is to be removed before publishing as an RFC. [IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security", IEEE Std
8021.AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December
2018, <https://ieeexplore.ieee.org/document/8585421>.
RFC-Editor: Please clean up the references cited by this section [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
before publication. Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
This section records the status of known implementations of the [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G.
protocol defined by this specification at the time of posting of this Swallow, Ed., "Relayed Echo Reply Mechanism for Label
Internet-Draft, and is based on a proposal described in [RFC7942]. Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743,
The description of implementations in this section is intended to January 2016, <https://www.rfc-editor.org/info/rfc7743>.
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.
9.1. Juniper Networks [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
Organization: Juniper Networks [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Implementation: JUNOS. [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
Description: Implementation for sending Return path TLV with Type-A [RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed.,
segment subTLV Henderickx, W., and D. Cooper, "Interconnecting Millions
of Endpoints with Segment Routing", RFC 8604,
DOI 10.17487/RFC8604, June 2019,
<https://www.rfc-editor.org/info/rfc8604>.
Maturity Level: Prototype [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
Coverage: Partial. Type-A SIDs in Return Path TLV [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K.,
Ray, S., and J. Dong, "Border Gateway Protocol - Link
State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
2021, <https://www.rfc-editor.org/info/rfc9086>.
Contact: shraddha@juniper.net [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
10. Acknowledgments [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
Thanks to Bruno Decraene for suggesting the use of generic Segment [RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
sub-TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody, and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
Dongjie, for careful review and comments. Thanks to Mach Chen for DOI 10.17487/RFC9350, February 2023,
suggesting the use of Reply Path TLV. Thanks to Gregory Mirsky for <https://www.rfc-editor.org/info/rfc9350>.
the detailed review which helped improve the readability of the
document to a great extent.
11. APPENDIX [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
Appendix A. Examples
This section elaborates examples of the inter-domain ping and This section elaborates examples of the inter-domain ping and
Traceroute procedures described in this document. traceroute procedures described in this document.
11.1. Detailed Example A.1. Detailed Example
The example topology given in Figure 1 will be used in the below The example topology given in Figure 1 will be used in the below
sections to explain LSP ping and traceroute procedures. The PMS/ sections to explain LSP ping and traceroute procedures. The PMS/
head-end has a complete view of the topology. PE1, P1, P2, ASBR1, 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 and ASBR2 are in AS1. Similarly, ASBR3, ASBR4, P3, P4, and PE4 are
in AS2. in AS2.
AS1 and AS2 have SR enabled. IGPs like OSPF/ISIS are used to flood AS1 and AS2 have SR enabled. IGPs like OSPF/IS-IS are used to flood
SIDs in each AS. The ASBR1, ASBR2, ASBR3,and ASBR4 advertise BGP SIDs in each AS. ASBR1, ASBR2, ASBR3, and ASBR4 advertise BGP EPE-
EPE-SIDs for the inter-AS links. Topology of AS1 and AS2 are 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- advertised via BGP - Link State (BGP-LS) to the controller, PMS, or
end node. The EPE-SIDs are also advertised via BGP-LS as described head-end node. The EPE-SIDs are also advertised via BGP-LS as
in [RFC9086]. The example uses EPE-SIDs for the inter-AS links but described in [RFC9086]. The example uses EPE-SIDs for the inter-AS
the same could be achieved using adjacency-SIDs advertised for a links, but the same could be achieved using Adjacency-SIDs advertised
passive IGP link. for a passive IGP link.
The description in the document uses below notations for Segment The description in this document uses the notations below for SIDs.
Identifiers (SIDs).
Node-SIDs: N-PE1, N-P1, N-ASBR1 etc. Node-SIDs: N-PE1, N-P1, N-ASBR1, etc.
Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2 etc. Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2, etc.
EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2 etc. EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2, etc.
11.1.1. Procedures for Segment Routing LSP ping A.1.1. Procedures for Segment Routing LSP Ping
Consider an SR-MPLS path from PE1 to PE4 consisting of a label stack Consider an SR-MPLS path from PE1 to PE4 consisting of a label stack
[N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from Figure 1. In order to [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from Figure 1. In order to
perform MPLS ping procedures on this path, the remote end (PE4) needs 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 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 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 path, there may be no IP connectivity from PE4 to PE1 as they lie in
different ASes. different ASes.
PE1 sends an echo request message to the endpoint PE4 along the path PE1 sends an echo request message to the endpoint PE4 along the path
that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, that consists of label stacks [N-P1, N-ASBR1, EPE-ASBR1-ASBR4,
N-PE4]. PE1 adds the return path from PE4 to PE1 in the echo request N-PE4]. PE1 adds the return path from PE4 to PE1 in the echo request
message in the Reply Path TLV. As an example, the Reply Path TLV for message in the Reply Path TLV. As an example, the Reply Path TLV for
PE1 to PE4 for LSP ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This 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 example path provides the entire return path up to the head-end node
PE1. The mechanism used to construct the return path is PE1. The mechanism used to construct the return path is
implementation-dependent. implementation dependent.
An implementation may also build a return Path consisting of labels An implementation may also build a return path consisting of labels
to reach its own AS. Once the label stack is popped off, the echo to reach its own AS. Once the label stack is popped off, the echo
reply message will be exposed. The further packet forwarding will be reply message will be exposed. The further packet forwarding will be
based on IP lookup. An example return Path for this case could be based on IP lookup. An example return path for this case could be
[N-ASBR4, EPE-ASBR4-ASBR1]. [N-ASBR4, EPE-ASBR4-ASBR1].
On receiving an MPLS echo request, PE4 first validates FEC in the On receiving an MPLS echo request, PE4 first validates the FEC in the
echo request. PE4 then builds a label stack to send the response echo request. PE4 then builds a label stack to send the response
from PE4 to PE1 by copying the labels from the Reply Path TLV. PE4 from PE4 to PE1 by copying the labels from the Reply Path TLV. PE4
builds the echo reply packet with the MPLS label stack constructed builds the echo reply packet with the MPLS label stack constructed,
and imposes MPLS headers on top of the echo reply packet and sends imposes MPLS headers on top of the echo reply packet, and sends out
out the packet to PE1. This segment List stack can successfully the packet to PE1. This segment list stack can successfully steer
steer the reply back to the head-end node (PE1). the reply back to the head-end node (PE1).
Let us consider a case when P3 node does not have a route to reach Let us consider a case when the P3 node does not have a route to
N-PE4. On P3 ping packet would be dropped and the head-end node reach N-PE4. On P3, a ping packet would be dropped, and the head-end
(PE1) will not receive Echo Reply indicating failure. node (PE1) will not receive an echo reply indicating failure.
11.1.2. Procedures for SR LSP traceroute A.1.2. Procedures for SR LSP Traceroute
11.1.2.1. Procedures for SR LSP traceroute with the Same SRGB on All A.1.2.1. Procedures for SR LSP Traceroute with the Same SRGB on All
Nodes Nodes
The traceroute procedure involves visiting every node on the path and The traceroute procedure involves visiting every node on the path and
obtaining echo replies from every node. In this section, we describe obtaining echo replies from every node. In this section, we describe
the traceroute mechanisms when the head-end/PMS has complete the traceroute mechanisms when the head-end/PMS has complete
visibility of the LSDB. The head-end/PMS computes the return path 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. from each node in the entire SR-MPLS path that is being tracerouted.
The return path computation is implementation-dependent. As the The return path computation is implementation dependent. As the
head-end/PMS completely controls the return path, it can use head-end/PMS completely controls the return path, it can use
proprietary computations to build the return path. proprietary computations to build the return path.
One of the ways the return path can be built is to use the principle 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 of building label stacks by adding each domain border node's Node-SID
on the return path label stack as the traceroute progresses. For on the return path label stack as the traceroute progresses. For
inter-AS networks, in addition to the border node's Node-SID, EPE-SID inter-AS networks, in addition to the border node's Node-SID, the
in the reverse direction also needs to be added to the label stack. EPE-SID in the reverse direction also needs to be added to the label
stack.
The Inter-domain/inter-AS traceroute procedure uses the TTL expiry The inter-domain/inter-AS traceroute procedure uses the TTL expiry
mechanism as specified in [RFC8029] and [RFC8287]. Every echo mechanism as specified in [RFC8029] and [RFC8287]. Every echo
request packet head-end/PMS will include the appropriate return path request packet head-end/PMS will include the appropriate return path
in the Reply Path TLV. The node that receives the echo request will in the Reply Path TLV. The node that receives the echo request will
follow procedures described in Section 5.1 and Section 5.2 to send follow procedures described in Sections 5.1 and 5.2 to send out an
out an echo reply. echo reply.
For Example: For example:
Let us consider a topology from Figure 1. Let us consider an SR-MPLS Let us consider the topology from Figure 1. Let us consider an SR-
path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. The traceroute is 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 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 the first echo request with the TTL set to 1 and includes a Reply
TLV consisting of a Type-A segment containing a label derived from Path TLV consisting of a Type-A segment containing a label derived
its own SR Global Block (SRGB). Note that the type of segment used from its own SRGB. Note that the type of segment used in
in constructing the return Path is determined by local policy. If constructing the return path is determined by local policy. If the
the entire network has the same SRGB configured, Type-A segments can entire network has the same SRGB configured, Type-A segments can be
be used. The TTL expires on P1 and P1 sends an echo reply using the used. The TTL expires on P1, and P1 sends an echo reply using the
return path. Note that implementations may choose to exclude the return path. Note that implementations may choose to exclude the
Reply Path TLV until the traceroute reaches the first domain border 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 as the return IP path to PE1 is expected to be available inside the
first domain. first domain.
The TTL is set to 2 and the next the echo request is sent out. Until The TTL is set to 2, and the next echo request is sent out. Until
the traceroute procedure reaches the domain border node ASBR1, the the traceroute procedure reaches the domain border node ASBR1, the
same return path TLV consisting of a single Label (PE1's node Label) 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 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 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 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 node has complete visibility of the network LSDB learned via BGP-LS
[RFC9552] and [RFC9086] and can derive the details of Autonomous (see [RFC9552] and [RFC9086]) and can derive the details of ASBR
System Boundary Router (ASBR) nodes. The Reply Path TLV is built nodes. The Reply Path TLV is built based on the forward path. As
based on the forward path. As the forward path consists of EPE- the forward path consists of EPE-ASBR1-ASBR4, an EPE-SID in the
ASBR1-ASBR4, an EPE-SID in the reverse direction is included in the reverse direction is included in the Reply Path TLV. The return path
Reply Path TLV. The return path now consists of two labels [EPE- now consists of two labels: [EPE-ASBR4-ASBR1, N-PE1]. The echo reply
ASBR4-ASBR1, N-PE1]. The echo reply from ASBR4 will use this return from ASBR4 will use this return path to send the reply.
path to send the reply.
The next echo request after visiting the border node ASBR4 will After visiting the border node ASBR4, the next echo request will
update the return path with the Node-SID label of ASBR4. The return 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 path beyond ASBR4 will be [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This
same return path is used until the traceroute procedure reaches the same return path is used until the traceroute procedure reaches the
next set of border nodes. When there are multiple ASes the next set of border nodes. When there are multiple ASes, the
traceroute procedure will continue by adding a set of Node-SIDs and traceroute procedure will continue by adding a set of Node-SIDs and
EPE-SIDs as the border nodes are visited. EPE-SIDs as the border nodes are visited.
Note that the above return path-building procedure requires the LSDB Note that the above return path building procedure requires the LSDB
of all the domains to be available at the head-end/PMS. of all the domains to be available at the head-end/PMS.
Let us consider a case when P3 node does not have a route to reach Let us consider a case when the P3 node does not have a route to
N-PE4. When TTL of the packet is 5, the packet reaches P3 and the reach N-PE4. When the TTL of the packet is 5, the packet reaches P3,
packet TTL becomes zero and the packet is sent to the control plane. its TTL becomes zero, and it is sent to the control plane. The FEC
The FEC validation Procedures are executed and the Echo Reply is sent validation procedures are executed, and the echo reply is sent using
using the labels in Reply Path TLV which is [N-PE1, EPE-ASBR4-ASBR1, the labels in the Reply Path TLV, which is [N-PE1, EPE-ASBR4-ASBR1,
N-ASBR4]. Head-end PE1 increases the TTL to 6 and sends next Echo N-ASBR4]. The head-end PE1 increases the TTL to 6 and sends the next
Request. The packet is dropped at P3 as there is no route on P3 to echo request. The packet is dropped at P3 as there is no route on P3
forward to N-PE4. Traceroute identifies the path [N-P1, N-ASBR1, to forward to N-PE4. The traceroute identifies that the path [N-P1,
EPE-ASBR1-ASBR4, N-PE4] is broken at P3. N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at P3.
11.1.2.2. Procedures for SR LSP Traceroute with the Different SRGBs A.1.2.2. Procedures for SR LSP Traceroute with Different SRGBs
Section 11.1.2.1 assumes the same SRGB is configured on all nodes Appendix A.1.2.1 assumes the same SRGB is configured on all nodes
along the path. The SRGB may differ from one node to another node along the path. The SRGB may differ from one node to another node,
and the SR architecture [RFC8402] allows the nodes to use different and the SR architecture [RFC8402] allows the nodes to use different
SRGBs. In such scenarios, PE1 finds out the difference in SRGB by SRGBs. In such scenarios, PE1 finds out the difference in the SRGB
looking into the LSDB and sends Type-C (or Type-D in the case of IPv6 by looking into the LSDB. Then, it sends the Type-C segment (or the
networks) segment with the node address of PE1 and with optional MPLS Type-D segment, in the case of IPv6 networks) with the node address
SID associated with the node address. The receiving node derives the of PE1 and with an optional MPLS SID associated with the node
label for the return path based on its own SRGB. When the traceroute address. The receiving node derives the label for the return path
procedure crosses the border ASBR1, head-end PE1 should send a Type-A based on its own SRGB. When the traceroute procedure crosses the
segment for N-PE1 based on the label derived from ASBR1's SRGB. This border ASBR1, head-end PE1 should send a Type-A segment for N-PE1
is required because, ASBR4, P3, P4, etc. may not have the topology based on the label derived from ASBR1's SRGB. This is required
information to derive SRGB for PE1. After the traceroute procedure because ASBR4, P3, P4, etc. may not have the topology information to
reaches ASBR4 the return path will be [N-PE1 (Type-A with label based derive SRGB for PE1. After the traceroute procedure reaches ASBR4,
on ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASBR4 (Type-C)]. the return path will be [N-PE1 (Type-A with the label based on
ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASBR4 (Type-C)].
If the packet needs to follow return path specific to an algorithm If the packet needs to follow a return path specific to an algorithm
(as defined in [RFC9350]), a Type-C Segment sub-TLV with (as defined in [RFC9350]), a Type-C Segment sub-TLV with a
corresponding algorithm field set should be used. A-flag should be corresponding algorithm field set should be used. The A-Flag should
set to indicate that the SID corresponding to the algorithm should be be set to indicate that the SID corresponding to the algorithm should
used. be used.
To extend the example to 3 or more ASes, let us consider a traceroute To extend the example to three or more ASes, let us consider a
from PE1 to PE5 in Figure 1. In this example, the PE1 to PE5 path traceroute from PE1 to PE5 in Figure 1. In this example, the PE1 to
has to cross 3 domains AS1, AS2, and AS3. Let us consider a path PE5 path has to cross three domains: AS1, AS2, and AS3. Let us
from PE1 to PE5 that goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, consider a path from PE1 to PE5 that goes through [PE1, ASBR1, ASBR4,
PE5]. When the traceroute procedure is visiting the nodes in AS1, ASBR6, ASBR8, PE5]. When the traceroute procedure is visiting the
the Reply Path TLV sent from the head-end consists of [N-PE1]. When nodes in AS1, the Reply Path TLV sent from the head-end consists of
the traceroute procedure reaches the ASBR4, the return Path consists [N-PE1]. When the traceroute procedure reaches the ASBR4, the return
of [N-PE1, EPE-ASBR4-ASBR1]. While visiting nodes in AS2, the path consists of [N-PE1, EPE-ASBR4-ASBR1]. While visiting nodes in
traceroute procedure consists of Reply Path TLV [N-PE1, EPE- AS2, the traceroute procedure consists of the Reply Path TLV [N-PE1,
ASBR4-ASBR1, N-ASBR4]. Similarly, while visiting ASBR8, the EPE-SID EPE-ASBR4-ASBR1, N-ASBR4]. Similarly, while visiting ASBR8, the EPE-
from ASBR8 to ASBR6 is added to the Reply Path TLV. While visiting SID from ASBR8 to ASBR6 is added to the Reply Path TLV. While
nodes in AS3, the Node-SID of ASBR8 would also be added which makes visiting nodes in AS3, the Node-SID of ASBR8 would also be added,
the return Path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE-ASBR8-ASBR6, which makes the return path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE-
N-ASBR8] ASBR8-ASBR6, N-ASBR8].
Let us consider another example from topology Figure 2. This
Let us consider another example from the topology in Figure 2. This
topology consists of multi-domain IGP with a common border node topology consists of multi-domain IGP with a common border node
between the domains. This could be achieved with multi-area or between the domains. This could be achieved with multi-area or
multi-level IGP or multiple instances of IGP deployed on the same multi-level IGP or with multiple instances of IGP deployed on the
node. The return path computation for this topology is similar to same node. The return path computation for this topology is similar
the multi-AS computation except that the return path consists of a to multi-AS computation, except that the return path consists of a
single border node label. single border node label.
11.1.3. Procedures for building Reply Path TLV dynamically A.1.3. Procedures for Building Reply Path TLV Dynamically
Let us consider a topology from Figure 1. Let us consider an SR Let us consider the topology from Figure 1. Let us consider an SR
policy path built from PE1 to PE4 with the label stack, N-P1, Policy path built from PE1 to PE4 with the following label stack:
N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute with the TTL N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute
set to 1 and includes [N-PE1] in the Reply Path TLV. The traceroute procedures with the TTL set to 1 and includes [N-PE1] in the Reply
packet TTL expires on P1 and P1 processes the traceroute as per the Path TLV. The traceroute packet TTL expires on P1, and P1 processes
procedures described in [RFC8029] and [RFC8287]. P1 sends an echo the traceroute as per the procedures described in [RFC8029] and
reply with the same Reply Path TLV with the reply path return code [RFC8287]. P1 sends an echo reply with the same Reply Path TLV with
set to 6. The return code of the echo reply itself is set to the the Reply Path Return Code set to 6. The Return Code of the echo
return code as per [RFC8029] and [RFC8287]. This traceroute doesn't reply itself is set to the Return Code as per [RFC8029] and
need any changes to the Reply Path TLV till it leaves AS1. The same [RFC8287]. This traceroute doesn't need any changes to the Reply
Reply Path TLV that is received may be included in the echo reply by Path TLV until it leaves AS1. The same Reply Path TLV that is
P1 and P2 or no Reply Path TLV included so that head-end continues to received may be included in the echo reply by P1 and P2, or no Reply
use the same return path in the echo request that it used to send the Path TLV is included so that the head-end continues to use the same
previous echo request. return path in the echo request that it used to send the previous
echo request.
When ASBR1 receives the echo request, in the case it receives the When ASBR1 receives the echo request, in the case it receives the
Type-C/Type-D segment in the Reply Path TLV in the echo request, it Type-C/Type-D segment in the Reply Path TLV in the echo request, it
converts that Type-C/Type-D segment to Type-A based on its own SRGB. converts that Type-C/Type-D segment to Type-A based on its own SRGB.
When ASBR4 receives the echo request, it should form this Reply Path When ASBR4 receives the echo request, it should form this Reply Path
TLV using its Node-SID (N-ASBR4) and EPE-SID (EPE-ASRB4-ASBR1) labels TLV using its Node-SID (N-ASBR4) and EPE-SID (EPE-ASRB4-ASBR1) labels
and set the reply path return code to TBA1. Then PE1 should use this and set the Reply Path Return Code to 0x0006. Then, PE1 should use
Reply Path TLV in subsequent echo requests. In this example, when this Reply Path TLV in subsequent echo requests. In this example,
the subsequent echo request reaches P3, it should use this Reply Path when the subsequent echo request reaches P3, it should use this Reply
TLV for sending the echo reply. The same Reply Path TLV is Path TLV for sending the echo reply. The same Reply Path TLV is
sufficient for any router in AS2 to send the reply. Because the sufficient for any router in AS2 to send the reply. This is because
first label(N-ASBR4) can direct echo reply to ASBR4 and the second the first label (N-ASBR4) can direct the echo reply to ASBR4 and the
one (EPE-ASBR4-ASBR1) to direct echo reply to AS1. Once the echo second one (EPE-ASBR4-ASBR1) can direct the echo reply to AS1. Once
reply reaches AS1, normal IP forwarding or the N-PE1 helps it to the echo reply reaches AS1, normal IP forwarding or the N-PE1 helps
reach PE1. it to reach PE1.
The example described in the above paragraphs can be extended to The example described in the above paragraphs can be extended to
multiple ASes by following the same procedure of each ASBR adding multiple ASes. This is done by following the same procedure for each
Node-SID and EPE-SID on receiving echo requests from neighboring AS. ASBR, i.e., adding Node-SIDs and EPE-SIDs on receiving echo requests
from neighboring ASes.
Let us consider a topology from Figure 2. It consists of multiple Let us consider the topology from Figure 2. It consists of multiple
IGP domains with multiple areas/levels or separate IGP instances. IGP domains with multiple areas/levels or separate IGP instances.
There is a single border node that separates the two domains. In There is a single border node that separates the two domains. In
this case, PE1 sends a traceroute packet with TTL set to 1 and 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 includes N-PE1 in the Reply Path TLV. ABR1 receives the echo
and while sending the echo reply adds its node Label to the Reply request, adds its node label to the Reply Path TLV (while sending the
Path TLV and sets the Reply path return code to TBA1. The Reply Path echo reply), and sets the Reply Path Return Code to 0x0006. The
TLV in the echo reply from ABR1 consists of [N-ABR1, N-PE1]. The Reply Path TLV in the echo reply from ABR1 consists of [N-ABR1,
next echo request with TTL 2 reaches the P node. It is an internal N-PE1]. The next echo request with a TTL of 2 reaches the P node.
node so it does not change the return Path. The echo request with It is an internal node, so it does not change the return path. The
TTL 3 reaches ABR2 and it adds its node label so the Reply Path TLV echo request with a TTL of 3 reaches ABR2, and it adds its node label
sent in the echo reply will be [N-ABR2, N-ABR1, N-PE1]. echo request so the Reply Path TLV sent in the echo reply will be [N-ABR2, N-ABR1,
with TTL 4 reaches PE4 and it sends an echo reply return code as N-PE1]. The echo request with a TTL of 4 reaches PE4, and it sends
Egress. PE4 does not include any Reply Path TLV in the echo reply. an echo reply Return Code as an egress. PE4 does not include any
The above example assumes a uniform SRGB throughout the domain. In Reply Path TLVs in the echo reply. The above example assumes a
the case of different SRGBs, the top segment will be a Type-C/Type-D uniform SRGB throughout the domain. In the case of different SRGBs,
segment and all other segments will be Type-A. Each border node the top segment will be a Type-C/Type-D segment and all other
converts the Type-C/Type-D segment to Type-A before adding its segments will be Type-A. Each border node converts the Type-C/Type-D
segment to the Reply Path TLV. segment to Type-A before adding its segment to the Reply Path TLV.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, DOI 10.17487/RFC7110, January 2014,
<https://www.rfc-editor.org/info/rfc7110>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
12.2. Informative References
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks–Media Access Control (MAC) Security", August
2023.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>.
[RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G.
Swallow, Ed., "Relayed Echo Reply Mechanism for Label
Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743,
January 2016, <https://www.rfc-editor.org/info/rfc7743>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address
Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
<https://www.rfc-editor.org/info/rfc8277>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>.
[RFC8604] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed.,
Henderickx, W., and D. Cooper, "Interconnecting Millions
of Endpoints with Segment Routing", RFC 8604,
DOI 10.17487/RFC8604, June 2019,
<https://www.rfc-editor.org/info/rfc8604>.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>.
[RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Acknowledgments
Ray, S., and J. Dong, "Border Gateway Protocol - Link
State (BGP-LS) Extensions for Segment Routing BGP Egress
Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August
2021, <https://www.rfc-editor.org/info/rfc9086>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., Thanks to Bruno Decraene for suggesting the use of the generic
and D. Afanasiev, "Segment Routing Centralized BGP Egress Segment sub-TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August Dhody, and Dongjie for their careful reviews and comments. Thanks to
2021, <https://www.rfc-editor.org/info/rfc9087>. Mach Chen for suggesting the use of the Reply Path TLV. Thanks to
Gregory Mirsky for the detailed review, which helped improve the
readability of the document to a great extent.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, Contributors
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., Carlos Pignataro
and A. Gulko, "IGP Flexible Algorithm", RFC 9350, NC State University
DOI 10.17487/RFC9350, February 2023, Email: cpignata@gmail.com
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Zafar Ali
Traffic Engineering Information Using BGP", RFC 9552, Cisco Systems, Inc.
DOI 10.17487/RFC9552, December 2023, Email: zali@cisco.com
<https://www.rfc-editor.org/info/rfc9552>.
Authors' Addresses Authors' Addresses
Shraddha Hegde Shraddha Hegde
Juniper Networks Inc. Juniper Networks, Inc.
Exora Business Park Exora Business Park
Bangalore 560103 Bangalore 560103
KA KA
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Kapil Arora Kapil Arora
Individual Contributor Individual Contributor
Email: kapil.it@gmail.com Email: kapil.it@gmail.com
Mukul Srivastava Mukul Srivastava
Juniper Networks Inc. Juniper Networks, Inc.
Email: msri@juniper.net Email: msri@juniper.net
Samson Ninan Samson Ninan
Ciena Ciena
Email: samson.cse@gmail.com Email: samson.cse@gmail.com
Nagendra Kumar Nagendra Kumar
Oracle Oracle
Email: nagendrakumar.nainar@gmail.com Email: nagendrakumar.nainar@gmail.com
 End of changes. 195 change blocks. 
733 lines changed or deleted 710 lines changed or added

This html diff was produced by rfcdiff 1.48.