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="September"/>
<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 label 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>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<!-- [rfced] Will readers know what "its" refers to in the phrase "of its
domain"?
</abstract> Original:
Controllers are often deployed
<note title="Requirements Language"> to construct paths across multi-domain networks. In such
<t> deployments, the head-end routers may have the link state database of
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU its domain and may not be aware of the FEC associated with labels
LD", that are used by the controller to build paths across multiple
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" domains.
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>
</note>
</front>
<middle> Perhaps:
<section title="Introduction" anchor='intro'> Controllers are often deployed
to construct paths across multi-domain networks. In such
deployments, the headend routers may have the link-state database of
their domain and may not be aware of the FEC associated with labels
that are used by the controller to build paths across multiple
domains.
-->
<t>Segment routing supports the creation of explicit paths by using one o <t>Segment routing supports the creation of explicit paths by using one or
r more more
Link State IGP Segments or BGP Segments defined in <xref target="RFC8402" Link-State IGP Segments or BGP Segments defined in <xref target="RFC8402"
/>. format="default"/>.
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 its domain and may not be aware of the FE
C C
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 <!-- [rfced] Is "Target FEC" correct here, or should this be updated to either
Echo Request/Echo Reply mechanism allows for traversing the SR Policy "the Target FEC Stack TLV" or "Target FEC Stack"?
path without validating the control plane state. <xref target="RFC8029"/>
supports this mechanism with FECs like Nil FEC and Generic FEC. Original:
However, there are challenges in reusing the Generic FEC and Nil FEC for The use of
validation of SR policies <xref target="RFC9256"/>. Target FEC requires all nodes in the network to have implemented the
Generic IPv4 prefix and Generic IPv6 prefix FECs are used when the validation procedures.
protocol that is advertising -->
the label is unknown. The information that is carried in Generic FEC is
the IPv4 or IPv6 prefix and prefix length. Thus Generic FEC types perform <xref target="RFC8029" format="default"/> describes a simple and
an additional control plane validation. However, the details of Generic F efficient mechanism to detect data plane failures in MPLS Label
EC and Switched Paths (LSPs). It defines a probe message called an "MPLS
validation procedures are not very detailed in the <xref target="RFC8029" echo request" and a response message called an "MPLS echo reply" for
/>. returning the result of the probe. SR-related extensions for these
The use-case mostly specifies inter-AS VPNs as the motivation. are specified in <xref target="RFC8287" format="default"/>. <xref
Certain aspects of SR such as anycast SIDs require clear guidelines target="RFC8029" format="default"/> provides mechanisms primarily to
on how the validation procedure should work. Also, Generic FEC may not be validate the data plane and secondarily to verify the consistency of
widely the data plane with the control plane. It also provides the ability
supported and if transit routers are not upgraded to support validation o to traverse Equal-Cost Multipaths (ECMPs) and validate each of the
f Generic ECMP paths. The Target FEC Stack TLV <xref target="RFC8029"
format="default"/> 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 the Target FEC requires all nodes
in the network to have implemented the validation procedures, but 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>
<!-- [rfced] The third paragraph in Section 1 mentions "Generic FEC" several
times. Does "Generic FEC" mean "Generic IPv4 prefix" and "Generic
IPv6 prefix", which are defined in RFC 8029? If so, would it be helpful
to clarify this in the first mention and update "Generic FEC" to "Generic
FECs" (plural) elsewhere? Please review and let us know if any updates
are needed.
Original:
[RFC8029] supports this mechanism with FECs like Nil FEC and Generic
FEC.
Perhaps:
[RFC8029] supports this mechanism with FECs like the Nil FEC and the Generic
FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix).
-->
<!-- [rfced] How may we revise this sentence to avoid "details...are not very
detailed"?
Original:
However, the details of Generic FEC and validation procedures are not
very detailed in the [RFC8029].
Perhaps:
However, the Generic FEC and relevant validation procedures are not thoroughl
y
detailed in [RFC8029].
-->
<t>A simple MPLS echo request/reply mechanism allows for traversing the
SR Policy path without validating the control plane state. <xref
target="RFC8029" format="default"/> supports this mechanism with FECs
like the Nil FEC and Generic FEC. However, there are challenges in reusin
g
the Nil FEC and Generic FEC 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 FEC is th
e
IPv4 or IPv6 prefix and prefix length. Thus, the Generic FEC types perform
an additional control plane validation. However, the details of the Generi
c
FEC and validation procedures are not very detailed in <xref
target="RFC8029" format="default"/>.
<!-- [rfced] FYI - We updated "when the Nil FEC is used where the Nil FEC is
intermediate" as follows to improve readability and align with similar
text in the abstract.
Original:
The procedures described in [RFC8029] are
mostly applicable when the Nil FEC is used where the Nil FEC is
intermediate in the label stack. When all labels in the label stack
are represented using Nil FEC, it poses some challenges.
Current:
The procedures described in [RFC8029] are mostly applicable when the
Nil FEC is used as an intermediate FEC in the label stack.
Challenges arise when all labels in the label stack are represented
using the Nil FEC.
-->
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 FEC may no
t be widely
supported, and if transit routers are not upgraded to support validation
of Generic
FEC, traceroute may fail. FEC, traceroute may fail.
On the other hand, Nil FEC consists of the label and there is no other as On the other hand, the Nil FEC consists of the label, and there is no oth
sociated er associated
FEC information. Nil FEC is used to traverse the path without validation FEC information. The Nil FEC is used to traverse the path without validat
for 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 Nil FEC is used where the Nil FEC is intermediate in the when the Nil FEC is used as an intermediate FEC in the
label stack. When all labels in the label-stack is represented using Nil label stack. Challenges arise when all labels in the label stack are repr
FEC, esented 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>
<!-- [rfced] May we update this sentence as follows to improve clarity?
<t> Current:
To mitigate this issue, it is necessary to include additional
information in the MPLS echo request message in both ping and
traceroute modes, along with the Nil FEC, to perform minimal
validation on the egress/destination router.
Perhaps (moved "along with the Nil FEC" and added "and" before "to perform"):
To mitigate this issue, it is necessary to include additional information,
along with the Nil FEC, in the MPLS echo request message in both ping and
traceroute modes and to perform minimal validation on the egress/destination
router.
-->
To mitigate this issue, it is necessary to include additional To mitigate this issue, it is necessary to include additional
information in the MPLS Echo Request message in both ping and traceroute information in the MPLS echo request message in both ping and traceroute
modes, along with the Nil FEC, to perform minimal validation on the modes, along with the Nil FEC, to perform minimal validation on the
egress/destination router. This will enable the router to send appropriat e egress/destination router. This will enable the router to send appropriat 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>
<!-- [rfced] Will readers understand what "It" refers to here?
<t>Consequently, the inclusion of egress information in the MPLS Original:
Echo Request messages in ping and traceroute modes will facilitate It can be employed to verify any combination of
the validation of Nil FEC on the egress router ensuring the correct segments on any path without requiring upgrades to transit nodes.
Perhaps:
Egress information can be employed to verify any combination of
segments on any path without requiring upgrades to transit nodes.
-->
<!-- [rfced] We updated the first sentence below for clarity. Would it be
helpful to further update this text by combining the first and second
sentences? Please review the suggestion below and let us know your
thoughts.
Original:
The code point used for the Egress TLV is from the range 32768-65535
and can be silently dropped if not recognized as per [RFC8029] and
the clarifications from [RFC9041]. Alternately, the unrecognized TLV
may be stepped over or an error message may be sent.
Current:
The Egress TLV can be silently dropped if not recognized, as per
[RFC8029] and the clarifications in [RFC9041] regarding code points
in the range 32768-65535. Alternately, the unrecognized TLV
may be stepped over, or an error message may be sent.
Perhaps:
The Egress TLV can be silently dropped if not recognized; alternately,
it may be stepped over, or an error message may be sent (per
[RFC8029] and the clarifications in [RFC9041] regarding code points
in the range 32768-65535).
-->
<t>Consequently, the inclusion of egress information in the MPLS
echo request messages in ping and traceroute modes will facilitate
the validation of the Nil FEC on the egress router, ensuring the correct
destination. It can be employed to destination. It 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. The
Egress TLV is from the range 32768-65535 and can be silently dropped Egress TLV can be silently dropped
if not recognized as per <xref target="RFC8029"/> and as per clarificatio if not recognized, as per <xref target="RFC8029" format="default"/> and t
ns from he 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. Alternately, the unrecognized TLV may be stepped over, or
an error message may be sent. </t> an error message may be sent. </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 anchor="egress_tlv" numbered="true" toc="default">
<name>Egress TLV</name>
</section> <!-- [rfced] The following sentences discuss how the address field is
derived. Is "address field" correct, or should these instances be updated
to simply "address"?
<section title="Egress TLV" anchor='egress_tlv'> Original:
The address field of the Egress TLV must be
derived from the path egress/destination.
...
Some specific cases on how to derive the
address field in the Egress TLV are listed below:
...
a. If the last SID in the SR policy is an Adj-SID, the address
field in the Egress TLV is derived from the node at the remote end
of the corresponding adjacency.
<t> b. If the last SID in the SR policy is a Binding SID, the address
The Egress TLV MAY be included in an MPLS Echo Request message. field in the Egress TLV is derived from the last node of the path
It is an optional TLV and, if present, MUST appear before the represented by the Binding SID.
FEC stack TLV in the MPLS Echo Request packet. This TLV can
only be used in LSP ping/traceroute requests, generated by Perhaps:
the head-end node of an LSP or SR policy for which verification The address in the Egress TLV
must be derived from the path egress/destination.
...
Some specific cases on how to derive the
address in the Egress TLV are listed below:
...
* If the last SID in the SR Policy is an Adj-SID, the address
in the Egress TLV is derived from the node at the remote end of
the corresponding adjacency.
* If the last SID in the SR Policy is a Binding SID, the address
in the Egress TLV is derived from the last node of the path
represented by the Binding SID.
-->
<t>
The Egress TLV <bcp14>MAY</bcp14> be included in an MPLS echo request mes
sage.
It is an optional TLV and, if present, <bcp14>MUST</bcp14> appear before
the
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 <!-- [rfced] May we update this definition as follows to be more concise by
4 octets or a valid IPv6 address of length 16 octe combining "based on IPV4/IPV6 address" and "Length will be 4 octets for
ts. IPv4 and 16 octets for IPv6"?
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> Original:
Length : variable based on IPV4/IPV6 address. Length excludes the
length of the Type and Length fields. Length is 4 octets for
IPv4 and 16 octets for IPv6.
<section title="Procedure" anchor='detail_procedure'> Perhaps:
Length: Variable (4 octets for IPv4 addresses and 16 octets for IPv6
addresses). Length excludes the length of the Type and Length fields.
-->
<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, based on IPv4/IPv6 address. Length excludes the length of the
<section title="Sending Egress TLV in MPLS Echo Request" anchor='send_proced Type and Length fields. Length is 4 octets for IPv4 and 16 octets for
ure'> IPv6.</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 anchor="traceroute_procedure" numbered="true" toc="default">
<name>Traceroute Mode</name>
<t>When the sender node builds an echo request with a Target FEC Stack
TLV
that contains a Nil FEC corresponding to the last segment of the
segment list of
the SR Policy, the sender node <bcp14>MUST</bcp14> add an Egress
TLV with the address obtained
from the SR Policy Endpoint field
<xref target="I-D.ietf-idr-sr-policy-safi" format="default"/>.
</t>
</section> <!-- [rfced] We updated the "i.e." phrase in this sentence as follows. Please
review and let us know any concerns.
<section title="Traceroute Mode" anchor='traceroute_procedure'> Original:
In case the endpoint is not
specified or is equal to zero (Sec 8.8.1 [RFC9256]), the sender MUST
use the address corresponding to the last segment endpoint of the SR
Policy path i.e. ultimate egress as the address for the Egress TLV.
<t>When the sender node builds an Echo Request with target FEC Stack TLV Current:
that contains Nil FEC corresponding to the last segment of the se If the endpoint is not
gment-list of specified or is equal to zero (Section 8.8.1 of [RFC9256]), the
the SR Policy, the sender node MUST add an Egress TLV with the ad sender MUST use the address corresponding to the last segment
dress obtained endpoint of the SR Policy path (i.e., the ultimate egress is used as the addr
from the SR policy endpoint field ess
<xref target="I.D-ietf-idr-sr-policy-safi"/>. in the Egress TLV).
</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. <!-- [rfced] We updated "will be 4 or 16" to "will be either 4 or 16
The Echo Request message contains a Target FEC stack TLV with the octets". Let us know any concerns.
Nil FEC sub-TLV.
An Egress TLV is added before the Target FEC Stack TLV. The addre
ss field contains
X (corresponding to a locally configured address on R7). X could
be an
IPv4 or IPv6 address and the Length field in the Egress TLV will
be 4 or 16
based on the address X's address type.
</t>
<t>Let us look at an example of an Echo Request message in a tracerou
te packet.
The Echo Request message contains a Target FEC stack TLV with the Nil FE
C sub-TLV
corresponding to the complete label-stack (1002, 1004, 1007).
An Egress TLV is added before the Target FEC Stack TLV.
The address field contains
X (corresponding to a locally configured address on destination R
7). X could be an
IPv4 or IPv6 address and the Length field in the Egress TLV will
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> Original:
</section> X could be an IPv4 or IPv6 address and the Length
field in the Egress TLV will be 4 or 16 based on the address X's
address type.
...
X could be an IPv4 or IPv6
address and the Length field in the Egress TLV will be 4 or 16 based
on the address type of address X.
</section> Current:
<section title="Receiving Egress TLV in MPLS Echo Request" X could be an IPv4 or IPv6 address, and the Length
anchor='recv_procedure'> field in the Egress TLV will be either 4 or 16 octets, based on the
address type of address X.
...
X could be an IPv4 or IPv6
address, and the Length field in the Egress TLV will be either 4 or 16
octets, based on the address type of address X.
-->
<t>Any node that receives the MPLS Echo Request message and processes it, <t>Let us look at an example of a ping echo request message. The
is referred to as the "receiver". In case of the ping procedure, echo request message contains a Target FEC Stack TLV with the Nil
FEC sub-TLV. An Egress TLV is added before the Target FEC Stack
TLV. The Address field contains X (corresponding to a locally
configured address on R7). X could be an IPv4 or IPv6 address, and
the Length field in the Egress TLV will be either 4 or 16 octets,
based on the address type of address X.
</t>
<t>Let us look at an example of an echo request message in a
traceroute packet. The echo request message contains a Target FEC
Stack TLV with the Nil FEC sub-TLV corresponding to the complete
label stack (1002, 1004, 1007). An Egress TLV is added before the
Target FEC Stack TLV. The Address field contains X (corresponding
to a locally configured address on destination R7). X could be an
IPv4 or IPv6 address, and the Length field in the Egress TLV will be e
ither
4 or 16 octets, based on the address type of address X. If the
destination/endpoint is set to zero (as in the case of the
color-only SR Policy), the sender should use the endpoint of segment
1007 (the last segment in the segment list) as the address for the
Egress TLV.
</t>
</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.
<!-- [rfced] How may we clarify "in the Target Stack TLV Node that receives an
MPLS echo request"?
Original:
This document does not propose any change in the processing for Nil FEC as
defined in [RFC8029] in the Target FEC Stack TLV Node that receives an MPLS
echo request.
Perhaps:
This document does not propose any change in the processing of the Nil FEC (as
defined in [RFC8029]) in the node that receives an MPLS echo request with a
Target FEC Stack TLV.
-->
This document does not propose any change in the processing This document does not propose any change in the processing
for Nil FEC as defined in of the Nil FEC (as defined in
<xref target="RFC8029"/> in the Target FEC stack TLV Node that receives <xref target="RFC8029" format="default"/>) in the Target FEC Stack TLV
an MPLS echo request. The presence of Egress TLV does not affect the Node that receives
validation of Target FEC Stack sub-TLV at FEC-stack-depth an MPLS echo request. The presence of the Egress TLV does not affect th
e
validation of the Target FEC Stack sub-TLV at FEC-stack-depth
if it is different than Nil FEC.</t> if it is different than Nil FEC.</t>
<t>Additional processing MUST be done for the Egress TLV on <t>Additional processing <bcp14>MUST</bcp14> be done for the Egress TLV on
the receiver node as follows: the receiver node as follows:
</t> </t>
<t>1. If the Label-stack-depth is greater than 0 and the Target FEC Stack
<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")
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 RSC")
(<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 RSC").</li>
</ol>
</li>
<!-- This long sentence is difficult to follow. May we break it up into
several sentences to improve readability? Also, please clarify "one each
corresponding to the labels in the label stack along with Egress TLV".
<section anchor='backward_compatibility' title='Backward Compatibility'> Original:
<t>The extensions defined in this document is backward compatible with 3. In cases where multiple Nil FECs are sent from the SR Policy headend, one
procedures described in <xref target="RFC8029"/>. A Router that does not each corresponding to the labels in the label stack along with Egress TLV,
support Egress TLV, will ignore it and use current the Nil-FEC procedures when the packet reaches the egress, the number of labels in the received
described in <xref target="RFC8029"/>. packet (Size of stack-R) becomes zero or a label with Bottom-of-Stack bit set
</t> to 1 is processed, all Nil FEC sub-TLVs MUST be removed and the Egress TLV
<t>When the egress node in the path does not support the extensions defined MUST be validated.
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 Perhaps:
allocation for Egress TLV in the 3. In some cases, multiple Nil FECs (one corresponding to each label in the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping label stack), along with the Egress TLV, are sent from the SR Policy headend.
Parameters" in the "TLVs" sub-registry to reference this When the packet reaches the egress in such cases, the number of labels in the
document when published as an RFC. received packet (size of stack-R) becomes zero, or a label with the
</t> Bottom-of-Stack bit set to 1 is processed. In addition, all Nil FEC sub-TLVs
<texttable anchor="iana_tlvs_tbl" title="TLVs Sub-Registry"> MUST be removed, and the Egress TLV MUST be validated.
<ttcol align="left">Value</ttcol> -->
<ttcol align="center">Description</ttcol> <li><t>In cases where multiple Nil FECs are sent from the SR Policy head
<ttcol align="left">Reference</ttcol> end,
<c>32771</c> one each corresponding to the labels in the label stack along with the
<c>Egress TLV</c> Egress TLV, when the packet reaches the egress, the number of labels in the rece
<c><xref target="egress_tlv"/> of this document</c> ived packet (Size of stack-R) becomes zero or a label with the Bottom-of-Stack b
</texttable> 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>
</ol>
</section>
</section> </section>
<section anchor="ret_code" title="New Return code"> <section anchor="backward_compatibility" numbered="true" toc="default">
<name>Backward Compatibility</name>
<t>The extensions defined in this document are backward compatible with th
e
procedures described in <xref target="RFC8029" format="default"/>. A rout
er that does not
support the Egress TLV will ignore it and use the Nil FEC procedures
described in <xref target="RFC8029" format="default"/>.
</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 will be set to 3 ("Replying router is an egress for the
FEC at stack-depth") and Best-rtn-subcode to stack-depth in the MPLS
echo reply message.
</t>
<t>When the transit node in the path does not support the extensions defin
ed
in this document, Best-return-code will be set to 8 ("Label switched at s
tack-depth") and
Best-rtn-subcode to Label-stack-depth to report transit switching
in the MPLS echo reply message.
</t>
</section>
<section anchor="iana_con" numbered="true" toc="default">
<name>IANA Considerations</name>
<t> <xref target="IANA"/> is requested to update the <!-- [rfced] IANA Considerations
early allocation of the Return Code for
"Replying router is an egress for the address in Egress TLV" in the a) In Table 1, we updated "Egress TLV" to "Egress" as the majority of entries
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping in the "TLVs" registry do not include "TLV" as part of the name. If no
Parameters" in the "Return Codes" sub-registry to reference this objections, we will ask IANA to update the entry in the registry accordingly
document when published as an RFC. prior to publication.
</t>
<texttable anchor="iana_return_code_tbl" title="Return code Sub-Registr Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls
y"> -lsp-ping-parameters.xhtml#tlvs
<ttcol align="left">Value</ttcol>
<ttcol align="center">Description</ttcol> b) Should "RSC" be updated to "<RSC>" in the Meaning column of Table 2? We ask
<ttcol align="left">Reference</ttcol> because angle brackets are used in a few other entries in the "Return Codes"
<c>36</c> registry.
<c>Replying router is an egress for the
address in Egress TLV for the FEC at stack depth RSC</c> Also, note that we added "the" before "Egress TLV". We will ask IANA to update
<c><xref target="recv_procedure"/> of this document</c> the entry in the "Return Codes" registry accordingly prior to publication.
</texttable>
Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls
-lsp-ping-parameters.xhtml#return-codes
Original:
Replying router is an egress for the
address in Egress TLV for the FEC at stack depth RSC
Current:
Replying router is an egress for the
address in the Egress TLV for the FEC at stack depth RSC
Perhaps:
Replying router is an egress for the
address in the Egress TLV for the FEC at stack depth <RSC>
-->
<!-- [rfced] Return Codes
a) FYI - We updated "Best-return-subcode" to "Best-rtn-subcode" per RFC 8029.
b) Is "stack-depth" correct here, or should it be updated to either
"Label-stack-depth" or "FEC-stack-depth"?
Original:
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-return- subcode set to stack-depth to will be set in
the MPLS Echo Reply message.
c) In the "Return Codes" registry, "<RSC>" is included in the meaning for
Return Codes 8, 10, and 3. Should "<RSC>" be included in the text below? Or
are these okay as is?
Link to registry: https://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls
-lsp-ping-parameters.xhtml#return-codes
Original:
...set Best-return-code to 8 ("Label switched at stack-depth")
...set the Best-return-code to 10, "Mapping for this FEC is not the
given label at stack-depth RSC"
...Best-return-code as 3 ("Replying router is an egress for the FEC at stack-
depth")
Perhaps:
...set Best-return-code to 8 ("Label switched at stack-depth <RSC>")
...set the Best-return-code to 10, "Mapping for this FEC is not the
given label at stack-depth <RSC>"
...Best-return-code to 3 ("Replying router is an egress for the FEC at stack-
depth <RSC>")
d) "RSC" is not expanded/defined in the document. May we add a sentence
before the list in Section 4.2 with the definition? RFC 8029 notes that "The
notation <RSC> refers to the Return Subcode."
-->
<section anchor="tlv" numbered="true" toc="default">
<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</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 RSC</td>
<td align="left">RFC 9655</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
</section> <section anchor="sec-con" numbered="true" toc="default">
<section title='Security Considerations' anchor='sec-con'> <name>Security Considerations</name>
<t>This document defines additional MPLS LSP ping TLVs and follows <!-- [rfced] We updated "TLVs" to "TLV" (singular) here as only one new TLV is
the mechanisms defined in <xref target="RFC8029"/>. defined in this document (i.e., the Egress TLV). We also updated
All the security considerations defined in <xref target="RFC8287"/> will "follows" to "conforms to". Let us know any concerns.
be applicable for this document and, in addition, they do not impose any
Original:
This document defines additional MPLS LSP ping TLVs and follows the
mechanisms defined in [RFC8029].
Perhaps:
This document defines an additional TLV for MPLS LSP ping and conforms
to the mechanisms defined in [RFC8029].
-->
<!-- [rfced] Does "they" here refer to "security considerations" or "this
document"? Also, would "introduce" rather than "impose" be a better word
choice?
Original:
All the security considerations
defined in [RFC8287] will be applicable for this document and, in
addition, they do not impose any additional security challenges to be
considered.
Perhaps:
All the security considerations
defined in [RFC8287] apply to this document. This document does not
introduce any additional security challenges to be considered.
-->
<t>This document defines an additional TLV for MPLS LSP ping and conforms to
the mechanisms defined in <xref target="RFC8029" format="default"/>.
All the security considerations defined in <xref target="RFC8287" format=
"default"/>
are applicable to this document, and they do not impose any
additional security challenges to be considered. additional security challenges to be considered.
</t> </t>
</section> </section>
</middle>
<back>
<displayreference target="I-D.ietf-idr-sr-policy-safi" to="SR-POLICY-BGP"/>
<references>
<name>References</name>
<references>
<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>
<section title='Implementation Status'> <reference anchor="IANA-MPLS-LSP" target="http://www.iana.org/assignment
<t>This section is to be removed before publishing as an RFC.</t> s/mpls-lsp-ping-parameters">
<front>
<title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LS
Ps)
Ping Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<t>RFC-Editor: Please clean up the references cited by this section <!-- [I-D.ietf-idr-sr-policy-safi] IESG state: I-D Exists as of 9/5/24; Updated
before publication.</t> to long way to add "Ed." for K. Talaulikar-->
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this <reference anchor="I-D.ietf-idr-sr-policy-safi" target="https://datatracker.ietf
Internet-Draft, and is based on a proposal described in <xref target="RFC7942 .org/doc/html/draft-ietf-idr-sr-policy-safi-06">
"/>. <front>
The description of implementations in this section is intended to <title>Advertising Segment Routing Policies in BGP</title>
assist the IETF in its decision processes in progressing drafts to <author initials="S." surname="Previdi" fullname="Stefano Previdi">
RFCs. Please note that the listing of any individual implementation <organization>Huawei Technologies</organization>
here does not imply endorsement by the IETF. Furthermore, no effort </author>
has been spent to verify the information presented here that was <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
supplied by IETF contributors. This is not intended as, and must not <organization>Cisco Systems</organization>
be construed to be, a catalog of available implementations or their </author>
features. Readers are advised to note that other implementations may <author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="edi
exist.</t> tor">
<section title='Juniper Networks'> <organization>Cisco Systems</organization>
<t>Organization: Juniper Networks</t> </author>
<t>Implementation: JUNOS</t> <author initials="P." surname="Mattes" fullname="Paul Mattes">
<t>Description: Implementation for sending and validating Egress TLV</t> <organization>Microsoft</organization>
<t>Maturity Level: Released</t> </author>
<t>Coverage: Full</t> <author initials="D." surname="Jain" fullname="Dhanendra Jain">
<t>Contact: shraddha@juniper.net</t> <organization>Google</organization>
</section> </author>
<date month="July" day="26" year="2024"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-sr-policy-safi-06"/>
</reference>
</references>
</references>
<section anchor="ack" numbered="false" toc="default">
<name>Acknowledgements</name>
<t> The authors would like to thank <contact fullname="Stewart
Bryant"/>, <contact fullname="Greg Mirsky"/>, <contact
fullname="Alexander Vainshtein"/>, <contact fullname="Sanga Mitra
Rajgopal"/>, and <contact fullname="Adrian Farrel"/> for their careful
review and comments.</t>
</section> </section>
<section title='Acknowledgements' anchor='ack'> </back>
<t> The authors would like to thank Stewart Bryant, Greg Mirsky, Alexander V
ainshtein,
Sanga Mitra Rajgopal, and Adrian Farrel for their careful review and comm
ents.</t>
</section>
</middle>
<back> <!-- [rfced] Terminology
<references title='Normative References'>
&RFC9041;
&RFC8402;
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119 a) We note inconsistencies in the terms listed below. We chose the form on the
"> right. Please let us know any objections.
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"/>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words ar
e often
capitalized. This document defines these words as they should
be
interpreted in IETF documents. This document specifies an Int
ernet
Best Current Practices for the Internet Community, and request
s
discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8029" target="https://www.rfc-editor.org/info/rfc8029
">
<front>
<title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane
Failures</title>
<author initials="K." surname="Kompella" fullname="K. Kompella"/>
<author initials="G." surname="Swallow" fullname="G. Swallow"/>
<author initials="C." surname="Pignataro" fullname="C. Pignataro"
role="editor"/>
<author initials="N." surname="Kumar" fullname="N. Kumar"/>
<author initials="S." surname="Aldrin" fullname="S. Aldrin"/>
<author initials="M." surname="Chen" fullname="M. Chen"/>
<date year="2017" month="March"/>
<abstract>
<t>This document describes a simple and efficient mechanism to detect
data-plane failures in Multiprotocol Label Switching (MPLS) La
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> Target FEC stack TLV vs. target FEC Stack TLV vs. FEC stack TLV vs. Target FEC S
<references title='Informative References'> tack TLV
<reference anchor="IANA" target="http://www.iana.org/assignments/mpls-lsp-p
ing-parameters"> SR policy vs. SR Policy
<front> Note: The capitalized form is more common in the RFC Series (e.g., it is
<title>Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) used in RFC 9256)
Ping Parameters</title>
<author fullname="IANA"/> Echo Reply vs. echo reply
<date/> Note: Per usage in RFCs 8029 and 8287.
<abstract>
<t></t> Echo Request vs. echo request
</abstract> Note: Per usage in RFCs 8029 and 8287.
</front>
</reference> head-end vs. headend
<reference anchor="I.D-ietf-idr-sr-policy-safi"
target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-s b) FYI - We updated "address field" to "Address field" (capitalized) per the
afi-04"> name of the field in Figure 1. We also updated "endpoint field" to "Endpoint
<front> field" (capitalized) per the name of the field in Figure 1 in
<title>Advertising Segment Routing Policies in BGP</title> draft-ietf-idr-sr-policy-safi.
<author initials="C." surname="Filsfils" fullname="C. Filsfils"
role="editor"/> c) We see both "Nil FEC" and "Nil FEC sub-TLV" used in the document. Please
<author initials="S." surname="Previdi" fullname="S. Previdi" review and let us know if any updates would be helpful.
role="editor"/>
<author initials="K." surname="Talaulikar " fullname="K. Talaulikar"/> d) Article usage (i.e, "the", "a", and "an") before "Nil FEC" and "General FEC"
<author initials="P." surname="Mattes" fullname="P. Mattes"/> is inconsistent. We added articles as there seems to be precedence in RFC
<author initials="E." surname="Rosen" fullname="Eric C. Rosen"/> 8029. Please review in the diff and confirm that these additions are
<author initials="D." surname="Jain" fullname="D. Jain"/> appropriate. Some examples:
<author initials="S." surname="Lin" fullname="S. Lin"/>
<date year="2024" month="April"/> Original:
<abstract>
<t>A Segment Routing (SR) Policy is an ordered list of segments With article ("the Nil FEC", "a Nil FEC"):
(i.e., instructions) that represent a source-routed policy. The procedures outlined in
An SR Policy consists of one or more candidate paths, each con [RFC8029] is primarily applicable when the Nil FEC is used as an
sisting intermediate FEC in the label stack.
of one or more segment lists. A headend may be provisioned wit
h candidate This document uses a Nil FEC to represent the complete label stack in
paths for an SR Policy via several different mechanisms, e.g., an MPLS Echo Request message in ping and traceroute mode.
CLI, NETCONF,
PCEP, or BGP.This document specifies how BGP may be used to di Without article ("Nil Fec"):
stribute SR [RFC8029] supports this mechanism with FECs like Nil FEC and Generic
Policy candidate paths. It introduces a BGP SAFI to advertise FEC.
a candidate
path of a Segment Routing (SR) Policy and defines sub-TLVs for On the other hand, Nil FEC consists of the
the Tunnel label and there is no other associated FEC information. Nil FEC is
Encapsulation Attribute for signaling information about these used to traverse the path without validation for cases where the FEC
candidate is not defined or routers are not upgraded to support the FECs.
paths.This documents updates RFC9012 with extensions to the Co -->
lor Extended
Community to support additional steering modes over SR Policy. <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
</t> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
</abstract> expansion in the document carefully to ensure correctness.
</front>
<seriesInfo name="" value="draft-ietf-idr-sr-policy-safi-04"/> SR over IPv6 (SRv6)
<seriesInfo name="" value="work in progress"/> Autonomous System (AS)
</reference> Segment Identifier (SID)
&RFC7942; -->
</references>
</back> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</rfc> </rfc>
 End of changes. 75 change blocks. 
715 lines changed or deleted 958 lines changed or added

This html diff was produced by rfcdiff 1.48.