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

This html diff was produced by rfcdiff 1.48.