Routing area
Internet Engineering Task Force (IETF) D. Rathi, Ed.
Internet-Draft
Request for Comments: 9655 Nokia
Intended status:
Category: Standards Track S. Hegde, Ed.
Expires: 14 December 2024
ISSN: 2070-1721 Juniper Networks Inc.
K. Arora
Individual Contributor
Z. Ali
N. Nainar
Cisco Systems, Inc.
12 June
September 2024
Egress Validation in Label Switched Path Ping and Traceroute Mechanisms
draft-ietf-mpls-egress-tlv-for-nil-fec-15
Abstract
The MPLS ping and traceroute mechanisms, as mechanisms described in [RFC8029] RFC 8029 and the
related extensions for Segment Routing (SR) defined in
[RFC8287], is 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 traversing traversal of any path without validating validation of the control plane
state. [RFC8029] RFC 8029 supports this mechanism with the Nil Forwarding
Equivalence Class (FEC). The procedures outlined in
[RFC8029] is RFC 8029 are
primarily applicable when the Nil FEC is used as an intermediate FEC
in the label FEC stack. However, challenges arise when all labels in the
label stack are represented using the Nil FEC.
This document introduces a new Type-Length-Value (TLV) as an
extension to the existing Nil FEC. It describes MPLS ping and
traceroute procedures using the Nil FEC with this extension to
address and overcome these challenges.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of six months RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 December 2024.
https://www.rfc-editor.org/info/rfc9655.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language
2. Problem with Nil FEC . . . . . . . . . . . . . . . . . . . . 4
3. Egress TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 6
4.1.1. Ping Mode . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Traceroute Mode . . . . . . . . . . . . . . . . . . . 7
4.1.3. Detailed Example . . . . . . . . . . . . . . . . . . 7
4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 8
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. New Return code . . . . . . . . . . . . . . . . . . . . . 9 Code
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
8.1. Juniper Networks . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1.
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2.
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Segment routing supports the creation of explicit paths by using one
or more Link State Link-State IGP Segments or BGP Segments defined in [RFC8402].
In certain use cases, the TE paths are built using mechanisms
described in [RFC9256] by stacking the labels that represent the
nodes and links in the explicit path. Controllers are often deployed
to construct paths across multi-domain networks. In such
deployments, the head-end headend routers may have the link state link-state database of
its
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. A very useful Operations, Administration, and Maintenance
(OAM) requirement is to be able to ping and trace these paths.
[RFC8029] describes a simple and efficient mechanism to detect data- 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 for these are specified in [RFC8287].
[RFC8029] primarily provides mechanisms primarily to validate the data plane and, secondarily,
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) Equal-Cost
Multipaths (ECMPs) and validate each of the ECMP paths. The Target
FEC Stack TLV [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 the Target FEC
Stack TLV requires all nodes in the network to have implemented the
validation procedures. All 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.
A simple MPLS Echo Request/Echo Reply echo request/reply mechanism allows for traversing the
SR Policy path without validating the control plane state. [RFC8029]
supports this mechanism with FECs like the Nil FEC and the Generic
FEC.
FECs (i.e., Generic IPv4 prefix and Generic IPv6 prefix). However,
there are challenges in reusing the Generic FEC and Nil FEC and Generic FECs for
validation of SR policies Policies [RFC9256]. 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 FECs is the IPv4 or IPv6 prefix and prefix length. Thus Thus,
the Generic FEC types perform an additional control plane validation.
However, the details of Generic FEC FECs and relevant validation procedures are not
very
thoroughly detailed in the [RFC8029]. The use-case use case mostly specifies inter-
AS
inter-AS (Autonomous System) VPNs as the motivation. Certain aspects
of SR SR, such as anycast
SIDs Segment Identifiers (SIDs), require clear
guidelines on how the validation procedure should work. Also, the
Generic FEC FECs may not be widely supported supported, and if transit routers are
not upgraded to support validation of Generic FEC, FECs, traceroute may
fail. On the other hand, the Nil FEC consists of the
label label, and
there is no other associated FEC information. The Nil FEC is used to
traverse the path without validation for 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 data path.
The procedures described in [RFC8029] are mostly applicable when the
Nil FEC is used where the Nil FEC is as an intermediate FEC in the
label FEC stack. When Challenges
arise when all labels in the label-stack is label stack are represented using the
Nil FEC, it poses some challenges. FEC.
Section 2 discusses the problems associated with using the Nil FEC in
an MPLS ping/traceroute procedure procedure, and Section Sections 3 and Section 4 discuss
simple extensions needed to solve the problem.
The problems and the solutions described in this document apply to
the MPLS data plane. SRv6 Segment Routing over IPv6 (SRv6) is out-of-scope out of
scope for this document.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Problem with Nil FEC
The purpose of the Nil FEC FEC, as described in [RFC8029] [RFC8029], is to ensure hiding
of
that transit tunnel information and is hidden and, in some cases cases, to
avoid false negatives when the FEC information is unknown.
This document uses a Nil FEC to represent the complete label stack in
an MPLS Echo Request echo request message in ping and traceroute mode. A single
Nil FEC is used in the MPLS Echo Request echo request message irrespective of the
number of segments in the label stack. As described in sec Section 4.4.1 of
[RFC8029], "If [RFC8029]
notes:
| If the outermost FEC of the Target FEC stack is the Nil FEC, then
| the node MUST skip the Target FEC validation completely." completely.
When a router in the label-stack label stack path receives an MPLS Echo Request 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
information and no validation is performed by the router. So Thus,
there is a high possibility that the packet may be mis-forwarded misforwarded to an
incorrect destination but the MPLS Echo Reply echo reply might still return
success.
To mitigate this issue, it is necessary to include additional
information
information, along with the Nil FEC, in the MPLS Echo Request echo request message
in both ping and traceroute modes, along with the Nil FEC, modes and to perform minimal validation
on the egress/destination router. This will enable the router to
send appropriate success and failure information to the headend
router of the SR Policy. This supplementary information should
assist in reporting transit router details to the headend router,
which can be utilized by an offline application to validate the
traceroute path.
Consequently, the inclusion of egress information in the MPLS Echo
Request echo
request messages in ping and traceroute modes will facilitate the
validation of the Nil FEC on the egress router router, ensuring the correct
destination. It Egress information can be employed to verify any
combination of segments on any path without requiring upgrades to
transit nodes. The code point used for Egress TLV is from the range 32768-65535 and can be silently dropped if not recognized as per [RFC8029] and as per
clarifications from [RFC9041]. Alternately, the un-recognized TLV
recognized; alternately, it may be stepped over over, or an error message
may be sent. sent (per [RFC8029] and the clarifications in [RFC9041]
regarding code points in the range 32768-65535).
If a transit node does not recognize the Egress TLV and chooses to
silently drop or step over the Egress TLV, the headend will continue
to send the Egress TLV in the next echo request message message, and if
egress recognizes the Egress TLV, egress validation will be executed
at the egress. If a transit node does not recognize the Egress TLV
and chooses to send an error message, the headend will log the
message for informational purposes and continue to send echo requests
with the Egress TLV, with the TTL incremented. If the egress node
does not recognize the Egress TLV and chooses to silently drop or
step over the Egress TLV, egress validation will not be done done, and the ping/
traceroute
ping/traceroute procedure will proceed as if the Egress TLV is were not
received.
3. Egress TLV
The Egress TLV MAY be included in an MPLS Echo Request echo request message. It
is an optional TLV and, if present, MUST appear before the Target FEC stack
Stack TLV in the MPLS Echo Request echo request packet. This TLV can only be used
in LSP ping/traceroute requests, requests that are generated by the head-end headend
node of an LSP or SR policy Policy for which verification is performed. In
cases where multiple Nil FECs are present in the Target FEC Stack
TLV, the Egress TLV must be added corresponding to the ultimate
egress of the label stack. Explicit paths can be created using Node-SID, Node-
SID, Adj-SID,
Binding-SID, Binding SID, etc. The address Address field of the Egress TLV
must be derived from the path egress/destination. The format is as
specified
below: in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 32771 (Egress TLV) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Egress TLV
Type :
Type: 32771 (Section 6.1)
Length : variable based on IPV4/IPV6 address.
Length: Variable (4 octets for IPv4 addresses and 16 octets for IPv6
addresses). Length excludes the length of the Type and Length
fields. Length will be 4 octets for
IPv4 and 16 octets for IPv6.
Address :
Address: This field carries a valid 4-octet IPv4 address of length 4 octets or a valid
16-octet IPv6 address. The address of length 16 octets. It can be obtained from the
egress of the path. It path and corresponds to the last label in the label
stack or the SR policy endpoint Policy Endpoint field
[I.D-ietf-idr-sr-policy-safi]. [SR-POLICY-BGP].
4. Procedure
This section describes aspects of LSP ping and traceroute operations
that require further considerations beyond those detailed in
[RFC8029].
4.1. Sending Egress TLV in MPLS Echo Request
As previously mentioned, when the sender node constructs an Echo
Request 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 echo request
packet.
4.1.1. Ping Mode
When the sender node constructs an Echo Request echo request with target a Target FEC
Stack TLV 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 address obtained from the SR policy endpoint Policy Endpoint field
[I.D-ietf-idr-sr-policy-safi].
[SR-POLICY-BGP]. The Label value in the Nil FEC MAY be set to zero
when a single Nil FEC is added for multiple labels in the label
stack. In case the endpoint is not specified or is equal to zero (Sec
(Section 8.8.1 of [RFC9256]), the sender MUST use the address
corresponding to the last segment of the SR Policy in the address Address
field for of the Egress TLV. Some specific cases on how to derive the
address
Address field in the Egress TLV are listed below:
a.
* If the last SID in the SR policy Policy is an Adj-SID, the address Address field
in the Egress TLV is derived from the node at the remote end of
the corresponding adjacency.
b.
* If the last SID in the SR policy Policy is a Binding SID, the address Address
field in the Egress TLV is derived from the last node of the path
represented by the Binding SID.
4.1.2. Traceroute Mode
When the sender node builds an Echo Request echo request with target a Target FEC Stack
TLV that contains a Nil FEC corresponding to the last segment of the
segment-list
segment list of the SR Policy, the sender node MUST add an Egress TLV
with the address obtained from the SR policy endpoint Policy Endpoint field
[I.D-ietf-idr-sr-policy-safi].
[SR-POLICY-BGP].
Although there is no requirement to do so, an implementation MAY send
multiple Nil FECs if that makes it easier for the implementation. In
case If
the SR Policy headend sends multiple Nil FECs FECs, the last one MUST
correspond to the Egress TLV. The Label value in the Nil FEC MAY be
set to zero for the last Nil FEC. In case If the endpoint is not specified
or is equal to zero (Sec (Section 8.8.1 of [RFC9256]), the sender MUST use
the address corresponding to the last segment endpoint of the SR
Policy path i.e. (i.e., the ultimate egress is used as the address for in the
Egress TLV. TLV).
4.1.3. Detailed Example
----R3----
/ (1003) \
(1001) / \(1005) (1007)
R1----R2(1002) R5----R6----R7(address X)
\ / (1006)
\ (1004) /
----R4----
Figure 2: Egress TLV processing on sample topology Processing in Sample Topology
Consider the SR Policy configured on router R1, R1 to destination X,
configured with label-stack label stack as 1002, 1004, 1007. Segment 1007
belongs to R7, which has the address X locally configured on it.
Let us look at an example of a ping Echo Request echo request message. The Echo
Request echo
request message contains a Target FEC stack Stack TLV with the Nil FEC sub-
TLV. An Egress TLV is added before the Target FEC Stack TLV. The
address
Address field contains X (corresponding to a locally configured
address on R7). X could be an IPv4 or IPv6 address address, and the Length
field in the Egress TLV will be either 4 or 16 octets, based on the
address X's type of address type. X.
Let us look at an example of an Echo Request echo request message in a traceroute
packet. The Echo Request echo request message contains a Target FEC stack Stack TLV
with the Nil FEC sub-TLV corresponding to the complete label-stack label stack
(1002, 1004, 1007). An Egress TLV is added before the Target FEC
Stack TLV. The address Address field contains X (corresponding to a locally
configured address on destination R7). X could be an IPv4 or IPv6
address
address, and the Length field in the Egress TLV will be either 4 or
16 octets, based on the address X's type of address type. X. If the
destination/endpoint is set to zero (as in the case of the color-only
SR Policy) Policy), the sender should use the endpoint of segment 1007 (the
last segment in the segment list) as an the address for the Egress TLV.
4.2. Receiving Egress TLV in MPLS Echo Request
Any node that receives the an MPLS Echo Request echo request message and processes
it, it
is referred to as the "receiver". In the case of the ping procedure,
the actual destination/egress is the receiver. In the case of
traceroute, every node is a receiver. This document does not propose
any change in the processing for of the Nil FEC as (as defined in [RFC8029] [RFC8029])
in the Target FEC stack TLV Node node that receives an MPLS echo request. request with a Target FEC
Stack TLV. The presence of the Egress TLV does not affect the
validation of the Target FEC Stack sub-TLV at FEC-stack-depth if it
is different than Nil FEC.
Additional processing MUST be done for the Egress TLV on the receiver
node as follows: follows. Note that <RSC> refers to the Return Subcode.
1. If the Label-stack-depth is greater than 0 and the Target FEC
Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code
to 8 ("Label switched at stack-depth") stack-depth <RSC>") and Best-return-subcode Best-rtn-subcode
to Label-
stack-depth Label-stack-depth to report transit switching in the MPLS Echo Reply echo
reply message.
2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at
FEC-stack-depth is Nil FEC FEC, then do the a lookup for an exact match
of the Address field of the Egress TLV address field to any of the locally
configured interfaces or loopback addresses.
2a.
a. If the Egress TLV address lookup succeeds, set Best-return-code Best-return-
code to 36 ("Replying router is an egress for the address in
the Egress TLV for the FEC at stack depth RSC") <RSC>")
(Section 6.2) in the MPLS Echo Reply echo reply message.
2b.
b. If the Egress TLV address lookup fails, set the Best-return-code Best-return-
code to 10, "Mapping 10 ("Mapping for this FEC is not the given label at
stack-depth
RSC" <RSC>").
3. In cases where multiple Nil FECs are sent from the SR Policy
headend, 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 received packet (Size of stack-R)
becomes zero or a label with the Bottom-of-Stack bit set to 1 is
processed, all Nil FEC sub-TLVs MUST be removed and the Egress
TLV MUST be validated.
5. Backward Compatibility
The extensions defined in this document is are backward compatible with
the procedures described in [RFC8029]. A Router router that does not
support the Egress TLV, TLV will ignore it and use current the Nil-FEC Nil FEC procedures
described in [RFC8029].
When the egress node in the path does not support the extensions
defined in this document document, egress validation will not be done done, and Best-
return-code as
Best-return-code will be set to 3 ("Replying router is an egress for
the FEC at stack-
depth") stack-depth <RSC>") and Best-return- subcode set Best-rtn-subcode to stack-depth to will be set in
the MPLS Echo Reply echo reply message.
When the transit node in the path does not support the extensions
defined in this document document, Best-return-code as will be set to 8 ("Label
switched at
stack-depth") stack-depth <RSC>") and Best-return-subcode as Label-stack-depth Best-rtn-subcode to Label-stack-
depth to report transit switching will be set in the MPLS Echo Reply echo reply message.
6. IANA Considerations
The code points in section Section 6.1 and Section 6.2 have been
assigned by [IANA] by early allocation on 2023-10-05 and 2021-11-08
respectively.
6.1. New TLV
[IANA] is requested
IANA has added the following entry to update the early allocation for Egress TLV in "TLVs" registry within the "Multi-Protocol
"Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" in the "TLVs" sub-registry to reference this
document when published as an RFC.
+=======+=============+============================+ registry group [IANA-MPLS-LSP]:
+=======+============+===========+
| Value Type | Description TLV Name | Reference |
+=======+=============+============================+
+=======+============+===========+
| 32771 | Egress TLV | Section 3 of this document RFC 9655 |
+-------+-------------+----------------------------+
+-------+------------+-----------+
Table 1: TLVs Sub-Registry Registry
6.2. New Return code
[IANA] is requested to update the early allocation of the Return Code
for "Replying router is an egress for
IANA has added the address in Egress TLV" in following entry to the "Return Codes" registry
within the "Multi-Protocol "Multiprotocol Label Switching (MPLS) Label Switched Paths
(LSPs) Ping Parameters" in the "Return Codes" sub-registry to
reference this document when published as an RFC.
+=======+================================+=============+ registry group [IANA-MPLS-LSP]:
+=======+===================================+===========+
| Value | Description Meaning | Reference |
+=======+================================+=============+
+=======+===================================+===========+
| 36 | Replying router is an egress for | Section 4.2 RFC 9655 |
| | for the address in the Egress TLV for | of this |
| | for the FEC at stack depth RSC <RSC>> | document |
+-------+--------------------------------+-------------+
+-------+-----------------------------------+-----------+
Table 2: Return code Sub-Registry Codes Registry
7. Security Considerations
This document defines an additional TLV for MPLS LSP ping TLVs and follows
conforms to the mechanisms defined in [RFC8029]. All the security
considerations defined in [RFC8287] will be applicable for apply to this document. This
document and, in
addition, they do does not impose introduce any additional security challenges to be
considered.
8. Implementation Status
This section is to be removed before publishing as an RFC.
RFC-Editor: Please clean up the references cited by this section
before publication.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
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.
8.1. Juniper Networks
Organization: Juniper Networks
Implementation: JUNOS
Description: Implementation for sending and validating Egress TLV
Maturity Level: Released
Coverage: Full
Contact: shraddha@juniper.net
9. Acknowledgements
The authors would like to thank Stewart Bryant, Greg Mirsky,
Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for
their careful review and comments.
10. References
10.1.
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad,
"Updating the MPLS Label Switched Paths (LSPs) Ping
Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041,
July 2021, <https://www.rfc-editor.org/info/rfc9041>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., Mattes,
P., and D. Voyer, P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2020, 2022,
<https://www.rfc-editor.org/info/rfc9256>.
10.2.
8.2. Informative References
[I.D-ietf-idr-sr-policy-safi]
Filsfils, C., Ed.,
[IANA-MPLS-LSP]
IANA, "Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/mpls-lsp-ping-
parameters>.
[SR-POLICY-BGP]
Previdi, S., Ed., Filsfils, C., Talaulikar, K., Ed., Mattes,
P., Rosen, E., Jain, D., and S. Lin, D. Jain, "Advertising Segment Routing Policies in
BGP", draft-ietf-idr-sr-
policy-safi-04, work Work in progress, April Progress, Internet-Draft, draft-ietf-idr-sr-
policy-safi-06, 26 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
policy-safi-04>.
[IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched
Paths (LSPs) Ping Parameters",
<http://www.iana.org/assignments/mpls-lsp-ping-
parameters>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code:
policy-safi-06>.
Acknowledgements
The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. authors would like to thank Stewart Bryant, Greg Mirsky,
Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for
their careful review and comments.
Authors' Addresses
Deepti N. Rathi (editor)
Nokia
Manyata Embassy Business Park
Bangalore 560045
Karnataka
India
Email: deepti.nirmalkumarji_rathi@nokia.com
Shraddha Hegde (editor)
Juniper Networks Inc.
Exora Business Park
Bangalore 560103
KA
Karnataka
India
Email: shraddha@juniper.net
Kapil Arora
Individual Contributor
Email: kapil.it@gmail.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Nagendra Kumar Nainar
Cisco Systems, Inc.
Email: naikumar@cisco.com