rfc9655xml2.original.xml   rfc9655.xml 
<?xml version="1.0"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.2119.xml">
<!ENTITY RFC8287 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8287.xml">
<!ENTITY RFC8029 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8029.xml">
<!ENTITY RFC3443 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.3443.xml">
<!ENTITY RFC5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5226.xml">
<!ENTITY RFC8402 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8402.xml">
<!ENTITY RFC9041 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.9041.xml">
<!ENTITY RFC7942 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7942.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 submissionType="IETF" category="std" docName="draft-ietf-mpls-egress-tlv-fo
r-nil-fec-15"
ipr="trust200902" consensus="true" version="2">
<front>
<title abbrev="Egress Validation in LSP Ping/Traceroute ">
Egress Validation in Label Switched Path Ping and Traceroute Mechanisms</title
>
<author initials="D." surname="Rathi" fullname="Deepti N. Rathi"
role="editor">
<organization>Nokia</organization>
<address>
<postal>
<street>Manyata Embassy Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560045</code>
<country>India</country>
</postal>
<email>deepti.nirmalkumarji_rathi@nokia.com</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde"
role="editor">
<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="Z." surname="Ali" fullname="Zafar Ali">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar"> <!DOCTYPE rfc [
<organization>Cisco Systems, Inc.</organization> <!ENTITY nbsp "&#160;">
<address> <!ENTITY zwsp "&#8203;">
<email>naikumar@cisco.com</email> <!ENTITY nbhy "&#8209;">
</address> <!ENTITY wj "&#8288;">
</author> ]>
<date year="2024"/> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<area>Routing</area> std" docName="draft-ietf-mpls-egress-tlv-for-nil-fec-15" number="9655" ipr="trus
<workgroup>Routing area</workgroup> t200902" consensus="true" version="3" obsoletes="" updates="" xml:lang="en" tocI
<keyword>FEC</keyword> nclude="true" tocDepth="3" symRefs="true" sortRefs="true">
<keyword>OAM</keyword>
<keyword>OSPF</keyword>
<keyword>IS-IS</keyword>
<keyword>SPRING</keyword>
<abstract>
<t>
The MPLS ping and traceroute mechanisms, as described in <xref target="RF
C8029"/>
and the related extensions for Segment Routing (SR) defined in <xref targ
et="RFC8287"/>,
is highly valuable for validating control plane and data plane synchroniz
ation.
In certain environments, only some intermediate or transit nodes may have
been
upgraded to support these validation procedures. A straightforward MPLS p
ing
and traceroute mechanism allows traversing any path without validating th
e
control plane state. <xref target="RFC8029"/> supports this mechanism wit
h the Nil
Forwarding Equivalence Class (FEC). The procedures outlined in <xref targ
et="RFC8029"/>
is primarily applicable when the Nil FEC is used as an intermediate FEC
in the label stack. However, challenges arise when all labels in the labe
l
stack are represented using the Nil FEC.</t>
<t>This document introduces a new Type-Length-Value (TLV) as an extension <front>
<title abbrev="Egress Validation in LSP Ping/Traceroute">Egress Validation
in Label Switched Path Ping and Traceroute Mechanisms</title>
<seriesInfo name="RFC" value="9655"/>
<author initials="D." surname="Rathi" fullname="Deepti N. Rathi" role="edito
r">
<organization>Nokia</organization>
<address>
<postal>
<street>Manyata Embassy Business Park</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560045</code>
<country>India</country>
</postal>
<email>deepti.nirmalkumarji_rathi@nokia.com</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde" role="editor
">
<organization>Juniper Networks Inc.</organization>
<address>
<postal>
<street>Exora Business Park</street>
<city>Bangalore</city>
<region>Karnataka</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="Z." surname="Ali" fullname="Zafar Ali">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>zali@cisco.com</email>
</address>
</author>
<author initials="N." surname="Nainar" fullname="Nagendra Kumar Nainar">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>naikumar@cisco.com</email>
</address>
</author>
<date year="2024" month="November"/>
<area>RTG</area>
<workgroup>mpls</workgroup>
<keyword>FEC</keyword>
<keyword>OAM</keyword>
<keyword>OSPF</keyword>
<keyword>IS-IS</keyword>
<keyword>SPRING</keyword>
<abstract>
<t>
The MPLS ping and traceroute mechanisms described in RFC 8029 and the
related extensions for Segment Routing (SR) defined in RFC 8287 are
highly valuable for validating control plane and data plane
synchronization. In certain environments, only some intermediate or
transit nodes may have been upgraded to support these validation
procedures. A straightforward MPLS ping and traceroute mechanism
allows traversal of any path without validation of the control plane
state. RFC 8029 supports this mechanism with the Nil Forwarding
Equivalence Class (FEC). The procedures outlined in RFC 8029 are
primarily applicable when the Nil FEC is used as an intermediate FEC
in the FEC stack. However, challenges arise when all labels in the
label stack are represented using the Nil FEC.</t>
<t>This document introduces a new Type-Length-Value (TLV) as an extension
to the existing Nil FEC. It describes MPLS ping and traceroute procedures to the existing Nil FEC. It describes MPLS ping and traceroute procedures
using the Nil FEC with this extension to address and overcome these chall enges.</t> using the Nil FEC with this extension to address and overcome these chall enges.</t>
</abstract>
</abstract> </front>
<middle>
<note title="Requirements Language"> <section anchor="intro" numbered="true" toc="default">
<t> <name>Introduction</name>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU <t>Segment routing supports the creation of explicit paths by using one or
LD", more
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" Link-State IGP Segments or BGP Segments defined in <xref target="RFC8402"
in this document are to be interpreted as described in BCP 14 format="default"/>.
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.
</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>Segment routing supports the creation of explicit paths by using one o
r more
Link State IGP Segments or BGP Segments defined in <xref target="RFC8402"
/>.
In certain use cases, the TE paths are In certain use cases, the TE paths are
built using mechanisms described in <xref target="RFC9256"/> built using mechanisms described in <xref target="RFC9256" format="defaul t"/>
by stacking the labels that represent the nodes and links in the explicit path. by stacking the labels that represent the nodes and links in the explicit path.
Controllers are often deployed to construct paths across multi-domain net works. Controllers are often deployed to construct paths across multi-domain net works.
In such deployments, the head-end routers may In such deployments, the headend routers may
have the link state database of its domain and may not be aware of the FE have the link-state database of their domain and may not be aware of the
C FEC
associated with labels that are used by the controller to build associated with labels that are used by the controller to build
paths across multiple domains. A very useful paths across multiple domains. A very useful
Operations, Administration, and Maintenance (OAM) requirement Operations, Administration, and Maintenance (OAM) requirement
is to be able to ping and trace these paths. </t> is to be able to ping and trace these paths. </t>
<t> <t>
<xref target="RFC8029"/> describes a simple and efficient mechanism to de
tect
data-plane failures in MPLS Label Switched Paths (LSPs). It defines
a probe message called an "MPLS echo request" and a response message
called an "MPLS echo reply" for returning the result of the probe.
SR-related extensions to Echo Request/Echo Reply are specified in
<xref target="RFC8287"/>. <xref target="RFC8029"/> primarily provides
mechanisms to validate the data plane and, secondarily, to verify the
consistency of the data plane with the control plane.
It also provides the ability to traverse
Equal-cost Multiple Paths (ECMP) and validate each of the ECMP paths.
Target FEC Stack TLV <xref target="RFC8029"/> contains sub-TLVs that
carry information about
the label. This information gets validated on each node for traceroute
and on the egress for ping.
The use of Target FEC
requires all nodes in the network to have implemented the validation
procedures. All intermediate nodes may not have been upgraded to support
validation procedures. In such cases, it is useful to have the ability to
traverse the paths in ping/traceroute mode without having to obtain the
FEC for each label. </t>
<t>A simple MPLS <xref target="RFC8029" format="default"/> describes a simple and
Echo Request/Echo Reply mechanism allows for traversing the SR Policy efficient mechanism to detect data plane failures in MPLS Label
path without validating the control plane state. <xref target="RFC8029"/> Switched Paths (LSPs). It defines a probe message called an "MPLS
supports this mechanism with FECs like Nil FEC and Generic FEC. echo request" and a response message called an "MPLS echo reply" for
However, there are challenges in reusing the Generic FEC and Nil FEC for returning the result of the probe. SR-related extensions for these
validation of SR policies <xref target="RFC9256"/>. are specified in <xref target="RFC8287" format="default"/>. <xref
Generic IPv4 prefix and Generic IPv6 prefix FECs are used when the target="RFC8029" format="default"/> provides mechanisms primarily to
protocol that is advertising validate the data plane and secondarily to verify the consistency of
the label is unknown. The information that is carried in Generic FEC is the data plane with the control plane. It also provides the ability
the IPv4 or IPv6 prefix and prefix length. Thus Generic FEC types perform to traverse Equal-Cost Multipaths (ECMPs) and validate each of the
an additional control plane validation. However, the details of Generic F ECMP paths. The Target FEC Stack TLV <xref target="RFC8029"
EC and format="default"/> contains sub-TLVs that carry information about the
validation procedures are not very detailed in the <xref target="RFC8029" label. This information gets validated on each node for traceroute and
/>. on the egress for ping. The use of the Target FEC Stack TLV requires all
The use-case mostly specifies inter-AS VPNs as the motivation. nodes
Certain aspects of SR such as anycast SIDs require clear guidelines in the network to have implemented the validation procedures, but all
on how the validation procedure should work. Also, Generic FEC may not be intermediate nodes may not have been upgraded to support validation
widely procedures. In such cases, it is useful to have the ability to
supported and if transit routers are not upgraded to support validation o traverse the paths in ping/traceroute mode without having to obtain
f Generic the FEC for each label. </t>
FEC, traceroute may fail.
On the other hand, Nil FEC consists of the label and there is no other as <t>A simple MPLS echo request/reply mechanism allows for traversing the
sociated SR Policy path without validating the control plane state. <xref
FEC information. Nil FEC is used to traverse the path without validation target="RFC8029" format="default"/> supports this mechanism with FECs
for like the Nil FEC and the Generic
FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix). However, there are c
hallenges in reusing
the Nil FEC and Generic FECs for validation of SR Policies <xref
target="RFC9256" format="default"/>. The Generic IPv4 prefix and Generic
IPv6 prefix FECs are used when the protocol that is advertising the
label is unknown. The information that is carried in the Generic FECs is t
he
IPv4 or IPv6 prefix and prefix length. Thus, the Generic FEC types perform
an additional control plane validation. However, the Generic
FECs and relevant validation procedures are not thoroughly detailed in <xr
ef
target="RFC8029" format="default"/>.
The use case mostly specifies inter-AS (Autonomous System) VPNs as the mo
tivation.
Certain aspects of SR, such as anycast Segment Identifiers (SIDs), requir
e clear guidelines
on how the validation procedure should work. Also, the Generic FECs may n
ot be widely
supported, and if transit routers are not upgraded to support validation
of Generic
FECs, traceroute may fail.
On the other hand, the Nil FEC consists of the label, and there is no oth
er associated
FEC information. The Nil FEC is used to traverse the path without validat
ion for
cases where the FEC is not defined or routers are not upgraded to support the cases where the FEC is not defined or routers are not upgraded to support the
FECs. Thus, it can be used to check any combination of segments on any da ta path. FECs. Thus, it can be used to check any combination of segments on any da ta path.
The procedures described in <xref target="RFC8029"/> are mostly applicabl The procedures described in <xref target="RFC8029" format="default"/> are
e mostly applicable when the
when the Nil FEC is used where the Nil FEC is intermediate in the Nil FEC is used as an intermediate FEC in the FEC stack.
label stack. When all labels in the label-stack is represented using Nil Challenges arise when all labels in the label stack are represented
FEC, using the Nil FEC.</t>
it poses some challenges.</t> <t> <xref target="Problems_with_Nil_FEC" format="default"/> discusses the
<t> <xref target="Problems_with_Nil_FEC"/> discusses the problems problems
associated with using Nil FEC in an MPLS ping/traceroute procedure and associated with using the Nil FEC in an MPLS ping/traceroute procedure, a
<xref target="egress_tlv"/> and <xref target="detail_procedure"/> discuss nd Sections
<xref target="egress_tlv" format="counter"/> and <xref target="detail_pro
cedure" format="counter"/> discuss
simple extensions needed to solve the problem. simple extensions needed to solve the problem.
</t> </t>
<t>The problems and the solutions described in this document apply to <t>The problems and the solutions described in this document apply to the
MPLS data plane. SRv6 is out-of-scope for this document.</t> MPLS data plane. Segment Routing over IPv6 (SRv6) is out of scope for thi
s document.</t>
<section anchor="Requirements_Language" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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='Problems_with_Nil_FEC' title='Problem with Nil FEC'> </section>
<t>The purpose of Nil FEC as described in <xref target="RFC8029"/> is to <section anchor="Problems_with_Nil_FEC" numbered="true" toc="default">
ensure hiding of transit tunnel information and in some cases to avoid fa <name>Problem with Nil FEC</name>
lse <t>The purpose of the Nil FEC, as described in <xref target="RFC8029" form
at="default"/>, is to
ensure that transit tunnel information is hidden and, in some cases, to a
void false
negatives when the FEC information is unknown.</t> negatives when the FEC information is unknown.</t>
<t>This document uses a Nil FEC to represent the complete label stack in <t>This document uses a Nil FEC to represent the complete label stack in a
an n
MPLS Echo Request message in ping and traceroute mode. A single Nil FEC i MPLS echo request message in ping and traceroute mode. A single Nil FEC i
s used s used
in the MPLS Echo Request message irrespective of the number of segments i in the MPLS echo request message irrespective of the number of segments i
n the n the
label stack. As described in sec 4.4.1 of <xref target="RFC8029"/>, label stack. <xref target="RFC8029" format="default" sectionFormat="of" se
"If the outermost FEC of the Target FEC stack is the Nil FEC, then the ction="4.4.1"/> notes:</t>
node MUST skip the Target FEC validation completely." <blockquote><t>
When a router in the label-stack path receives an MPLS If the outermost FEC of the Target FEC stack is the Nil FEC, then the
Echo Request message, there is no definite way to decide whether it is node <bcp14>MUST</bcp14> skip the Target FEC validation completely.</t>
the intended egress router since Nil FEC does not carry any information a </blockquote>
nd no validation <t>When a router in the label stack path receives an MPLS
echo request message, there is no definite way to decide whether it is
the intended egress router since the Nil FEC does not carry any informati
on and no validation
is performed by the router. is performed by the router.
So there is a high possibility that the packet may be mis-forwarded to an Thus, there is a high possibility that the packet may be misforwarded to
incorrect an incorrect
destination but the MPLS Echo Reply might still return success.</t> destination but the MPLS echo reply might still return success.</t>
<t>
<t> To mitigate this issue, it is necessary to include additional information,
To mitigate this issue, it is necessary to include additional along with the Nil FEC, in the MPLS echo request message in both ping and
information in the MPLS Echo Request message in both ping and traceroute traceroute modes and to perform minimal validation on the egress/destination
modes, along with the Nil FEC, to perform minimal validation on the router.
egress/destination router. This will enable the router to send appropriat This will enable the router to send appropriate
e
success and failure information to the headend router of the SR Policy. T his supplementary success and failure information to the headend router of the SR Policy. T his supplementary
information should assist in reporting transit router details to the information should assist in reporting transit router details to the
headend router, which can be utilized by an offline application headend router, which can be utilized by an offline application
to validate the traceroute path. to validate the traceroute path.
</t> </t>
<t>Consequently, the inclusion of egress information in the MPLS <t>Consequently, the inclusion of egress information in the MPLS
Echo Request messages in ping and traceroute modes will facilitate echo request messages in ping and traceroute modes will facilitate
the validation of Nil FEC on the egress router ensuring the correct the validation of the Nil FEC on the egress router, ensuring the correct
destination. It can be employed to destination. Egress information can be employed to
verify any combination of segments on any path without requiring verify any combination of segments on any path without requiring
upgrades to transit nodes. The code point used for upgrades to transit nodes.
Egress TLV is from the range 32768-65535 and can be silently dropped The Egress TLV can be silently dropped if not recognized; alternately,
if not recognized as per <xref target="RFC8029"/> and as per clarificatio it may be stepped over, or an error message may be sent (per
ns from <xref target="RFC8029" format="default"/> and the clarifications in
<xref target="RFC9041"/>. Alternately, the un-recognized TLV may be stepp <xref target="RFC9041" format="default"/> regarding code points in the ra
ed over or nge 32768-65535).
an error message may be sent. </t> </t>
<t>If a transit node does not recognize the Egress TLV and chooses to sil
ently <t>If a transit node does not recognize the Egress TLV and chooses to sile
drop or step over the Egress TLV, ntly
headend will continue to send Egress TLV in the next echo request drop or step over the Egress TLV, the
message and if egress recognizes the Egress TLV, egress validation headend will continue to send the Egress TLV in the next echo request
message, and if egress recognizes the Egress TLV, egress validation
will be executed at the egress. will be executed at the egress.
If a transit node does not recognize the Egress TLV and chooses to send a n error If a transit node does not recognize the Egress TLV and chooses to send a n error
message, the headend will log the message for informational purposes and message, the headend will log the message for informational purposes and
continue to send echo requests with Egress TLV, with TTL incremented. continue to send echo requests with the Egress TLV, with the TTL incremen ted.
If the egress node does not recognize the Egress TLV and chooses to silen tly If the egress node does not recognize the Egress TLV and chooses to silen tly
drop or step over the Egress TLV, egress validation will not be done drop or step over the Egress TLV, egress validation will not be done,
and the ping/traceroute procedure will proceed as if Egress TLV is and the ping/traceroute procedure will proceed as if the Egress TLV were
not received. not received.
</t> </t>
</section>
</section> <section anchor="egress_tlv" numbered="true" toc="default">
<name>Egress TLV</name>
<section title="Egress TLV" anchor='egress_tlv'>
<t> <t>
The Egress TLV MAY be included in an MPLS Echo Request message. The Egress TLV <bcp14>MAY</bcp14> be included in an MPLS echo request mes
It is an optional TLV and, if present, MUST appear before the sage.
FEC stack TLV in the MPLS Echo Request packet. This TLV can It is an optional TLV and, if present, <bcp14>MUST</bcp14> appear before
only be used in LSP ping/traceroute requests, generated by the
the head-end node of an LSP or SR policy for which verification Target FEC Stack TLV in the MPLS echo request packet. This TLV can
only be used in LSP ping/traceroute requests that are generated by
the headend node of an LSP or SR Policy for which verification
is performed. In cases where multiple Nil FECs are present in is performed. In cases where multiple Nil FECs are present in
the Target FEC Stack TLV, the Egress TLV must be added corresponding the Target FEC Stack TLV, the Egress TLV must be added corresponding
to the ultimate egress of the label stack. Explicit paths can be to the ultimate egress of the label stack. Explicit paths can be
created using Node-SID, Adj-SID, created using Node-SID, Adj-SID,
Binding-SID, etc. The address field of the Egress TLV must be derived Binding SID, etc. The Address field of the Egress TLV must be derived
from the path egress/destination. The format is as specified below: from the path egress/destination. The format is as specified in <xref tar
</t> get="pic_egress_tlv"/>.
</t>
<figure anchor="pic_egress_tlv" title="Egress TLV"> <figure anchor="pic_egress_tlv">
<artwork> <name>Egress TLV</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32771 (Egress TLV) | Length | | Type = 32771 (Egress TLV) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (4 or 16 octets) | | Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</artwork> <dl>
</figure> <dt>Type:</dt>
<t>Type : 32771 (<xref target="tlv"/>)</t> <dd>32771 (<xref target="tlv" format="default"/>)</dd>
<t>Length : variable based on IPV4/IPV6 address.
Length excludes the length of the Type and Length
fields. Length will be 4 octets for IPv4 and
16 octets for IPv6.</t>
<t>Address : This field carries a valid IPv4 address of length
4 octets or a valid IPv6 address of length 16 octe
ts.
It can be obtained from the egress of the path.
It corresponds to the last label in the label stac
k or
the SR policy endpoint field
<xref target="I.D-ietf-idr-sr-policy-safi"/>.
</t>
</section>
<section title="Procedure" anchor='detail_procedure'>
<t>This section describes aspects of LSP ping and traceroute operations that <dt>Length:</dt>
require further considerations beyond <xref target="RFC8029"/>.</t> <dd>Variable (4 octets for IPv4 addresses and 16 octets for IPv6 addresses).
<section title="Sending Egress TLV in MPLS Echo Request" anchor='send_proced Length excludes the length of the Type and Length fields.
ure'> </dd>
<t>As previously mentioned, when the sender node constructs
an Echo Request with a Target FEC Stack TLV, the Egress TLV,
if present, MUST appear before the Target FEC Stack TLV in
the MPLS Echo Request packet.</t>
<section title="Ping Mode" anchor='ping_procedure'>
<t>When the sender node constructs an Echo Request with target FEC Stack <dt>Address:</dt>
TLV <dd>This field carries a valid 4-octet IPv4 address or a valid
16-octet IPv6 address. The address can be obtained from the egress of the
path and corresponds to the last label in the label stack or the SR Policy
Endpoint field <xref target="I-D.ietf-idr-sr-policy-safi"
format="default"/>.</dd>
</dl>
</section>
<section anchor="detail_procedure" numbered="true" toc="default">
<name>Procedure</name>
<t>This section describes aspects of LSP ping and traceroute operations th
at
require further considerations beyond those detailed in <xref target="RFC
8029" format="default"/>.</t>
<section anchor="send_procedure" numbered="true" toc="default">
<name>Sending Egress TLV in MPLS Echo Request</name>
<t>As previously mentioned, when the sender node constructs
an echo request with a Target FEC Stack TLV, the Egress TLV,
if present, <bcp14>MUST</bcp14> appear before the Target FEC Stack TLV
in
the MPLS echo request packet.</t>
<section anchor="ping_procedure" numbered="true" toc="default">
<name>Ping Mode</name>
<t>When the sender node constructs an echo request with a Target FEC S
tack TLV
that contains a single Nil FEC corresponding to the last segment of the that contains a single Nil FEC corresponding to the last segment of the
SR Policy path, the sender node MUST add an Egress TLV with the a SR Policy path, the sender node <bcp14>MUST</bcp14> add an Egress
ddress obtained from TLV with the address obtained from
the SR policy endpoint field <xref target="I.D-ietf-idr-sr-policy the SR Policy Endpoint field <xref target="I-D.ietf-idr-sr-policy
-safi"/>. -safi" format="default"/>.
The Label value in the Nil FEC MAY be set to zero when a single N The Label value in the Nil FEC <bcp14>MAY</bcp14> be set to zero
il FEC is when a single Nil FEC is
added for multiple labels in the label stack. added for multiple labels in the label stack.
In case the endpoint is not specified or is equal to zero In case the endpoint is not specified or is equal to zero
(Sec 8.8.1 <xref target="RFC9256"/>), the sender MUST use the (<xref target="RFC9256" format="default" sectionFormat="of" secti on="8.8.1"/>), the sender <bcp14>MUST</bcp14> use the
address corresponding to the last segment of the SR Policy address corresponding to the last segment of the SR Policy
in the address field for in the Address field of
Egress TLV. Some specific cases on how to derive the address fiel the Egress TLV. Some specific cases on how to derive the Address
d field
in the Egress TLV are listed below:</t> in the Egress TLV are listed below:</t>
<t> <ul spacing="normal">
<list> <li>
<t>a. If the last SID in the SR policy is an Adj-SID, <t>If the last SID in the SR Policy is an Adj-SID,
the address field in the Egress TLV is derived from the node the Address field in the Egress TLV is derived from the node
at the remote end of the corresponding adjacency.</t> at the remote end of the corresponding adjacency.</t>
<t>b. If the last SID in the SR policy is a Binding SID, </li>
the address field in the Egress TLV is derived from the <li>
<t>If the last SID in the SR Policy is a Binding SID,
the Address field in the Egress TLV is derived from the
last node of the path represented by the Binding SID.</t> last node of the path represented by the Binding SID.</t>
</list> </li>
</t> </ul>
</section>
</section> <section anchor="traceroute_procedure" numbered="true" toc="default">
<name>Traceroute Mode</name>
<section title="Traceroute Mode" anchor='traceroute_procedure'> <t>When the sender node builds an echo request with a Target FEC Stack
TLV
<t>When the sender node builds an Echo Request with target FEC Stack TLV that contains a Nil FEC corresponding to the last segment of the
that contains Nil FEC corresponding to the last segment of the se segment list of
gment-list of the SR Policy, the sender node <bcp14>MUST</bcp14> add an Egress
the SR Policy, the sender node MUST add an Egress TLV with the ad TLV with the address obtained
dress obtained from the SR Policy Endpoint field
from the SR policy endpoint field <xref target="I-D.ietf-idr-sr-policy-safi" format="default"/>.
<xref target="I.D-ietf-idr-sr-policy-safi"/>. </t>
</t>
<t> Although there is no requirement to do so, an implementatio <t> Although there is no requirement to do so, an implementation
n MAY <bcp14>MAY</bcp14> send multiple Nil FECs if that makes it easier
send multiple Nil FECs if that makes it easier for the for the implementation. If the SR Policy headend sends
implementation. multiple Nil FECs, the last one <bcp14>MUST</bcp14> correspond to
In case the SR Policy headend sends multiple Nil FECs the last one MUST the Egress TLV. The Label value in the Nil FEC <bcp14>MAY</bcp14>
correspond to the Egress TLV. be set to zero for the last Nil FEC. If the endpoint is not
The Label value in the Nil FEC MAY be set to zero for the last Ni specified or is equal to zero (<xref target="RFC9256"
l FEC. format="default" sectionFormat="of" section="8.8.1"/>), the sender
In case the endpoint is not specified or is equal to zero <bcp14>MUST</bcp14> use the address corresponding to the last
(Sec 8.8.1 <xref target="RFC9256"/>), the sender MUST use the add segment endpoint of the SR Policy path (i.e., the ultimate egress is u
ress corresponding sed as the
to the last segment endpoint of the SR Policy path i.e. ultimate address in the Egress TLV).
egress </t>
as the address for the Egress TLV. </section>
</t> <section anchor="detail_example" numbered="true" toc="default">
</section> <name>Detailed Example</name>
<section title="Detailed Example" anchor='detail_example'> <figure anchor="example_topology">
<figure anchor="example_topology" title="Egress TLV processing on sample <name>Egress TLV Processing in Sample Topology</name>
topology"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
----R3---- ----R3----
/ (1003) \ / (1003) \
(1001) / \(1005) (1007) (1001) / \(1005) (1007)
R1----R2(1002) R5----R6----R7(address X) R1----R2(1002) R5----R6----R7(address X)
\ / (1006) \ / (1006)
\ (1004) / \ (1004) /
----R4---- ----R4----
</artwork> ]]></artwork>
</figure> </figure>
<t>Consider the SR Policy configured on router R1, to destination X, <t>Consider the SR Policy configured on router R1 to destination X,
configured with label-stack as 1002, 1004, 1007. configured with label stack as 1002, 1004, 1007.
Segment 1007 belongs to R7, which has the address X Segment 1007 belongs to R7, which has the address X
locally configured on it. locally configured on it.
</t> </t>
<t>Let us look at an example of a ping Echo Request message. <t>Let us look at an example of a ping echo request message. The
The Echo Request message contains a Target FEC stack TLV with the echo request message contains a Target FEC Stack TLV with the Nil
Nil FEC sub-TLV. FEC sub-TLV. An Egress TLV is added before the Target FEC Stack
An Egress TLV is added before the Target FEC Stack TLV. The addre TLV. The Address field contains X (corresponding to a locally
ss field contains configured address on R7). X could be an IPv4 or IPv6 address, and
X (corresponding to a locally configured address on R7). X could the Length field in the Egress TLV will be either 4 or 16 octets,
be an based on the address type of address X.
IPv4 or IPv6 address and the Length field in the Egress TLV will </t>
be 4 or 16 <t>Let us look at an example of an echo request message in a
based on the address X's address type. traceroute packet. The echo request message contains a Target FEC
</t> Stack TLV with the Nil FEC sub-TLV corresponding to the complete
<t>Let us look at an example of an Echo Request message in a tracerou label stack (1002, 1004, 1007). An Egress TLV is added before the
te packet. Target FEC Stack TLV. The Address field contains X (corresponding
The Echo Request message contains a Target FEC stack TLV with the Nil FE to a locally configured address on destination R7). X could be an
C sub-TLV IPv4 or IPv6 address, and the Length field in the Egress TLV will be e
corresponding to the complete label-stack (1002, 1004, 1007). ither
An Egress TLV is added before the Target FEC Stack TLV. 4 or 16 octets, based on the address type of address X. If the
The address field contains destination/endpoint is set to zero (as in the case of the
X (corresponding to a locally configured address on destination R color-only SR Policy), the sender should use the endpoint of segment
7). X could be an 1007 (the last segment in the segment list) as the address for the
IPv4 or IPv6 address and the Length field in the Egress TLV will Egress TLV.
be 4 or 16
based on the address X's address type.
If the destination/endpoint is set to zero (as in the case of the
color-only SR Policy)
sender should use the endpoint of segment 1007 (the last segment
in the segment list)
as an address for the Egress TLV.
</t>
</section>
</section>
<section title="Receiving Egress TLV in MPLS Echo Request"
anchor='recv_procedure'>
<t>Any node that receives the MPLS Echo Request message and processes it, </t>
is referred to as the "receiver". In case of the ping procedure, </section>
</section>
<section anchor="recv_procedure" numbered="true" toc="default">
<name>Receiving Egress TLV in MPLS Echo Request</name>
<t>Any node that receives an MPLS echo request message and processes it
is referred to as the "receiver". In the case of the ping procedure,
the actual destination/egress is the receiver. the actual destination/egress is the receiver.
In the case of traceroute, every node is a receiver. In the case of traceroute, every node is a receiver.
This document does not propose any change in the processing
for Nil FEC as defined in This document does not propose any change in the processing of the
<xref target="RFC8029"/> in the Target FEC stack TLV Node that receives Nil FEC (as defined in <xref target="RFC8029" format="default"/>) in
an MPLS echo request. The presence of Egress TLV does not affect the the node that receives an MPLS echo request with a Target FEC Stack
validation of Target FEC Stack sub-TLV at FEC-stack-depth TLV. The presence of the Egress TLV does not affect the validation
if it is different than Nil FEC.</t> of the Target FEC Stack sub-TLV at FEC-stack-depth if it is
<t>Additional processing MUST be done for the Egress TLV on different than Nil FEC.</t>
the receiver node as follows: <t>Additional processing <bcp14>MUST</bcp14> be done for the Egress TLV
</t> on
<t>1. If the Label-stack-depth is greater than 0 and the Target FEC Stack the receiver node as follows. Note that &lt;RSC&gt; refers to the Retur
n Subcode.
</t>
<ol spacing="normal" type="1">
<li><t>If the Label-stack-depth is greater than 0 and the Target FEC Sta
ck
sub-TLV at FEC-stack-depth is Nil FEC, sub-TLV at FEC-stack-depth is Nil FEC,
set Best-return-code to 8 ("Label switched at stack-depth") set Best-return-code to 8 ("Label switched at stack-depth &lt;RSC&gt;")
and Best-return-subcode to Label-stack-depth to report transit switchin and Best-rtn-subcode to Label-stack-depth to report transit switching
g in the MPLS echo reply message.</t></li>
in MPLS Echo Reply message.</t> <li><t>If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
<t>2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is Nil FEC, then do a lookup for an exact match of the
FEC-stack-depth is Nil FEC then do the lookup for an exact match of the Address field of the Egress TLV to any of the locally configured inter
Egress TLV address field to any of the locally configured interfaces faces
or loopback addresses.</t> or loopback addresses.</t>
<t> 2a. If the Egress TLV address lookup succeeds, <ol spacing="normal" type="a">
<li>If the Egress TLV address lookup succeeds,
set Best-return-code to 36 ("Replying router is an egress for the set Best-return-code to 36 ("Replying router is an egress for the
address in Egress TLV for the FEC at stack depth RSC") address in the Egress TLV for the FEC at stack depth &lt;RSC&gt;")
(<xref target="ret_code"/>) in MPLS Echo Reply message.</t>
<t> 2b. If the Egress TLV address lookup fails,
set the Best-return-code to 10, "Mapping for this FEC is not the given
label at stack-depth RSC" </t>
<t> 3. In cases where multiple Nil FECs are sent from the SR Policy hea
dend,
one each corresponding to the
labels in the label stack along with Egress TLV, when the packet reache
s the egress,
the number of labels in the received packet (Size of stack-R) becomes z
ero or
a label with Bottom-of-Stack bit set to 1 is processed, all Nil FEC
sub-TLVs MUST be removed and the Egress TLV MUST be validated.
</t>
</section> (<xref target="ret_code" format="default"/>) in the MPLS echo reply mes
</section> sage.</li>
<li>If the Egress TLV address lookup fails,
set the Best-return-code to 10 ("Mapping for this FEC is not the given
label at stack-depth &lt;RSC&gt;").</li>
</ol>
</li>
<li><t>In cases where multiple Nil FECs are sent from the SR Policy head
end,
one each corresponding to the labels in the label stack along with the
Egress TLV, when the packet reaches the egress, the number of labels in the rece
ived packet (Size of stack-R) becomes zero or a label with the Bottom-of-Stack b
it set to 1 is processed, all Nil FEC sub-TLVs <bcp14>MUST</bcp14> be removed an
d the Egress TLV <bcp14>MUST</bcp14> be validated.</t></li>
<section anchor='backward_compatibility' title='Backward Compatibility'> </ol>
<t>The extensions defined in this document is backward compatible with
procedures described in <xref target="RFC8029"/>. A Router that does not
support Egress TLV, will ignore it and use current the Nil-FEC procedures
described in <xref target="RFC8029"/>.
</t>
<t>When the egress node in the path does not support the extensions defined
in this document egress validation will not be done and Best-return-code
as 3
("Replying router is an egress for the FEC at stack-depth") and Best-retu
rn-
subcode set to stack-depth to will be set in the MPLS Echo Reply message.
</t>
<t>When the transit node in the path does not support the extensions defined
in this document Best-return-code as 8 ("Label switched at stack-depth")
and
Best-return-subcode as Label-stack-depth to report transit switching will
be
set in the MPLS Echo Reply message.
</t>
</section>
<section anchor="iana_con" title="IANA Considerations">
<t>The code points in section <xref target="tlv"/> and <xref target="ret_cod
e"/>
have been assigned by <xref target="IANA"/> by early allocation on 2023-1
0-05
and 2021-11-08 respectively.
</t>
<section anchor="tlv" title="New TLV">
<t> <xref target="IANA"/> is requested to update the early </section>
allocation for Egress TLV in the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping
Parameters" in the "TLVs" sub-registry to reference this
document when published as an RFC.
</t>
<texttable anchor="iana_tlvs_tbl" title="TLVs Sub-Registry">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol>
<ttcol align="left">Reference</ttcol>
<c>32771</c>
<c>Egress TLV</c>
<c><xref target="egress_tlv"/> of this document</c>
</texttable>
</section> </section>
<section anchor="ret_code" title="New Return code"> <section anchor="backward_compatibility" numbered="true" toc="default">
<name>Backward Compatibility</name>
<t> <xref target="IANA"/> is requested to update the <t>The extensions defined in this document are backward compatible with th
early allocation of the Return Code for e
"Replying router is an egress for the address in Egress TLV" in the procedures described in <xref target="RFC8029" format="default"/>. A rout
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping er that does not
Parameters" in the "Return Codes" sub-registry to reference this support the Egress TLV will ignore it and use the Nil FEC procedures
document when published as an RFC. described in <xref target="RFC8029" format="default"/>.
</t> </t>
<texttable anchor="iana_return_code_tbl" title="Return code Sub-Registr <t>
y"> When the egress node in the path does not support the extensions
<ttcol align="left">Value</ttcol> defined in this document, egress validation will not be done, and Best-return-c
<ttcol align="center">Description</ttcol> ode will be set to 3 ("Replying router is an egress for the FEC at stack-depth &
<ttcol align="left">Reference</ttcol> lt;RSC&gt;") and Best-rtn-subcode to stack-depth in
<c>36</c> the MPLS echo reply message.
<c>Replying router is an egress for the </t>
address in Egress TLV for the FEC at stack depth RSC</c> <t>When the transit node in the path does not support the extensions defin
<c><xref target="recv_procedure"/> of this document</c> ed
</texttable> in this document, Best-return-code will be set to 8 ("Label switched at s
tack-depth &lt;RSC&gt;") and
Best-rtn-subcode to Label-stack-depth to report transit switching
in the MPLS echo reply message.
</t>
</section> </section>
</section> <section anchor="iana_con" numbered="true" toc="default">
<section title='Security Considerations' anchor='sec-con'> <name>IANA Considerations</name>
<t>This document defines additional MPLS LSP ping TLVs and follows
the mechanisms defined in <xref target="RFC8029"/>.
All the security considerations defined in <xref target="RFC8287"/> will
be applicable for this document and, in addition, they do not impose any
additional security challenges to be considered.
</t>
</section>
<section title='Implementation Status'> <section anchor="tlv" numbered="true" toc="default">
<t>This section is to be removed before publishing as an RFC.</t> <name>New TLV</name>
<t>IANA has added the following entry to the "TLVs" registry within
the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Pi
ng Parameters" registry group <xref target="IANA-MPLS-LSP" format="default"/>:
</t>
<table anchor="iana_tlvs_tbl" align="center">
<name>TLVs Registry</name>
<thead>
<tr>
<th align="left">Type</th>
<th align="left">TLV Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">32771</td>
<td align="left">Egress TLV</td>
<td align="left">RFC 9655</td>
</tr>
</tbody>
</table>
</section>
<section anchor="ret_code" numbered="true" toc="default">
<name>New Return Code</name>
<t> IANA has added the following entry to the "Return Codes" registry
within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (L
SPs) Ping Parameters" registry group <xref target="IANA-MPLS-LSP"
format="default"/>:
</t>
<table anchor="iana_return_code_tbl" align="center">
<name>Return Codes Registry</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Meaning</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">36</td>
<td align="left">Replying router is an egress for the
address in the Egress TLV for the FEC at stack depth &lt;RSC&gt;</td>
<td align="left">RFC 9655</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="sec-con" numbered="true" toc="default">
<name>Security Considerations</name>
<t>RFC-Editor: Please clean up the references cited by this section <t>This document defines an additional TLV for MPLS LSP ping and conforms to
before publication.</t> the mechanisms defined in <xref target="RFC8029" format="default"/>.
<t>This section records the status of known implementations of the All the security considerations defined in <xref target="RFC8287" format=
protocol defined by this specification at the time of posting of this "default"/> apply to this document. This document does not
Internet-Draft, and is based on a proposal described in <xref target="RFC7942 introduce any additional security challenges to be considered.
"/>. </t>
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 and validating Egress TLV</t>
<t>Maturity Level: Released</t>
<t>Coverage: Full</t>
<t>Contact: shraddha@juniper.net</t>
</section>
</section> </section>
<section title='Acknowledgements' anchor='ack'> </middle>
<t> The authors would like to thank Stewart Bryant, Greg Mirsky, Alexander V <back>
ainshtein, <displayreference target="I-D.ietf-idr-sr-policy-safi" to="SR-POLICY-BGP"/>
Sanga Mitra Rajgopal, and Adrian Farrel for their careful review and comm <references>
ents.</t> <name>References</name>
</section> <references>
</middle> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
041.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.2
119.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.8
174.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.9
256.xml"/>
</references>
<references>
<name>Informative References</name>
<back> <reference anchor="IANA-MPLS-LSP" target="http://www.iana.org/assignment
<references title='Normative References'> s/mpls-lsp-ping-parameters">
&RFC9041; <front>
&RFC8402; <title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LS
Ps)
Ping Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119 <!-- [I-D.ietf-idr-sr-policy-safi] IESG state: I-D Exists as of 9/5/24; Updated
"> to long way to add "Ed." for K. Talaulikar-->
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <reference anchor="I-D.ietf-idr-sr-policy-safi" target="https://datatracker.ietf
<author initials="S." surname="Bradner" fullname="S. Bradner"/> .org/doc/html/draft-ietf-idr-sr-policy-safi-10">
<date year="1997" month="March"/> <front>
<abstract> <title>Advertising Segment Routing Policies in BGP</title>
<t>In many standards track documents several words are used to <author initials="S." surname="Previdi" fullname="Stefano Previdi">
signify the requirements in the specification. These words ar <organization>Huawei Technologies</organization>
e often </author>
capitalized. This document defines these words as they should <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
be <organization>Cisco Systems</organization>
interpreted in IETF documents. This document specifies an Int </author>
ernet <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="edi
Best Current Practices for the Internet Community, and request tor">
s <organization>Cisco Systems</organization>
discussion and suggestions for improvements.</t> </author>
</abstract> <author initials="P." surname="Mattes" fullname="Paul Mattes">
</front> <organization>Microsoft</organization>
<seriesInfo name="BCP" value="14"/> </author>
<seriesInfo name="RFC" value="2119"/> <author initials="D." surname="Jain" fullname="Dhanendra Jain">
<seriesInfo name="DOI" value="10.17487/RFC2119"/> <organization>Google</organization>
</reference> </author>
<reference anchor="RFC8029" target="https://www.rfc-editor.org/info/rfc8029 <date month="November" day="7" year="2024"/>
"> </front>
<front> <seriesInfo name="Internet-Draft" value="draft-ietf-idr-sr-policy-safi-10"/>
<title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane </reference>
Failures</title>
<author initials="K." surname="Kompella" fullname="K. Kompella"/> </references>
<author initials="G." surname="Swallow" fullname="G. Swallow"/> </references>
<author initials="C." surname="Pignataro" fullname="C. Pignataro" <section anchor="ack" numbered="false" toc="default">
role="editor"/> <name>Acknowledgements</name>
<author initials="N." surname="Kumar" fullname="N. Kumar"/> <t> The authors would like to thank <contact fullname="Stewart
<author initials="S." surname="Aldrin" fullname="S. Aldrin"/> Bryant"/>, <contact fullname="Greg Mirsky"/>, <contact
<author initials="M." surname="Chen" fullname="M. Chen"/> fullname="Alexander Vainshtein"/>, <contact fullname="Sanga Mitra
<date year="2017" month="March"/> Rajgopal"/>, and <contact fullname="Adrian Farrel"/> for their careful
<abstract> review and comments.</t>
<t>This document describes a simple and efficient mechanism to detect </section>
data-plane failures in Multiprotocol Label Switching (MPLS) La </back>
bel
Switched Paths (LSPs). It defines a probe message called an "
MPLS
echo request" and a response message called an "MPLS echo repl
y" for
returning the result of the probe. The MPLS echo request is i
ntended
to contain sufficient information to check correct operation o
f the
data plane and to verify the data plane against the control pl
ane,
thereby localizing faults.</t>
<t>This document obsoletes RFCs 4379, 6424, 6829, and 7537,
and updates RFC 1122.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8029"/>
<seriesInfo name="DOI" value="10.17487/RFC8029"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174
">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title
>
<author initials="B." surname="Leiba" fullname="B. Leiba"/>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol
specifications. This document aims to reduce the ambiguity by
clarifying that only UPPERCASE usage of the key words have the
defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8287" target="https://www.rfc-editor.org/info/rfc8287
">
<front>
<title>Label Switched Path (LSP) Ping/Traceroute for Segment Routing
(SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) wit
h MPLS
Data Planes</title>
<author initials="N." surname="Kumar" fullname="N. Kumar"
role="editor"/>
<author initials="C." surname="Pignataro" fullname="C. Pignataro"
role="editor"/>
<author initials="G." surname="Swallow" fullname="G. Swallow"/>
<author initials="N." surname="Akiya" fullname="N. Akiya"/>
<author initials="S." surname="Kini" fullname="S. Kini"/>
<author initials="M." surname="Chen" fullname="M. Chen"/>
<date year="2017" month="December"/>
<abstract>
<t>A Segment Routing (SR) architecture leverages source routing and
tunneling paradigms and can be directly applied to the use of
a
Multiprotocol Label Switching (MPLS) data plane. A node steers
a
packet through a controlled set of instructions called "segmen
ts" by
prepending the packet with an SR header.
</t>
<t>The segment assignment and forwarding semantic nature of SR raises
additional considerations for connectivity verification and fa
ult
isolation for a Label Switched Path (LSP) within an SR archite
cture.
This document illustrates the problem and defines extensions t
o
perform LSP ping and traceroute for Segment Routing IGP-Prefix
and
IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data pla
ne.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8287"/>
<seriesInfo name="DOI" value="10.17487/RFC8287"/>
</reference>
<reference anchor="RFC9256" target="https://www.rfc-editor.org/info/rfc9256
">
<front>
<title>Segment Routing Policy Architecture</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils"/>
<author initials="K." surname="Talaulikar " fullname="K. Talaulikar"
role="editor"/>
<author initials="A." surname="Bogdanov" fullname="A. Bogdanov"/>
<author initials="P." surname="Mattes" fullname="P. Mattes"/>
<author initials="D." surname="Voyer" fullname="D. Voyer"/>
<date year="2020" month="July"/>
<abstract>
<t>Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Intermediate per-flow states are eliminated th
anks to
source routing. The headend node steers a flow into an SR Poli
cy. The
header of a packet steered in an SR Policy is augmented with a
n
ordered list of segments associated with that SR Policy.
This document details the concepts of SR Policy and steering i
nto an
SR Policy.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
</references>
<references title='Informative References'>
<reference anchor="IANA" target="http://www.iana.org/assignments/mpls-lsp-p
ing-parameters">
<front>
<title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters</title>
<author fullname="IANA"/>
<date/>
<abstract>
<t></t>
</abstract>
</front>
</reference>
<reference anchor="I.D-ietf-idr-sr-policy-safi"
target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-s
afi-04">
<front>
<title>Advertising Segment Routing Policies in BGP</title>
<author initials="C." surname="Filsfils" fullname="C. Filsfils"
role="editor"/>
<author initials="S." surname="Previdi" fullname="S. Previdi"
role="editor"/>
<author initials="K." surname="Talaulikar " fullname="K. Talaulikar"/>
<author initials="P." surname="Mattes" fullname="P. Mattes"/>
<author initials="E." surname="Rosen" fullname="Eric C. Rosen"/>
<author initials="D." surname="Jain" fullname="D. Jain"/>
<author initials="S." surname="Lin" fullname="S. Lin"/>
<date year="2024" month="April"/>
<abstract>
<t>A Segment Routing (SR) Policy is an ordered list of segments
(i.e., instructions) that represent a source-routed policy.
An SR Policy consists of one or more candidate paths, each con
sisting
of one or more segment lists. A headend may be provisioned wit
h candidate
paths for an SR Policy via several different mechanisms, e.g.,
CLI, NETCONF,
PCEP, or BGP.This document specifies how BGP may be used to di
stribute SR
Policy candidate paths. It introduces a BGP SAFI to advertise
a candidate
path of a Segment Routing (SR) Policy and defines sub-TLVs for
the Tunnel
Encapsulation Attribute for signaling information about these
candidate
paths.This documents updates RFC9012 with extensions to the Co
lor Extended
Community to support additional steering modes over SR Policy.
</t>
</abstract>
</front>
<seriesInfo name="" value="draft-ietf-idr-sr-policy-safi-04"/>
<seriesInfo name="" value="work in progress"/>
</reference>
&RFC7942;
</references>
</back>
</rfc> </rfc>
 End of changes. 53 change blocks. 
742 lines changed or deleted 568 lines changed or added

This html diff was produced by rfcdiff 1.48.