Egress Validation in Label Switched Path Ping and Traceroute Mechanisms
draft-ietf-mpls-egress-tlv-for-nil-fec-15

Routing area                                               D. Rathi, Ed.
Internet-Draft                                                     Nokia
Intended status: Standards Track                           S. Hegde, Ed.
Expires: 14 December 2024                          Juniper Networks Inc.
                                                                K. Arora
                                                  Individual Contributor
                                                                  Z. Ali
                                                               N. Nainar
                                                     Cisco Systems, Inc.
                                                            12 June 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 described in [RFC8029]
   and the related extensions for Segment Routing (SR) defined in
   [RFC8287], is 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 any path without validating the control
   plane state.  [RFC8029] supports this mechanism with the Nil
   Forwarding Equivalence Class (FEC).  The procedures outlined in
   [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 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.

Rathi, et al.           Expires 14 December 2024                [Page 1]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents 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.

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) 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
   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
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Juniper Networks  . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  12

Rathi, et al.           Expires 14 December 2024                [Page 2]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   Segment routing supports the creation of explicit paths by using one
   or more 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 routers may have the link state database of
   its 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-
   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
   [RFC8287].  [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 [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.

   A simple MPLS Echo Request/Echo Reply mechanism allows for traversing
   the SR Policy path without validating the control plane state.
   [RFC8029] supports this mechanism with FECs like Nil FEC and Generic
   FEC.  However, there are challenges in reusing the Generic FEC and
   Nil FEC for validation of SR policies [RFC9256].  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
   Generic FEC is the IPv4 or IPv6 prefix and prefix length.  Thus
   Generic FEC types perform an additional control plane validation.
   However, the details of Generic FEC and validation procedures are not
   very detailed in the [RFC8029].  The use-case mostly specifies inter-
   AS VPNs as the motivation.  Certain aspects of SR such as anycast
   SIDs require clear guidelines on how the validation procedure should
   work.  Also, Generic FEC may not be widely supported and if transit

Rathi, et al.           Expires 14 December 2024                [Page 3]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   routers are not upgraded to support validation of Generic FEC,
   traceroute may fail.  On the other hand, Nil FEC consists of the
   label and there is no other associated FEC information.  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 intermediate in the
   label stack.  When all labels in the label-stack is represented using
   Nil FEC, it poses some challenges.

   Section 2 discusses the problems associated with using Nil FEC in an
   MPLS ping/traceroute procedure and Section 3 and Section 4 discuss
   simple extensions needed to solve the problem.

   The problems and the solutions described in this document apply to
   MPLS data plane.  SRv6 is out-of-scope for this document.

2.  Problem with Nil FEC

   The purpose of Nil FEC as described in [RFC8029] is to ensure hiding
   of transit tunnel information and in some 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 message in ping and traceroute mode.  A single
   Nil FEC is used in the MPLS Echo Request message irrespective of the
   number of segments in the label stack.  As described in sec 4.4.1 of
   [RFC8029], "If the outermost FEC of the Target FEC stack is the Nil
   FEC, then the node MUST skip the Target FEC validation completely."
   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 Nil FEC does not carry any information
   and no validation is performed by the router.  So there is a high
   possibility that the packet may be mis-forwarded to an incorrect
   destination but the MPLS Echo Reply might still return success.

   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.  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.

Rathi, et al.           Expires 14 December 2024                [Page 4]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   Consequently, the inclusion of egress information in the MPLS Echo
   Request messages in ping and traceroute modes will facilitate the
   validation of Nil FEC on the egress router ensuring the correct
   destination.  It 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
   may be stepped over or an error message may be sent.

   If a transit node does not recognize the Egress TLV and chooses to
   silently drop or step over the Egress TLV, headend will continue to
   send Egress TLV in the next echo request 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
   Egress TLV, with 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 and the ping/
   traceroute procedure will proceed as if Egress TLV is not received.

3.  Egress TLV

   The Egress TLV MAY be included in an MPLS Echo Request message.  It
   is an optional TLV and, if present, MUST appear before the FEC stack
   TLV in the MPLS Echo Request packet.  This TLV can only be used in
   LSP ping/traceroute requests, generated by the head-end node of an
   LSP or SR 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, Adj-SID,
   Binding-SID, etc.  The address field of the Egress TLV must be
   derived from the path egress/destination.  The format is as specified
   below:

       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 : 32771 (Section 6.1)

Rathi, et al.           Expires 14 December 2024                [Page 5]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   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.

   Address : This field carries a valid IPv4 address of length 4 octets
   or a valid IPv6 address of length 16 octets.  It can be obtained from
   the egress of the path.  It corresponds to the last label in the
   label stack or the SR policy endpoint field
   [I.D-ietf-idr-sr-policy-safi].

4.  Procedure

   This section describes aspects of LSP ping and traceroute operations
   that require further considerations beyond [RFC8029].

4.1.  Sending Egress TLV in MPLS Echo Request

   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.

4.1.1.  Ping Mode

   When the sender node constructs an Echo Request with 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 field
   [I.D-ietf-idr-sr-policy-safi].  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 8.8.1 [RFC9256]), the sender MUST use the address
   corresponding to the last segment of the SR Policy in the address
   field for Egress TLV.  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.

      b.  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.

Rathi, et al.           Expires 14 December 2024                [Page 6]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

4.1.2.  Traceroute Mode

   When the sender node builds an Echo Request with target FEC Stack TLV
   that contains Nil FEC corresponding to the last segment of the
   segment-list of the SR Policy, the sender node MUST add an Egress TLV
   with the address obtained from the SR policy endpoint field
   [I.D-ietf-idr-sr-policy-safi].

   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 the SR Policy headend sends multiple Nil 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 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.

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

   Consider the SR Policy configured on router R1, to destination X,
   configured with 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 message.  The 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 4 or 16 based on the address X's
   address type.

   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 4 or 16 based

Rathi, et al.           Expires 14 December 2024                [Page 7]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   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.

4.2.  Receiving Egress TLV in MPLS Echo Request

   Any node that receives the MPLS Echo Request message and processes
   it, is referred to as the "receiver".  In 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 Nil FEC as defined in [RFC8029] in
   the Target FEC stack TLV Node that receives an MPLS echo request.
   The presence of Egress TLV does not affect the validation of 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:

   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") and Best-return-subcode to Label-
   stack-depth to report transit switching in MPLS 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 then do the lookup for an exact match of
   the Egress TLV address field to any of the locally configured
   interfaces or loopback addresses.

   2a.  If the Egress TLV address lookup succeeds, set Best-return-code
   to 36 ("Replying router is an egress for the address in Egress TLV
   for the FEC at stack depth RSC") (Section 6.2) in MPLS Echo Reply
   message.

   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"

   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 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 Bottom-of-Stack bit set to 1 is processed, all Nil FEC
   sub-TLVs MUST be removed and the Egress TLV MUST be validated.

Rathi, et al.           Expires 14 December 2024                [Page 8]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

5.  Backward Compatibility

   The extensions defined in this document is backward compatible with
   procedures described in [RFC8029].  A Router that does not support
   Egress TLV, will ignore it and use current the Nil-FEC procedures
   described in [RFC8029].

   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.

   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.

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 to update the early allocation for Egress TLV in
   the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
   (LSPs) Ping Parameters" in the "TLVs" sub-registry to reference this
   document when published as an RFC.

           +=======+=============+============================+
           | Value | Description | Reference                  |
           +=======+=============+============================+
           | 32771 |  Egress TLV | Section 3 of this document |
           +-------+-------------+----------------------------+

                        Table 1: TLVs Sub-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 the address in Egress TLV" in
   the "Multi-Protocol Label Switching (MPLS) Label Switched Paths
   (LSPs) Ping Parameters" in the "Return Codes" sub-registry to
   reference this document when published as an RFC.

Rathi, et al.           Expires 14 December 2024                [Page 9]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

         +=======+================================+=============+
         | Value |          Description           | Reference   |
         +=======+================================+=============+
         | 36    |  Replying router is an egress  | Section 4.2 |
         |       | for the address in Egress TLV  | of this     |
         |       | for the FEC at stack depth RSC | document    |
         +-------+--------------------------------+-------------+

                    Table 2: Return code Sub-Registry

7.  Security Considerations

   This document defines additional MPLS LSP ping TLVs and follows the
   mechanisms defined in [RFC8029].  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.

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

Rathi, et al.           Expires 14 December 2024               [Page 10]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   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.  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>.

Rathi, et al.           Expires 14 December 2024               [Page 11]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Bogdanov, A., Mattes,
              P., and D. Voyer, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2020,
              <https://www.rfc-editor.org/info/rfc9256>.

10.2.  Informative References

   [I.D-ietf-idr-sr-policy-safi]
              Filsfils, C., Ed., Previdi, S., Ed., Talaulikar, K.,
              Mattes, P., Rosen, E., Jain, D., and S. Lin, "Advertising
              Segment Routing Policies in BGP",  draft-ietf-idr-sr-
              policy-safi-04,  work in progress, April 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: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

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
   India
   Email: shraddha@juniper.net

   Kapil Arora
   Individual Contributor
   Email: kapil.it@gmail.com

Rathi, et al.           Expires 14 December 2024               [Page 12]
Internet-Draft  Egress Validation in LSP Ping/Traceroute       June 2024

   Zafar Ali
   Cisco Systems, Inc.
   Email: zali@cisco.com

   Nagendra Kumar Nainar
   Cisco Systems, Inc.
   Email: naikumar@cisco.com

Rathi, et al.           Expires 14 December 2024               [Page 13]