RFC 9716
Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks
RFC 9716: Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks 🦋✨
Part 1 of 6
Okay bestie, this RFC is an IETF Standards Track document, dated February 2025, and it's a whole mood 💅. It was written by S. Hegde and M. Srivastava (both from Juniper Networks, Inc.), K. Arora (as an Individual Contributor), S. Ninan (from Ciena), and N. Kumar (from Oracle). Its ISSN is 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so it's a fresh start 🌸.
Abstract 💖
Okay so, Segment Routing (SR) is source routing, and it works directly with an MPLS data plane. An SR-MPLS network can be made of several IGP domains or several Autonomous Systems (ASes), all run by the same organization. Sometimes an SR end-to-end path crosses multiple ASes or IGP domains, and in that case you really want Label Switched Path (LSP) ping and traceroute to work 🫶.
This document is about making LSP ping and traceroute efficient across inter-AS and inter-domain SR-MPLS networks. It does this with a simple extension to the Operations, Administration, and Maintenance (OAM) protocol. The clever bit is that echo replies on transit nodes are handled purely by data plane forwarding 🔥.
Status of This Memo ✨
This is an Internet Standards Track document. 🌈
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.
Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9716. Bookmark it, bestie 🔖.
Copyright Notice 🎀
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️.
Table of Contents 📋
1. Introduction
1.1. Definition of Domain
1.2. Requirements Language
2. Inter-Domain Networks with Multiple IGPs
3. Reply Path TLV
4. Segment Sub-TLV
4.1. Type-A: SID Only, in the Form of an MPLS Label
4.2. Type-C: IPv4 Node Address with an Optional SID for SR-MPLS
4.3. Type-D: IPv6 Node Address with an Optional SID for SR-MPLS
4.4. Segment Flags
5. Detailed Procedures
5.1. Sending an Echo Request
5.2. Receiving an Echo Request
5.3. Sending an Echo Reply
5.4. Receiving an Echo Reply
5.5. Building a Reply Path TLV Dynamically
5.5.1. Procedures to Build the Return Path
6. Security Considerations
7. IANA Considerations
7.1. Segment Sub-TLV
7.2. New Registry for Segment ID Sub-TLV Flags
7.3. Reply Path Return Codes Registry
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Examples
A.1. Detailed Example
A.1.1. Procedures for Segment Routing LSP Ping
A.1.2. Procedures for SR LSP Traceroute
A.1.3. Procedures for Building Reply Path TLV Dynamically
Acknowledgments
Contributors
Authors' Addresses1. Introduction 🚀
Lots of networks are made of multiple ASes, either because they're easier to run that way or because of network mergers and acquisitions 🤝. SR can be deployed in these setups to give you end-to-end paths that cross several Autonomous Systems (ASes).
[RFC8660] specifies SR with an MPLS data plane. [RFC8402] describes BGP peering segments, and [RFC9087] describes centralized BGP Egress Peer Engineering, which helps steer packets from one AS to another. Put those SR capabilities together and you can build paths that span multiple ASes 💅.
Here's the topology we're working with. The diagram is in the code block so the layout stays intact:
+----------------+
| Controller/PMS |
+----------------+
|---AS1-----| |----AS2----| |----AS3---|
ASBR2----ASBR3 ASBR5------ASBR7
/ \ / \
/ \ / \
PE1----P1---P2 P3---P4---PE4 P5---P6--PE5
\ / \ /
\ / \ /
ASBR1----ASBR4 ASBR6------ASBR8
Figure 1: Inter-AS Segment Routing TopologyHere's the breakdown of who's who:
- 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
So, Figure 1 shows an inter-AS network made of AS1, AS2, and AS3. All three are SR enabled, and their egress links have Segment Identifiers (SIDs) configured and advertised via [RFC9086]: PeerNode SID, PeerAdj SID, and PeerSet SID. In this document, those three are called Egress Peer Engineering SIDs (EPE-SIDs) 🧚. The controller or head-end can then build an end-to-end traffic-engineered path out of Node-SIDs, Adjacency-SIDs, and EPE-SIDs ✨.
Operators really want to run LSP ping and traceroute on these inter-AS SR-MPLS paths. That lets them catch failed deliveries, figure out what's going wrong, and see the path traffic actually takes 🕵️♀️. The catch is that LSP ping and traceroute use IP connectivity to get echo replies back to the head-end. In inter-AS networks, not every router on the path has IP connectivity. In Figure 1, for example, P3 and P4 may not have IP connectivity to PE1 😬.
It's not always possible to run LSP ping and traceroute on these paths to check basic connectivity and isolate faults using the existing mechanisms (see [RFC8287] and [RFC8029]). The reason is that a responding node might not have IP connectivity back to the source address of the ping packet when it sits in a different AS from the ping's source.
[RFC8403] describes ways to run MPLS ping and traceroute from a Path Monitoring System (PMS). You can also build GRE tunnels or static routes to every router in the network to get IP connectivity for the reverse path. But that's operationally very heavy. It requires the PMS to be able to build a huge number of GRE tunnels or install the necessary static routes, which may not be feasible 😩.
[RFC7743] describes an Echo-relay-based solution. It works by advertising a new Relay Node Address Stack TLV that contains a stack of Echo-relay IP addresses, and these ideas can be applied to SR networks too. The catch is that the mechanism from [RFC7743] requires the return ping packet to be processed on the slow path, or as a bump-in-the-wire, on every relay node. This document's motivation is to offer an alternate ping and traceroute mechanism for inter-domain SR networks. The meaning of "domain" as used here is defined in Section 1.1 🔍.
This document describes a new mechanism that's efficient, simple, and easy to deploy in SR-MPLS networks 🌸. It uses MPLS paths, and no changes are needed in the forwarding path. Any MPLS-capable node can forward the echo-reply packet in the fast path ⚡. The document uses the Reply Path TLV [RFC7110] to carry the reverse path. It defines three new sub-TLVs for the Reply Path TLV, which make it possible to encode SR label stacks 💜. The return path can come from a smart application or a controller that has a full topology view, or an end-to-end view of part of the topology. The document also proposes ways to derive the return path dynamically during traceroute procedures 🦋.
This document focuses on the inter-domain use case. The protocol extensions described may also indicate the return path for other use cases. Those are outside the scope of this document and aren't detailed here. The SRv6 data plane isn't covered in this document either 🙅♀️.
1.1. Definition of Domain 🗺️
In this document, "domain" means an IGP domain where every node is visible to every other node for shortest path computation. That implies an IGP area or level. An Autonomous System (AS) is made of one or more IGP domains. The procedures here apply to paths built across multiple domains, including both inter-area and inter-AS paths. These procedures and deployment scenarios matter for inter-AS paths where the participating ASes are under closely coordinated administrations or a single ownership. This document is about SR-MPLS networks where all nodes within each domain are SR capable. It also applies to SR-MPLS networks where SR works as an overlay on top of SR-incapable underlay nodes. In those networks, the traceroute procedure runs only on the overlay SR nodes 🧃.
1.2. Requirements Language 📜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.
2. Inter-Domain Networks with Multiple IGPs 🌈
When a network has a large number of nodes, they get split into multiple IGP domains, as Figure 2 shows. You can reach the remote PEs in two ways: with BGP advertisements that carry an MPLS label bound to the prefix, as described in [RFC8277], or by building paths out of a list of segments, as described in [RFC8604] 🧩.
Here's Figure 2. Again, the diagram sits in a code block so the alignment doesn't fall apart:
|-Domain 1|-------Domain 2-----|--Domain 3-|
PE1------ABR1--------P--------ABR2------PE4
\ / \ /\ /
-------- ----------------- -------
BGP-LU BGP-LU BGP-LU
Figure 2: Inter-Domain Networks with Multiple IGPsIt's useful to support MPLS ping and traceroute mechanisms in these networks 🔎. The procedures in this document for constructing the Reply Path TLV, and for using it in echo replies, apply just as well to networks made of multiple IGP domains that use BGP-Labeled Unicast (BGP-LU) or label stacking 💖.
Part 2 is next, bestie. Stay tuned for Section 3 and all the Reply Path TLV drama 🍓.
3. Reply Path TLV 🦋
okay so the Reply Path (RP) TLV is defined in [RFC7110] 💖 SR networks give every label to a node ahead of time, and a PMS/head-end can know the whole Link State Database (LSDB) plus all the assigned SIDs ✨ That means the head-end can build the reverse path by stacking segments for it. The Reply Path TLV from [RFC7110] is what actually carries that return path 🛤️
Reply Mode 5 (Reply via Specified Path) is defined in Section 4.1 of [RFC7110] 🎀 When you use the procedures in this document, the Reply Mode gets set to 5 (Reply via Specified Path), and the Reply Path TLV goes into the echo request message as described in [RFC7110]. The Reply Path TLV is put together following Section 4.2 of [RFC7110]. This document adds three new sub-TLVs to encode the SR Path 🧚
The head-end gets to pick which segment type goes in the Reply Path TLV, and that choice is governed by local policy 💅 Implementations can take Command Line Interface (CLI) input in the form of labels, IPv4 addresses, IPv6 addresses, or a mix of those, and then encode them into the Reply Path TLV. They can also grab the LSDB of remote domains and compute the return path from that data 👑 For traceroute, the return path has to account for the reply coming from every node along the path, and it changes as the traceroute moves across each domain 😭 One way to do this on the head-end is to get the entire LSDB (across all domains) and build a return path for every node on the SR-MPLS path using that knowledge. Another option is a dynamically computed return path, which is covered in Section 5.5 🌸
Some networks are a mix of IPv4-only and IPv6-only domains. Handling end-to-end MPLS OAM for those is out of scope for this document 🙈 In that situation it is recommended to use dual-stack and to use end-to-end IPv6 addresses for the MPLS ping and traceroute procedures ✨
4. Segment Sub-TLV 🌈
Section 4 of [RFC9256] defines the various Segment Types 💜 This section defines the segment types that apply to this document for use in MPLS OAM. The goal was to keep these definitions as close to [RFC9256] as possible, and only change things when it was truly needed 🫶 One or more Segment sub-TLVs can go inside a Reply Path TLV, and those Segment sub-TLVs MAY be of different types 🔥
These are the Segment sub-TLV types that apply to the Reply Path TLV. Their code points come from the IANA registry shared by TLVs 1, 16, and 21 📋 This document only defines how the Type-A, Type-C, and Type-D Segment sub-TLVs get used and processed when they show up in TLV 21 (Reply Path TLV). If any of these sub-TLVs show up in TLVs 1 or 16, appropriate error codes MUST be returned, as defined in [RFC8029] 🚨
- Type-A: SID only, in the form of an MPLS label
- Type-C: IPv4 Node Address with an optional SID
- Type-D: IPv6 Node Address with an optional SID for SR-MPLS
4.1. Type-A: SID Only, in the Form of an MPLS Label 🍓
The Type-A Segment sub-TLV encodes one SID as an MPLS label 🎀 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: Type-A Segment Sub-TLV
Here's what each field means 💖
Type: 2 octets. Carries the value 46 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).Length: 2 octets. Carries the value 8. The length value does not count the Type and Length fields themselves.Flags: 1 octet of flags, as defined in Section 4.4.RESERVED: 3 octets of reserved bits. MUST be set to zero when sending. MUST be ignored on receipt.Label: 20 bits of label value.TC: 3 bits of Traffic Class (TC). If the originator wants the receiver to pick the TC value, it MUST set the TC field to zero.S: 1 bit, Reserved. The S bit MUST be zero upon transmission and MUST be ignored upon reception.TTL: 1 octet of TTL. If the originator wants the receiver to pick the TTL value, it MUST set the TTL field to 255.
The labels, TC, S, and TTL together are called a SID ✨
For the Type-A Segment sub-TLV, the receiver MAY override the originator's values for these fields 🌸 The receiver's local policy decides whether that happens. One possible policy is to only override the fields when they still have the default values listed above 💅
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, an SR Algorithm, and an optional SID in the form of an MPLS label 💜 Here's the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Type-C Segment Sub-TLV
The breakdown 🫧
Type: 47 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).Length: 2 octets. Carries the value 8 when no optional SID is included, or the value 12 when the optional SID is included.Flags: 1 octet of flags, as defined in Section 4.4.RESERVED: 2 octets of reserved bits. MUST be set to zero when sending. MUST be ignored on receipt.SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4) is present, this specifies the SR Algorithm described in Section 3.1.1 of [RFC8402], or the Flexible Algorithm defined in [RFC9350]. The receiver uses the SR Algorithm to derive the label. When the A-Flag is unset, this field has no meaning, so it MUST be set to zero (MBZ) on transmission and ignored on receipt.IPv4 Node Address: a 4-octet IPv4 address that represents a node. The IPv4 Node Address MUST be present. It should be a stable address that belongs to the node (for example, a loopback address) 🌷SID: an optional 4-octet field holding the TC, S, and TTL labels as defined in Section 4.1. When the SID field is present, it MUST be used for constructing the Reply Path 🔥
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, an SR Algorithm, and an optional SID in the form of an MPLS label 🌈 Here's the format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | RESERVED (MBZ) | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: Type-D Segment Sub-TLV
Now the fields 🎀
Type: 48 (assigned by IANA from the "Sub-TLVs for TLV Types 1, 16, and 21" registry).Length: 2 octets. Carries the value 20 when no optional SID is included, or the value 24 when the optional SID is included.Flags: 1 octet of flags, as defined in Section 4.4.RESERVED: 2 octets of reserved bits. MUST be set to zero when sending. MUST be ignored on receipt.SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4) is present, this specifies the SR Algorithm described in Section 3.1.1 of [RFC8402], or the Flexible Algorithm defined in [RFC9350]. The receiver uses the SR Algorithm to derive the label. When the A-Flag is unset, this field has no meaning, so it MUST be set to zero (MBZ) on transmission and ignored on receipt.IPv6 Node Address: a 16-octet IPv6 address of one interface of a node. The IPv6 Node Address MUST be present. It should be a stable address that belongs to the node (for example, a loopback address) 🌸SID: an optional 4-octet field holding the TC, S, and TTL labels as defined in Section 4.1. When the SID field is present, it MUST be used for constructing the Reply Path 💅
4.4. Segment Flags 🚩
The Segment Types above all carry the following flags in their Flags field (codes assigned by IANA from the "Segment ID Sub-TLV Flags" registry) 📋
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| |A| | | | | | |
+-+-+-+-+-+-+-+-+Figure 6: Flags
Where 💫
- A-Flag: this flag tells you there's an SR Algorithm ID in the SR Algorithm field, which applies to several Segment Types.
Unused bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon reception 🫶
For the Segment Flags, the A-Flag applies to Segment Type-C and Type-D. If the A-Flag shows up with the Type-A Segment Type, it MUST be ignored 🙈
5. Detailed Procedures 🎀
This section uses "initiator" for the node that starts the MPLS ping or MPLS traceroute procedure 🦋 "Responder" is the node that receives the echo request and sends back the echo reply ✨ "Egress node" is the last node that the MPLS ping or traceroute is headed for 🧚 In an MPLS network, any node can be an initiator, a responder, or an egress 👑
5.1. Sending an Echo Request 🛰️
In the inter-AS scenario, the procedures in this document are used to specify the return path when IP connectivity to the initiator isn't available 😭 They can also be used whether or not IP connectivity is available 🌈 The LSP ping 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 request message to match 💖 The Reply Path TLV MUST contain the SR Path in the reverse direction, encoded as an ordered list of segments. The first segment MUST correspond to the top segment in the MPLS header that the responder MUST use while sending the echo reply 🔥
5.2. Receiving an Echo Request ✨
okay so, bestie, picture this 💅 when the Reply Mode is set to 5 (Reply via Specified Path), the echo request MUST carry the Reply Path TLV 🎀 as described in [RFC7110]. no Reply Path TLV? that's a malformed echo request, periodt 💀
when an echo request shows up, if the responder doesn't support Reply Mode 5 from [RFC7110], it has to send back an echo reply with the Return Code set to "Malformed echo request received" and the Subcode set to zero 🙈 following the rules of [RFC8029]. and if the echo request has a malformed Segment sub-TLV, like a wonky length field, the responder has to send an echo reply with that same Return Code ("Malformed echo request received") and Subcode zero 😭 no exceptions, no vibes-based decisions.
when a Reply Path TLV comes in and the responder knows how to process it, the responder MUST use the segments in that Reply Path TLV to build the echo reply 🦋 it also MUST follow the normal Forwarding Equivalence Class (FEC) validation procedures from [RFC8029] and [RFC8287], and this document doesn't suggest changing those one bit 🫶 and when the echo reply actually has to go out, the Reply Path TLV MUST be used to construct the MPLS packet 🌸
5.3. Sending an Echo Reply ✨
the echo reply goes out as an MPLS packet with an MPLS label stack 🧚 the echo reply message MUST be constructed as described in [RFC8029], and the packet carries that echo reply in its payload. the top label MUST come from the first segment of the Reply Path TLV, and the remaining labels MUST follow the order of the segments in the Reply Path TLV 💖 the MPLS header MUST be built from the segments in the Reply Path TLV and MUST NOT add any other label, no sneaky extras 🙅♀️ the S bit is set for the bottom label, as per [RFC3032] 🍓
the responder MAY check whether the top label is reachable in its own Label Forwarding Information Base (LFIB) before sending the echo reply 👑 if the top label is unreachable, the responder SHOULD send the appropriate Return Code and follow the procedures in Section 5.2 of [RFC7110] 💜
the exception case is when the responder has no IP reachability to the originator. then it might not be possible to send an echo reply at all 😭 even if it does get sent (say, by following a default route on the responder), the echo reply might never reach the originator 🥺 the node MAY provide log information in case of unreachability 📝
in certain scenarios, the head-end MAY choose to send Type-C/Type-D segments made of IPv4 or IPv6 addresses when it can't derive the SID from the available topology information 🌈 optionally, the SID can also be attached to the Type-C/Type-D segment, if the controller or operator input provides it 🎀 in those cases, the node sending the echo reply MUST derive the MPLS labels from the Node-SIDs associated with the IPv4/IPv6 addresses. if an optional MPLS SID is present in the Type-C/Type-D segment, the SID MUST be used to encode the echo reply with MPLS labels ✨ and if the MPLS SID doesn't match the IPv4 or IPv6 address 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 [RFC7110] 🦋 and according to Section 5.3 of [RFC7110], the Reply Path TLV is included in an echo reply to indicate the specified return path that the echo reply message is required to follow 🌸
when the node is configured to dynamically create a return path for the next echo request, the procedures in Section 5.5 MUST be used 👑 the Reply Path Return Code MUST be set to 0x0006, and the same Reply Path TLV or a new one MUST be included in the echo reply 💅
5.4. Receiving an Echo Reply ✨
the rules and processes in Section 4.6 of [RFC8029] and Section 5.4 of [RFC7110] apply here too 🫶 on top of that, if the Reply Path Return Code is "Use Reply Path TLV from this echo reply for building the next echo request" (as defined in this document), the Reply Path TLV from the echo reply MUST be sent in the next echo request with the TTL incremented by 1 💖
if the initiator doesn't support the Return Code "Use Reply Path TLV from this echo reply for building the next echo request", log information SHOULD be generated showing the Return Code, and the operator may choose to specify the return path explicitly or use other mechanisms to verify the SR Policy 🙈 if the Return Code is 0x0007 "Local policy does not allow dynamic return path building", that means the intermediate node can't build a dynamic return path 😭 log information SHOULD be generated on the initiator that receives this Return Code, and the operator may again pick an explicit return path or other ways to verify the SR Policy 🧚
and if the TTL is already 255, the traceroute procedure MUST be ended with an appropriate log message 🛑
5.5. Building a Reply Path TLV Dynamically ✨
sometimes the head-end just doesn't have the full picture of the inter-AS/inter-domain topology 🌍 so it can rely on routers along the path to build the reverse path for MPLS traceroute procedures 🧠 the Reply Path TLV in the echo reply is the return path that gets used to build the next echo request. this document defines a brand new Return Code, "Use Reply Path TLV from this echo reply for building the next echo request" 🎉
+========+=========================================+
| Value | Meaning |
+========+=========================================+
| 0x0006 | Use Reply Path TLV from this echo reply |
| | for building the next echo request |
+--------+-----------------------------------------+
Table 15.5.1. Procedures to Build the Return Path 🌷
to build the return path dynamically, the domain border nodes along the traced path should support the procedures in this section 💜 whether a domain border node joins in on dynamic return path building during traceroute is decided by local policy on that node 🎀
the head-end/PMS node may include its node label when it starts the traceroute procedure 🚀 when an Area Border Router (ABR) receives the echo request and local policy calls for dynamic return path building, the ABR SHOULD include its node label in the Reply Path TLV and send it in the echo reply 🦋 if the received echo request already has a Reply Path TLV, the ABR's node label gets added before the existing segments 🫶 the type of segment added is based on local policy. when the Segment Routing Global Block (SRGB) isn't uniform across the network (which can be inferred from the LSDB), it is RECOMMENDED to add a Type-C or a Type-D segment 🌈 implementations MAY safely use other approaches if they see benefits in doing so ✨ if the existing segment in the Reply Path TLV is a Type-C/Type-D segment, it SHOULD be converted to a Type-A segment based on the ABR's own SRGB 🔥 this is because downstream nodes won't know which SRGB to use to translate the IP address into a label 🙈 since the ABR added its own node label, it's guaranteed that this ABR will be on the return path and will forward traffic based on the next label after its label 💖
when an ASBR gets an echo request from another AS, and the ASBR is configured to build the return path dynamically, the ASBR SHOULD build a Reply Path TLV and include it in the echo reply 👑 that Reply Path TLV should consist of its node label plus an EPE-SID to the AS the traceroute message came from 🧚 a Reply Path Return Code of 0x0006 MUST be set in the echo reply to indicate that the next echo request MUST use the return path from the Reply Path TLV in the echo reply 💅 the ASBR should decide locally which outgoing interface the echo reply goes out on 🌸 generally, the remote ASBR will choose the interface on which the incoming OAM packet was received to send the echo reply 🫶 if the ASBR sees multiple paths to reach the initiator, it MUST choose one such path to put in the Reply Path TLV 🍓 the Reply Path TLV is built by adding two Segment sub-TLVs 🎀 the top Segment sub-TLV holds the ASBR's Node-SID, and the second holds the EPE-SID in the reverse direction to reach the AS the OAM packet came from 💜 which type of segment goes into the Reply Path TLV is a local policy call 🌈 it is RECOMMENDED to use the Type-C/Type-D segment for the top segment when the SRGB isn't guaranteed to be uniform in the domain ✨
no matter which segment type is in the Reply Path TLV, the responder to the echo requests MUST always translate the Reply Path TLV into a label stack and build an MPLS header for the echo reply packet 🔥 this works for an end-to-end path spanning multiple ASes 🌍 and each ASBR that receives an echo request from another AS adds its Node-SID and EPE-SID on top of the existing segments in the Reply Path TLV 🦋
an ASBR that receives the echo request from a neighbor in the same AS MUST look at the Reply Path TLV it got in the echo request 👀 if that Reply Path TLV has a Type-C/Type-D segment, the ASBR MUST convert it into a Type-A segment by deriving a label from its own SRGB 🛠️ the ASBR MUST set the Reply Path Return Code to 0x0006 and send the newly built Reply Path TLV in the echo reply 💖
internal nodes or non-domain border nodes might not set the Reply Path Return Code to 0x0006 in the echo reply, since the return path hasn't changed 🙃 in those cases, the head-end node/PMS that starts the traceroute MUST keep sending the previously sent Reply Path TLV in the echo request in every subsequent echo request 🔁
heads up though: an ASBR's local policy may stop it from joining dynamic traceroute procedures 🚫 if one of those ASBRs shows up in the forward path, dynamic return path building will fail 😬 in that case, an ASBR that supports this document MUST set the Return Code to 0x0007 to say that local policies don't allow dynamic return path building 🙅♀️
+========+==========================================================+
| Value | Meaning |
+========+==========================================================+
| 0x0007 | Local policy does not allow |
| | dynamic return path building |
+--------+----------------------------------------------------------+
Table 26. Security Considerations 🔒
okay bestie, this section is SERIOUS but we're still gonna make it cute 🎀. The procedures in this doc let LSP ping and traceroute run across multiple IGP domains or multiple ASes that belong to the same administration or closely cooperating administrations 🫶. It's assumed that sharing domain internal info across those domains doesn't pose a security risk ✨. BUT, and this is a big but 💀, an attacker could use these same procedures to extract the domain's internal info. An operator MUST deploy appropriate filter policies as described in [RFC8029] to restrict the LSP ping and traceroute packets based on origin 🚫. It's also RECOMMENDED that an operator deploy security mechanisms such as Media Access Control Security (MACsec) [IEEE-802.1AE] on inter-domain links or security-vulnerable links to prevent spoofing attacks 🔐.
All the security considerations defined in [RFC8029] apply to this document too, so no skipping them 📖. Appropriate filter policies SHOULD be applied at the edges to stop attackers from getting into the network 🧱. And if a security breach does happen, the network devices MUST have mechanisms to prevent denial-of-service attacks as described in [RFC8029] 😭🚨.
7. IANA Considerations 🦋
7.1. Segment Sub-TLV
IANA has assigned three new sub-TLVs from the "Sub-TLVs for TLV Types 1, 16, and 21" registry of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group 🌸.
+==========+=====================================+=============+
| Sub-Type | Sub-TLV Name | Reference |
+==========+=====================================+=============+
| 46 | SID only, in the form of MPLS label | Section 4.1 |
| | | of RFC 9716 |
+----------+-------------------------------------+-------------+
| 47 | IPv4 Node Address with an optional | Section 4.2 |
| | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+
| 48 | IPv6 Node Address with an optional | Section 4.3 |
| | SID for SR-MPLS | of RFC 9716 |
+----------+-------------------------------------+-------------+Table 3
The code points for the Segment sub-TLVs have been registered in the Standards Action range (0-16383) 💜.
7.2. New Registry for Segment ID Sub-TLV Flags
IANA has created a new "Segment ID Sub-TLV Flags" registry (see Section 4.4) under the "Multiprotocol Label Switched Paths (LSPs) Ping Parameters" registry group. Yes, I know the name is a lot 💅.
This registry tracks the assignment of 8 flags in the Segment ID sub-TLV flags field. The flags are numbered from 0 (the most significant bit and transmitted first) to 7 🧚.
New entries are assigned by Standards Action. Initial entries in the registry are as follows:
+============+========+=========================+
| Bit Number | Name | Reference |
+============+========+=========================+
| 1 | A-Flag | Section 4.4 of RFC 9716 |
+------------+--------+-------------------------+Table 4
7.3. Reply Path Return Codes Registry
IANA has assigned new Return Codes in the "Reply Path Return Codes" registry under the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group 🍓.
+========+=========================================+===========+
| Value | Meaning | Reference |
+========+=========================================+===========+
| 0x0006 | Use Reply Path TLV from this echo reply | RFC 9716 |
| | for building the next echo request | |
+--------+-----------------------------------------+-----------+
| 0x0007 | Local policy does not allow dynamic | RFC 9716 |
| | return path building | |
+--------+-----------------------------------------+-----------+Table 5
The Return Codes have been registered in the Standards Action range (0x0000-0xFFFB) ✨.
8. References 📚
8.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.
8.2. Informative References
[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.
[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.
[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., 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., 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.
[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.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", RFC 9350, DOI 10.17487/RFC9350, February 2023, https://www.rfc-editor.org/info/rfc9350.
[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 traceroute procedures described in this document. Time for the fun part 🎉.
A.1. Detailed Example
The example topology given in Figure 1 will be used in the below sections to explain LSP ping and traceroute procedures. The PMS/head-end has a complete view of the topology. PE1, P1, P2, ASBR1, and ASBR2 are in AS1. Similarly, ASBR3, ASBR4, P3, P4, and PE4 are in AS2 🗺️.
AS1 and AS2 have SR enabled. IGPs like OSPF/IS-IS are used to flood SIDs in each AS. ASBR1, ASBR2, ASBR3, and ASBR4 advertise BGP EPE-SIDs for the inter-AS links. The topologies of AS1 and AS2 are advertised via BGP - Link State (BGP-LS) to the controller, PMS, or head-end node. The EPE-SIDs are also advertised via BGP-LS as described in [RFC9086]. The example uses EPE-SIDs for the inter-AS links, but the same could be achieved using Adjacency-SIDs advertised for a passive IGP link 🔗.
The description in this document uses the notations below for SIDs 🏷️.
- Node-SIDs: N-PE1, N-P1, N-ASBR1, etc.
- Adjacency-SIDs: Adj-PE1-P1, Adj-P1-P2, etc.
- EPE-SIDs: EPE-ASBR2-ASBR3, EPE-ASBR1-ASBR4, EPE-ASBR3-ASBR2, etc.
A.1. Detailed Example (continued) ✨
A.1.1. Procedures for Segment Routing LSP Ping 🦋
okay so picture this: we've got an SR-MPLS path from PE1 to PE4, made of the label stack [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] from Figure 1 💖. To run MPLS ping on this path, the remote end (PE4) needs IP connectivity back to the head-end PE1 so the echo reply can get home 🏠. But in a deployment with a controller-computed inter-domain path, PE4 might have no IP connectivity to PE1, since they live in different ASes 💀.
PE1 sends an echo request to the endpoint PE4 along [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. It also tucks the return path from PE4 back to PE1 into the echo request, inside the Reply Path TLV 🎀. As an example, the Reply Path TLV for PE1 to PE4 LSP ping is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. This example gives the entire return path all the way to the head-end node PE1. How the return path gets constructed is implementation dependent, so each vendor gets to decide that part 🤷♀️.
An implementation can also build a return path made of labels that just gets the reply into its own AS. Once that label stack is popped, the echo reply is exposed, and the rest of the forwarding is based on IP lookup 🌸. An example return path for this case could be [N-ASBR4, EPE-ASBR4-ASBR1].
When PE4 gets an MPLS echo request, it first validates the FEC in the request 🔍. Then it builds a label stack for the reply to PE1 by copying the labels from the Reply Path TLV. PE4 builds the echo reply packet with that MPLS label stack, imposes the MPLS headers on top, and sends the packet to PE1 🚀. This segment list stack can successfully steer the reply back to the head-end node (PE1) 👑.
Now the drama: what if P3 doesn't have a route to reach N-PE4? Then the ping packet just gets dropped at P3, and the head-end node (PE1) never receives an echo reply, so it knows something failed 😭.
A.1.2. Procedures for SR LSP Traceroute 🗺️
A.1.2.1. Procedures for SR LSP Traceroute with the Same SRGB on All Nodes 💜
Traceroute is all about visiting every node on the path and collecting echo replies from each one 🧚. In this section we look at traceroute when the head-end/PMS has complete visibility of the LSDB. The head-end/PMS computes the return path from each node along the entire SR-MPLS path being traced. Computing that return path is implementation dependent, and since the head-end/PMS fully controls it, it can use proprietary computations to build it 💅.
One way to build the return path is to stack up labels: as the traceroute moves along, each domain border node's Node-SID gets added to the return path label stack 🥞. For inter-AS networks, the EPE-SID in the reverse direction also needs to go on the label stack, alongside the border node's Node-SID ✨.
The inter-domain/inter-AS traceroute procedure relies on the TTL expiry mechanism from [RFC8029] and [RFC8287] ⏳. Every echo request sent by the head-end/PMS includes the appropriate return path in the Reply Path TLV. The node that receives the echo request follows the procedures in Sections 5.1 and 5.2 to send out its echo reply 📨.
Let's walk through an example, because this is where it gets good 🎬. Take the topology from Figure 1 and the SR-MPLS path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4]. The traceroute runs on this inter-AS path toward destination PE4. PE1 sends the first echo request with the TTL set to 1, and it includes a Reply Path TLV holding a Type-A segment with a label derived from PE1's own SRGB. Which segment type goes into the return path is decided by local policy, so it's a policy call 📋. If the whole network has the same SRGB configured, Type-A segments are fine to use 🙌. The TTL expires on P1, and P1 sends an echo reply using the return path 💫.
Quick heads-up: implementations may choose to leave out the Reply Path TLV until the traceroute reaches the first domain border 🙈. The reason is that the return IP path to PE1 is expected to be available inside the first domain anyway.
Next, the TTL is set to 2 and the next echo request goes out 🏃♀️. Until the traceroute reaches the domain border node ASBR1, the same return path TLV, made of a single label (PE1's node label), keeps getting used 🔁. When an echo request reaches the border node ASBR1 and an echo reply comes back from ASBR1, the next echo request has to include an extra label, because ASBR1 is a border node 🚧. The head-end node can see the whole network LSDB learned via BGP-LS (see [RFC9552] and [RFC9086]), so it can work out the details of the ASBR nodes 🧠. The Reply Path TLV is built based on the forward path. Since the forward path has EPE-ASBR1-ASBR4 in it, an EPE-SID in the reverse direction goes into the Reply Path TLV 💡. The return path is now two labels: [EPE-ASBR4-ASBR1, N-PE1], and the echo reply from ASBR4 uses this return path to get back 🦄.
After the traceroute visits the border node ASBR4, the next echo request updates the return path with ASBR4's Node-SID label 🌈. From there, the return path beyond ASBR4 is [N-ASBR4, EPE-ASBR4-ASBR1, N-PE1]. That same return path stays in use until the traceroute reaches the next set of border nodes ⭐. When there are multiple ASes, the traceroute keeps going, adding a set of Node-SIDs and EPE-SIDs as each border node is visited 🫶.
Important: this return path building procedure only works if the LSDB of all the domains is available at the head-end/PMS 👑.
Now let's go back to the broken case, where P3 doesn't have a route to reach N-PE4 🥲. When the TTL is 5, the packet reaches P3, its TTL hits zero, and the packet is sent up to the control plane 🛑. The FEC validation procedures run, and the echo reply goes out using the labels in the Reply Path TLV, which is [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4]. The head-end PE1 bumps the TTL up to 6 and sends the next echo request 📈. This time the packet gets dropped at P3, since P3 has no route to forward it to N-PE4 💔. The traceroute spots that the path [N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4] is broken at P3 🔎.
A.1.2.2. Procedures for SR LSP Traceroute with Different SRGBs 🌟
Appendix A.1.2.1 assumes the same SRGB is configured on all nodes along the path. But real life is messier 😅. The SRGB can differ from one node to another, and the SR architecture [RFC8402] lets nodes use different SRGBs. In that case, PE1 finds out about the SRGB difference by looking into the LSDB 🕵️♀️. Then it sends a Type-C segment (or a Type-D segment, for IPv6 networks) carrying the node address of PE1, plus an optional MPLS SID associated with that node address 💌. The receiving node derives the label for the return path from its own SRGB 🧮.
When the traceroute crosses the border ASBR1, the head-end PE1 should send a Type-A segment for N-PE1, with the label derived from ASBR1's SRGB 🎯. This is needed because ASBR4, P3, P4, and so on may not have the topology information to derive the SRGB for PE1 🙏. Once the traceroute reaches ASBR4, the return path becomes [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 a return path specific to an algorithm (as defined in [RFC9350]), a Type-C Segment sub-TLV with the corresponding algorithm field set should be used 🧑💻. The A-Flag should be set to indicate that the SID corresponding to the algorithm should be used 🚩.
What about three or more ASes? Let's trace from PE1 to PE5 in Figure 1 🌍. This path has to cross three domains: AS1, AS2, and AS3. Say the PE1 to PE5 path goes through [PE1, ASBR1, ASBR4, ASBR6, ASBR8, PE5]. While the traceroute is visiting nodes in AS1, the Reply Path TLV from the head-end is just [N-PE1] 🏁. When the traceroute reaches ASBR4, the return path becomes [N-PE1, EPE-ASBR4-ASBR1] 💫. While visiting nodes in AS2, the Reply Path TLV is [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4] 🛤️. Similarly, when visiting ASBR8, the EPE-SID from ASBR8 to ASBR6 gets added to the Reply Path TLV 🪄. And while visiting nodes in AS3, the Node-SID of ASBR8 also gets added, which makes the return path [N-PE1, EPE-ASBR4-ASBR1, N-ASBR4, EPE-ASBR8-ASBR6, N-ASBR8] 🎉.
One more example, this time from the topology in Figure 2 🦋. This topology has a multi-domain IGP with a common border node between the domains. That could be set up with multi-area or multi-level IGP, or with multiple IGP instances deployed on the same node 🧠. The return path computation here works like the multi-AS computation, except the return path contains a single border node label 💜.
A.1.3. Procedures for Building Reply Path TLV Dynamically ✨
Okay bestie, let's look at the topology from Figure 1 🦋. We build an SR Policy path from PE1 to PE4 with this label stack: N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 starts the traceroute with the TTL set to 1 and puts [N-PE1] in the Reply Path TLV 💅. The traceroute packet's TTL expires on P1, and P1 handles it as described in [RFC8029] and [RFC8287] 🔥. P1 then sends an echo reply with that same Reply Path TLV and sets the Reply Path Return Code to 6. The Return Code of the echo reply itself gets set according to [RFC8029] and [RFC8287] 🎀. This traceroute doesn't need any changes to the Reply Path TLV until it leaves AS1 🌸. Also, P1 and P2 can copy the Reply Path TLV they received into their echo replies. Or they can leave it out entirely, so the head-end keeps using the same return path it used in the previous echo request 🫶.
Now, when ASBR1 gets the echo request, if the Reply Path TLV in it has a Type-C/Type-D segment, ASBR1 converts that segment to Type-A using its own SRGB 🧚. When ASBR4 receives the echo request, it should build this Reply Path TLV using its Node-SID (N-ASBR4) and its EPE-SID (EPE-ASRB4-ASBR1) labels, and it sets the Reply Path Return Code to 0x0006 💜. After that, PE1 should use this Reply Path TLV in its later echo requests ✨. In this example, when the next echo request reaches P3, P3 should use this Reply Path TLV to send the echo reply 🍓. The same Reply Path TLV is enough for any router in AS2 to send its reply, and that's because the first label (N-ASBR4) can steer the echo reply to ASBR4, and the second one (EPE-ASBR4-ASBR1) can steer it to AS1 🦋. Once the echo reply gets to AS1, normal IP forwarding, or N-PE1, gets it back to PE1 🌈.
This whole example can be stretched across multiple ASes, and it's the same procedure every time. You just repeat it for each ASBR, which means adding Node-SIDs and EPE-SIDs whenever an echo request comes in from a neighboring AS 👑.
Next, let's check out the topology from Figure 2 💖. This one has multiple IGP domains, with multiple areas or levels, or separate IGP instances. A single border node separates the two domains 🌸. Here PE1 sends a traceroute packet with the TTL set to 1 and includes N-PE1 in the Reply Path TLV 🦋. ABR1 gets the echo request, adds its node label to the Reply Path TLV while it sends the echo reply, and sets the Reply Path Return Code to 0x0006 ✨. So the Reply Path TLV in the echo reply from ABR1 is [N-ABR1, N-PE1] 💅. The next echo request, with a TTL of 2, reaches the P node. The P node is an internal node, so it doesn't change the return path 🫶. The echo request with a TTL of 3 reaches ABR2, and ABR2 adds its node label, so the Reply Path TLV in the echo reply becomes [N-ABR2, N-ABR1, N-PE1] 🔥. The echo request with a TTL of 4 reaches PE4, and PE4 sends an echo reply with a Return Code as an egress 🎀. PE4 doesn't include any Reply Path TLVs in its echo reply 🙈. Everything above assumes a uniform SRGB throughout the domain. If the SRGBs are different, the top segment is a Type-C/Type-D segment and every other segment is Type-A 🧚. Each border node converts the Type-C/Type-D segment to Type-A before it adds its own segment to the Reply Path TLV 💜.
Acknowledgments
Huge thanks to Bruno Decraene for suggesting the use of the generic Segment sub-TLV 🫶. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Dhody, and Dongjie for their careful reviews and comments 💖. Thanks to Mach Chen for suggesting the use of the Reply Path TLV ✨. And thanks to Gregory Mirsky for the detailed review, which made the document way more readable 😭🌈.
Contributors
Carlos Pignataro
NC State University
Email: cpignata@gmail.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.comAuthors' Addresses
Shraddha Hegde
Juniper Networks, Inc.
Exora Business Park
Bangalore 560103
KA
India
Email: shraddha@juniper.net
Kapil Arora
Individual Contributor
Email: kapil.it@gmail.com
Mukul Srivastava
Juniper Networks, Inc.
Email: msri@juniper.net
Samson Ninan
Ciena
Email: samson.cse@gmail.com
Nagendra Kumar
Oracle
Email: nagendrakumar.nainar@gmail.com📦 where this page comes from
- ietf: rfc9716 2025-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms