Egress Validation in Label Switched Path Ping and Traceroute Mechanisms

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

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

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)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 32771 (Section 6.1)¶

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

                  ----R3----
                 /  (1003)  \
      (1001)    /            \(1005)     (1007)
        R1----R2(1002)        R5----R6----R7(address X)
                \            /     (1006)
                 \   (1004) /
                  ----R4----

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

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

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

Authors' Addresses