rfc9716v1.txt   rfc9716.txt 
skipping to change at line 12 skipping to change at line 12
Internet Engineering Task Force (IETF) S. Hegde Internet Engineering Task Force (IETF) S. Hegde
Request for Comments: 9716 Juniper Networks, Inc. Request for Comments: 9716 Juniper Networks, Inc.
Category: Standards Track K. Arora Category: Standards Track K. Arora
ISSN: 2070-1721 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
January 2025 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
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. A Segment can be directly applied to the use of an MPLS data plane. A Segment
Routing over MPLS (SR-MPLS) network may consist of multiple IGP Routing over MPLS (SR-MPLS) network may consist of multiple IGP
domains or multiple Autonomous Systems (ASes) under the control of domains or multiple Autonomous Systems (ASes) under the control of
the same organization. It is useful to have the Label Switched Path the same organization. It is useful to have the Label Switched Path
(LSP) ping and traceroute procedures when an SR end-to-end path (LSP) ping and traceroute procedures when an SR end-to-end path
traverses multiple ASes or IGP domains. This document outlines traverses multiple ASes or IGP domains. This document outlines
skipping to change at line 138 skipping to change at line 138
Provider Edge: PE1, PE4, PE5 Provider Edge: PE1, PE4, PE5
Provider: P1, P2, P3, P4, P5, P6 Provider: P1, P2, P3, P4, P5, P6
Autonomous System Boundary Router: ASBR1, ASBR2, ASBR3, ASBR4, Autonomous System Boundary Router: ASBR1, ASBR2, ASBR3, ASBR4,
ASBR5, ASBR6, ASBR7, ASBR8 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 and traceroute procedures on these inter-AS SR-MPLS paths, to detect
determine the actual path that traffic takes through the network. and diagnose failed deliveries, and to determine the actual path that
LSP ping and traceroute procedures use IP connectivity for echo traffic takes through the network. LSP ping and traceroute
replies to reach the head-end. In inter-AS networks, IP connectivity procedures use IP connectivity for echo replies to reach the head-
may not be there from each router in the path. For example, in end. In inter-AS networks, IP connectivity may not be there from
Figure 1, P3 and P4 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 (see isolation using existing LSP ping and traceroute mechanisms (see
[RFC8287] and [RFC8029]). That is because there might not always be [RFC8287] and [RFC8029]). That is because there might not always be
IP connectivity from a responding node back to the source address of IP connectivity from a responding node back to the source address of
the ping packet when the responding node is in a different AS from the ping packet when the responding node is in a different AS from
the source of the ping. the source of the ping.
[RFC8403] describes mechanisms to carry out MPLS ping and traceroute [RFC8403] describes mechanisms to carry out MPLS ping and traceroute
from a Path Monitoring System (PMS). It is possible to build GRE from a Path Monitoring System (PMS). It is possible to build GRE
tunnels or static routes to each router in the network to get IP tunnels or static routes to each router in the network to get IP
connectivity for the reverse path. This mechanism is operationally connectivity for the reverse path. This mechanism is operationally
very heavy and requires the PMS to be capable of building a huge very heavy and requires the PMS to be capable of building a huge
number of GRE tunnels or installing the necessary static routes, number of GRE tunnels or installing the necessary static routes,
which may not be feasible. which may not be feasible.
[RFC7743] describes an Echo-relay based solution that is based on [RFC7743] describes an Echo-relay-based solution that is predicated
advertising a new Relay Node Address Stack TLV containing a stack of on advertising a new Relay Node Address Stack TLV containing a stack
Echo-relay IP addresses. These mechanisms can be applied to SR of Echo-relay IP addresses. These mechanisms can be applied to SR
networks as well. The mechanism from [RFC7743] requires the return networks as well. The mechanism from [RFC7743] requires the return
ping packet to be processed on the slow path or as a bump-in-the-wire ping packet to be processed on the slow path or as a bump-in-the-wire
on every relay node. The motivation of the current document is to on every relay node. The motivation of the current document is to
provide an alternate mechanism for ping and traceroute in inter- provide an alternate mechanism for ping and traceroute in inter-
domain SR networks. The definition of the term "domain" as domain SR networks. The definition of the term "domain" as
applicable to this document is 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
skipping to change at line 225 skipping to change at line 226
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 "OPTIONAL" in this document are to be interpreted as described in
BCP 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
the Reply Path TLV and its use in echo replies are equally applicable the Reply Path TLV and its use in echo replies are equally applicable
to networks consisting of multiple IGP domains that use BGP-LU or to networks consisting of multiple IGP domains that use BGP-Labeled
label stacking. Unicast (BGP-LU) or label stacking.
3. Reply Path TLV 3. Reply Path TLV
The Reply Path (RP) TLV is defined in [RFC7110]. SR networks The Reply Path (RP) TLV is defined in [RFC7110]. SR networks
statically assign the labels to nodes, and a PMS/head-end may know statically assign the labels to nodes, and a PMS/head-end may know
the entire Link State Database (LSDB) along with assigned SIDs. The the entire Link State Database (LSDB) along with assigned SIDs. The
reverse path can be built from the PMS/head-end by stacking segments reverse path can be built from the PMS/head-end by stacking segments
for the reverse path. The Reply Path TLV as defined in [RFC7110] is for the reverse path. The Reply Path TLV as defined in [RFC7110] is
used to carry the return path. Reply Mode 5 (Reply via Specified used to carry the return path. Reply Mode 5 (Reply via Specified
Path) is defined in Section 4.1 of [RFC7110]. While using the Path) is defined in Section 4.1 of [RFC7110]. While using the
procedures described in this document, the Reply Mode is set to 5 procedures described in this document, the Reply Mode is set to 5
(Reply via Specified Path), and the Reply Path TLV is included in the (Reply via Specified Path), and the Reply Path TLV is included in the
echo request message as described in [RFC7110]. The Reply Path TLV echo request message as described in [RFC7110]. The Reply Path TLV
is constructed as per Section 4.2 of [RFC7110]. This document is constructed as per Section 4.2 of [RFC7110]. This document
defines three new 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
skipping to change at line 282 skipping to change at line 283
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 usage and to TLVs 1, 16, and 21. This document defines the usage and
skipping to change at line 391 skipping to change at line 392
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. When the A-Flag (as defined in Section 4.4) SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4)
is present, this specifies the SR Algorithm as described in is present, this specifies the SR Algorithm as described in
Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in
[RFC9350]. The SR Algorithm is used by the receiver to derive the [RFC9350]. The SR Algorithm is used by the receiver to derive the
label. When the A-flag is unset, this field has no meaning and label. When the A-Flag is unset, this field has no meaning and
thus MUST be set to zero on transmission 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 (e.g., loopback address). belonging to the node (e.g., loopback address).
SID: Optional 4-octet field containing the labels 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 an Optional SID for SR-MPLS 4.3. Type-D: IPv6 Node Address with an Optional SID for SR-MPLS
skipping to change at line 439 skipping to change at line 441
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. When the A-Flag (as defined in Section 4.4) SR Algorithm: 1 octet. When the A-Flag (as defined in Section 4.4)
is present, this specifies the SR Algorithm as described in is present, this specifies the SR Algorithm as described in
Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in Section 3.1.1 of [RFC8402] or the Flexible Algorithm as defined in
[RFC9350]. The SR Algorithm is used by the receiver to derive the [RFC9350]. The SR Algorithm is used by the receiver to derive the
label. When the A-flag is unset, this field has no meaning and label. When the A-Flag is unset, this field has no meaning and
thus MUST be set to zero (MBZ) on transmission and ignored on thus MUST be set to zero (MBZ) on transmission and ignored on
receipt. 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 The IPv6 Node Address MUST be present. It should be a stable
address belonging to the node (e.g., loopback address). address belonging to the node (e.g., loopback address).
SID: Optional 4-octet field containing the labels 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.
skipping to change at line 467 skipping to change at line 469
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 an SR Algorithm ID in A-Flag: This flag indicates the presence of an SR Algorithm ID in
the "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:
The A-Flag applies to Segment Type-C and Type-D. If the A-Flag The A-Flag applies to Segment Type-C and Type-D. If the A-Flag
appears with the 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
skipping to change at line 507 skipping to change at line 509
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 the 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.
The absence of the Reply Path TLV is treated as a malformed echo The absence of the Reply Path TLV is treated as a malformed echo
request. When an echo request is received, if the responder does not request. When an echo request is received, if the responder does not
support the Reply Mode 5 defined in [RFC7110], an echo reply with the support the Reply Mode 5 defined in [RFC7110], an echo reply with the
return code set to "Malformed echo request received" and the Subcode Return Code set to "Malformed echo request received" and the Subcode
set to zero must be sent back to the initiator according to the rules set to zero must be sent back to the initiator according to the rules
of [RFC8029]. If the echo request message contains a malformed of [RFC8029]. If the echo request message contains a malformed
Segment sub-TLV, such as an incorrect length field, an echo reply Segment sub-TLV, such as an incorrect length field, an echo reply
must be sent back to the initiator with the return code set to must be sent back to the initiator with the Return Code set to
"Malformed echo request received" and the Subcode set to zero. "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 Forwarding echo reply. The responder MUST follow the normal Forwarding
Equivalence Class (FEC) validation procedures as described in Equivalence Class (FEC) validation procedures as described in
[RFC8029] and [RFC8287] and this document does not suggest any change [RFC8029] and [RFC8287] and this document does not suggest any change
to those procedures. When the echo reply has to be sent out, the to those procedures. When the echo reply has to be sent out, the
Reply Path TLV MUST be used to construct the MPLS packet to send out. Reply Path TLV MUST be used to construct the MPLS packet to send out.
skipping to change at line 536 skipping to change at line 538
[RFC8029]. An MPLS packet is constructed with an echo reply in the [RFC8029]. An MPLS packet is constructed with an echo reply in the
payload. The top label MUST be constructed from the first segment of payload. The top label MUST be constructed from the first segment of
the Reply Path TLV. The remaining labels MUST be constructed by the Reply Path TLV. The remaining labels MUST be constructed by
following the order of the segments from the Reply Path TLV. The following the order of the segments from the Reply Path TLV. The
MPLS header of the echo reply MUST be constructed from the segments MPLS header of the echo reply MUST be constructed from the segments
in the Reply Path TLV and MUST NOT add any other label. The S bit is in the Reply Path TLV and MUST NOT add any other label. The S bit is
set for the bottom label as per the MPLS specifications [RFC3032]. set for the bottom label as per the MPLS specifications [RFC3032].
The responder MAY check the reachability of the top label in its own The responder MAY check the reachability of the top label in its own
Label Forwarding Information Base (LFIB) before sending the echo Label Forwarding Information Base (LFIB) before sending the echo
reply. If the top label is unreachable, the responder SHOULD send reply. If the top label is unreachable, the responder SHOULD send
the appropriate return code and follow the 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 does not have IP reachability to the originator, in which case, it
may not be possible to send an echo reply at all. Even if sent (by may not be possible to send an echo reply at all. Even if sent (by
following a default route present on the responder, for example), the 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, the derive the SID from available topology information. Optionally, the
SID 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 the Node-SIDs associated with the IPv4/IPv6 labels based on the Node-SIDs associated with the IPv4/IPv6
addresses. If an optional MPLS SID is present in the Type-C/Type-D addresses. If an optional MPLS SID is present in the Type-C/Type-D
segments, the SID MUST be used to encode the echo reply with MPLS segments, the SID MUST be used to encode the echo reply with MPLS
labels. If the MPLS SID does not match with the IPv4 or IPv6 address labels. If the MPLS SID does not match with the IPv4 or IPv6 address
field in the Type-C or Type-D SID, log information should be field in the Type-C or Type-D SID, log information should be
generated. 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 0x0006, and the be used. The Reply Path Return Code MUST be set to 0x0006, and the
same Reply Path TLV or a new Reply Path TLV MUST be included in the same Reply Path TLV or a new Reply Path TLV MUST be included in the
echo 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" (as 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 the TLV from the echo reply MUST be sent in the next echo request with
TTL incremented by 1. If the initiator node does not support the the TTL incremented by 1. If the initiator node does not support the
return code "Use Reply Path TLV in the echo reply for building the Return Code "Use Reply Path TLV from this echo reply for building the
next echo request", log information should be generated indicating next echo request", log information should be generated indicating
the return code, and the operator may choose to specify the return the Return Code, and the operator may choose to specify the return
path explicitly or use other mechanisms to verify the SR policy. If path explicitly or use other mechanisms to verify the SR Policy. If
the return code is 0x0007 "Local policy does not allow dynamic return the Return Code is 0x0007 "Local policy does not allow dynamic return
path building", it indicates that the intermediate node does not path building", it indicates that the intermediate node does not
support 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 a 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 |
+========+======================================+ +========+=========================================+
| 0x0006 | Use Reply Path TLV in the echo reply | | 0x0006 | Use Reply Path TLV from this echo reply |
| | for building the next echo request | | | for building the next echo request |
+--------+--------------------------------------+ +--------+-----------------------------------------+
Table 1 Table 1
5.5.1. Procedures to Build the Return Path 5.5.1. Procedures to Build the Return Path
To dynamically build the return path for the traceroute procedures, 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.
skipping to change at line 640 skipping to change at line 642
downstream nodes in the path will not know what SRGB to use to downstream nodes in the path will not know what SRGB to use to
translate the IP address to a label. As the ABR added its own node translate the IP address to a label. As the ABR added its own node
label, it is guaranteed that this ABR will be in the return path and 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 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 0x0006 MUST be set in the echo reply to indicate that the 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 next echo request MUST use the return path from the Reply Path TLV in
the echo reply. ASBR should locally decide the outgoing interface the echo reply. ASBR should locally decide the outgoing interface
for 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. The Reply Path TLV is built by adding two Segment sub-TLVs. TLV. The Reply Path TLV is built by adding two Segment sub-TLVs.
The top Segment sub-TLV consists of the ASBR's Node-SID, and the The top Segment sub-TLV consists of the ASBR's Node-SID, and the
second segment consists of the EPE-SID in the reverse direction to second segment consists of the EPE-SID in the reverse direction to
reach the AS from which the OAM packet was received. The type of reach the AS from which the OAM packet was received. The type of
skipping to change at line 668 skipping to change at line 670
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 0x0006 and send the newly constructed Reply Path TLV Return Code to 0x0006 and send the newly constructed Reply Path TLV
in 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 0x0006 in the echo reply message as there is Path TLV Return Code to 0x0006 in the echo reply message as there is
no 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 to 0x0007 to indicate that local policies do not the Return Code to 0x0007 to indicate that local policies do not
allow the dynamic return path building. allow the dynamic return path building.
+========+==========================================================+ +========+==========================================================+
| Value | Meaning | | Value | Meaning |
+========+==========================================================+ +========+==========================================================+
| 0x0007 | Local policy does not allow | | 0x0007 | Local policy does not allow |
| | dynamic return path building | | | dynamic return path building |
+--------+----------------------------------------------------------+ +--------+----------------------------------------------------------+
Table 2 Table 2
skipping to change at line 726 skipping to change at line 728
described in [RFC8029]. described in [RFC8029].
7. IANA Considerations 7. IANA Considerations
7.1. Segment Sub-TLV 7.1. Segment Sub-TLV
IANA has assigned three new sub-TLVs from the "Sub-TLVs for TLV Types 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) 1, 16, and 21" registry of the "Multiprotocol Label Switching (MPLS)
Label Switched Paths (LSPs) Ping Parameters" registry group. Label Switched Paths (LSPs) Ping Parameters" registry group.
+==========+====================================+=============+ +==========+=====================================+=============+
| Sub-Type | Sub-TLV Name | Reference | | Sub-Type | Sub-TLV Name | Reference |
+==========+====================================+=============+ +==========+=====================================+=============+
| 46 | SID only in the form of MPLS label | Section 4.1 | | 46 | SID only, in the form of MPLS label | Section 4.1 |
| | | of RFC 9716 | | | | of RFC 9716 |
+----------+------------------------------------+-------------+ +----------+-------------------------------------+-------------+
| 47 | IPv4 Node Address with an optional | Section 4.2 | | 47 | IPv4 Node Address with an optional | Section 4.2 |
| | SID for SR-MPLS | of RFC 9716 | | | SID for SR-MPLS | of RFC 9716 |
+----------+------------------------------------+-------------+ +----------+-------------------------------------+-------------+
| 48 | IPv6 Node Address with an optional | Section 4.3 | | 48 | IPv6 Node Address with an optional | Section 4.3 |
| | SID for SR-MPLS | of RFC 9716 | | | SID for SR-MPLS | of RFC 9716 |
+----------+------------------------------------+-------------+ +----------+-------------------------------------+-------------+
Table 3 Table 3
The allocation of code points for the Segment sub-TLVs should be done The code points for the Segment sub-TLVs have been registered in the
from the Standards Action range (0-16383). Standards Action range (0-16383).
7.2. New Registry for Segment ID Sub-TLV Flags 7.2. New Registry for Segment ID Sub-TLV Flags
IANA has created a new "Segment ID Sub-TLV Flags" registry (see IANA has created a new "Segment ID Sub-TLV Flags" registry (see
Section 4.4) under the "Multiprotocol Label Switching (MPLS) Label Section 4.4) under the "Multiprotocol Label Switching (MPLS) Label
Switched Paths (LSPs) Ping Parameters" registry group. 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 (the most significant TLV flags field. The flags are numbered from 0 (the most significant
bit and 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 RFC 9716 | | 1 | A-Flag | Section 4.4 of RFC 9716 |
+------------+--------+-------------------------+ +------------+--------+-------------------------+
Table 4 Table 4
7.3. Reply Path Return Codes Registry 7.3. Reply Path Return Codes Registry
IANA has assigned 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 group. Switched Paths (LSPs) Ping Parameters" registry group.
+========+=========================================+===========+ +========+=========================================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+========+=========================================+===========+ +========+=========================================+===========+
| 0x0006 | Use Reply Path TLV from this echo reply | RFC 9716 | | 0x0006 | Use Reply Path TLV from this echo reply | RFC 9716 |
| | for building the next echo request | | | | for building the next echo request | |
+--------+-----------------------------------------+-----------+ +--------+-----------------------------------------+-----------+
| 0x0007 | Local policy does not allow dynamic | RFC 9716 | | 0x0007 | Local policy does not allow dynamic | RFC 9716 |
| | return path building | | | | return path building | |
+--------+-----------------------------------------+-----------+ +--------+-----------------------------------------+-----------+
Table 5 Table 5
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. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at line 903 skipping to change at line 905
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/IS-IS are used to flood 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 in each AS. ASBR1, ASBR2, ASBR3, and ASBR4 advertise BGP EPE-
SIDs for the inter-AS links. The topologies 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 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 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 described in [RFC9086]. The example uses EPE-SIDs for the inter-AS
links, but the same could be achieved using Adjacency-SIDs advertised links, but the same could be achieved using Adjacency-SIDs advertised
for a passive IGP link. for a passive IGP link.
The description in this document uses the notations below for SIDs. The description in this document uses the notations below for 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.
skipping to change at line 1053 skipping to change at line 1055
based on its own SRGB. When the traceroute procedure crosses the based on its own SRGB. When the traceroute procedure crosses the
border ASBR1, head-end PE1 should send a Type-A segment for N-PE1 border ASBR1, head-end PE1 should send a Type-A segment for N-PE1
based on the label derived from ASBR1's SRGB. This is required based on the label derived from ASBR1's SRGB. This is required
because ASBR4, P3, P4, etc. may not have the topology information to because ASBR4, P3, P4, etc. may not have the topology information to
derive SRGB for PE1. After the traceroute procedure reaches ASBR4, derive SRGB for PE1. After the traceroute procedure reaches ASBR4,
the return path will be [N-PE1 (Type-A with the label based on the return path will be [N-PE1 (Type-A with the label based on
ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASBR4 (Type-C)]. ASBR1's SRGB), EPE-ASBR4-ASBR1, N-ASBR4 (Type-C)].
If the packet needs to follow a 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 a (as defined in [RFC9350]), a Type-C Segment sub-TLV with a
corresponding algorithm field set should be used. The A-flag should corresponding algorithm field set should be used. The A-Flag should
be set to indicate that the SID corresponding to the algorithm should be set to indicate that the SID corresponding to the algorithm should
be used. be used.
To extend the example to three or more ASes, let us consider a To extend the example to three or more ASes, let us consider a
traceroute from PE1 to PE5 in Figure 1. In this example, the PE1 to traceroute from PE1 to PE5 in Figure 1. In this example, the PE1 to
PE5 path has to cross three domains: AS1, AS2, and AS3. Let us PE5 path has to cross three domains: AS1, AS2, and AS3. Let us
consider a path from PE1 to PE5 that goes through [PE1, ASBR1, ASBR4, consider a path from PE1 to PE5 that goes through [PE1, ASBR1, ASBR4,
ASBR6, ASBR8, PE5]. When the traceroute procedure is visiting the ASBR6, ASBR8, PE5]. When the traceroute procedure is visiting the
nodes in AS1, the Reply Path TLV sent from the head-end consists of nodes in AS1, the Reply Path TLV sent from the head-end consists of
[N-PE1]. When the traceroute procedure reaches the ASBR4, the return [N-PE1]. When the traceroute procedure reaches the ASBR4, the return
skipping to change at line 1083 skipping to change at line 1085
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 with multiple instances of IGP deployed on the multi-level IGP or with multiple instances of IGP deployed on the
same node. The return path computation for this topology is similar same node. The return path computation for this topology is similar
to 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.
A.1.3. Procedures for Building Reply Path TLV Dynamically A.1.3. Procedures for Building Reply Path TLV Dynamically
Let us consider the 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 following label stack: Policy path built from PE1 to PE4 with the following label stack:
N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute N-P1, N-ASBR1, EPE-ASBR1-ASBR4, N-PE4. PE1 begins traceroute
procedures with the TTL set to 1 and includes [N-PE1] in the Reply procedures with the TTL set to 1 and includes [N-PE1] in the Reply
Path TLV. The traceroute packet TTL expires on P1, and P1 processes Path TLV. The traceroute packet TTL expires on P1, and P1 processes
the traceroute as per the procedures described in [RFC8029] and the traceroute as per the procedures described in [RFC8029] and
[RFC8287]. P1 sends an echo reply with the same Reply Path TLV with [RFC8287]. P1 sends an echo reply with the same Reply Path TLV with
the reply path return code set to 6. The return code of the echo the Reply Path Return Code set to 6. The Return Code of the echo
reply itself is set to the return code as per [RFC8029] and reply itself is set to the Return Code as per [RFC8029] and
[RFC8287]. This traceroute doesn't need any changes to the Reply [RFC8287]. This traceroute doesn't need any changes to the Reply
Path TLV until it leaves AS1. The same Reply Path TLV that is Path TLV until it leaves AS1. The same Reply Path TLV that is
received may be included in the echo reply by P1 and P2, or no Reply received may be included in the echo reply by P1 and P2, or no Reply
Path TLV is included so that the head-end continues to use the same Path TLV is included so that the head-end continues to use the same
return path in the echo request that it used to send the previous return path in the echo request that it used to send the previous
echo request. 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 0x0006. Then, PE1 should use and set the Reply Path Return Code to 0x0006. Then, PE1 should use
this Reply Path TLV in subsequent echo requests. In this example, this Reply Path TLV in subsequent echo requests. In this example,
when the subsequent echo request reaches P3, it should use this Reply when the subsequent echo request reaches P3, it should use this Reply
Path TLV for sending the echo reply. The same Reply Path TLV is Path TLV for sending the echo reply. The same Reply Path TLV is
sufficient for any router in AS2 to send the reply. This is because sufficient for any router in AS2 to send the reply. This is because
the first label (N-ASBR4) can direct the echo reply to ASBR4 and the the first label (N-ASBR4) can direct the echo reply to ASBR4 and the
second one (EPE-ASBR4-ASBR1) can direct the echo reply to AS1. Once second one (EPE-ASBR4-ASBR1) can direct the echo reply to AS1. Once
the echo reply reaches AS1, normal IP forwarding or the N-PE1 helps the echo reply reaches AS1, normal IP forwarding or the N-PE1 helps
it to 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. This is done by following the same procedure for each multiple ASes. This is done by following the same procedure for each
ASBR, i.e., adding Node-SIDs and EPE-SIDs on receiving echo requests ASBR, i.e., adding Node-SIDs and EPE-SIDs on receiving echo requests
from neighboring ASes. from neighboring ASes.
Let us consider the 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 the 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 0x0006. The Reply echo reply), and sets the Reply Path Return Code to 0x0006. The
Path TLV in the echo reply from ABR1 consists of [N-ABR1, N-PE1]. Reply Path TLV in the echo reply from ABR1 consists of [N-ABR1,
The next echo request with a TTL of 2 reaches the P node. It is an N-PE1]. The next echo request with a TTL of 2 reaches the P node.
internal node, so it does not change the return path. The echo It is an internal node, so it does not change the return path. The
request with a TTL of 3 reaches ABR2, and it adds its node label so echo request with a TTL of 3 reaches ABR2, and it adds its node label
the Reply Path TLV sent in the echo reply will be [N-ABR2, N-ABR1, so the Reply Path TLV sent in the echo reply will be [N-ABR2, N-ABR1,
N-PE1]. The echo request with a TTL of 4 reaches PE4, and it sends N-PE1]. The echo request with a TTL of 4 reaches PE4, and it sends
an echo reply return code as an egress. PE4 does not include any an echo reply Return Code as an egress. PE4 does not include any
Reply Path TLVs in the echo reply. The above example assumes a Reply Path TLVs in the echo reply. The above example assumes a
uniform SRGB throughout the domain. In the case of different SRGBs, uniform SRGB throughout the domain. In the case of different SRGBs,
the top segment will be a Type-C/Type-D segment and all other the top segment will be a Type-C/Type-D segment and all other
segments will be Type-A. Each border node converts the Type-C/Type-D segments will be Type-A. Each border node converts the Type-C/Type-D
segment to Type-A before adding its segment to the Reply Path TLV. segment to Type-A before adding its segment to the Reply Path TLV.
Acknowledgments Acknowledgments
Thanks to Bruno Decraene for suggesting the use of the generic Thanks to Bruno Decraene for suggesting the use of the generic
Segment sub-TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv Segment sub-TLV. Thanks to Adrian Farrel, Huub van Helvoort, Dhruv
 End of changes. 40 change blocks. 
93 lines changed or deleted 95 lines changed or added

This html diff was produced by rfcdiff 1.48.