| RFC 9655 | Egress Validation in LSP Ping/Traceroute | September 2024 |
| Rathi, et al. | Standards Track | [Page] |
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.¶
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.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9655.¶
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.¶
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 headend 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 for these are specified in [RFC8287]. [RFC8029] provides mechanisms primarily 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 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 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.¶
A simple MPLS 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 Generic FEC. However, there are challenges in reusing the Nil FEC and Generic FEC for validation of SR 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 is the IPv4 or IPv6 prefix and prefix length. Thus, the Generic FEC types perform an additional control plane validation. However, the details of the Generic FEC and validation procedures are not very detailed in [RFC8029]. The use case mostly specifies inter-AS (Autonomous System) VPNs as the motivation. Certain aspects of SR, such as anycast Segment Identifiers (SIDs), require clear guidelines on how the validation procedure should work. Also, the 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, the Nil FEC consists of the 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 as an intermediate FEC in the label stack. Challenges arise when all labels in the label stack are represented using the Nil FEC.¶
Section 2 discusses the problems associated with using the Nil FEC in an MPLS ping/traceroute procedure, and Sections 3 and 4 discuss simple extensions needed to solve the problem.¶
The problems and the solutions described in this document apply to the MPLS data plane. Segment Routing over IPv6 (SRv6) is out of scope for this document.¶
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.¶
The purpose of the Nil FEC, as described in [RFC8029], is to ensure that transit tunnel information is hidden 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. Section 4.4.1 of [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.¶
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 information and no validation is performed by the router. Thus, there is a high possibility that the packet may be misforwarded 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 the 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 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.¶
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, 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, and the ping/traceroute procedure will proceed as if the Egress TLV were not received.¶
The Egress TLV MAY be included in an MPLS echo request message. It is an optional TLV and, if present, MUST 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 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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This section describes aspects of LSP ping and traceroute operations that require further considerations beyond those detailed in [RFC8029].¶
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.¶
When the sender node constructs an echo request with 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 field [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 (Section 8.8.1 of [RFC9256]), the sender MUST use the address corresponding to the last segment of the SR Policy in the Address field of the Egress TLV. Some specific cases on how to derive the Address field in the Egress TLV are listed below:¶
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.¶
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.¶
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 MUST add an Egress TLV with the address obtained from the SR Policy Endpoint field [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. If 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. If the endpoint is not specified or is equal to zero (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., the ultimate egress is used as the address in the Egress TLV).¶
----R3----
/ (1003) \
(1001) / \(1005) (1007)
R1----R2(1002) R5----R6----R7(address X)
\ / (1006)
\ (1004) /
----R4----
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 either 4 or 16 octets, based on the address type of address X.¶
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 either 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.¶
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. In the case of traceroute, every node is a receiver. This document does not propose any change in the processing of the Nil FEC (as defined in [RFC8029]) in the Target FEC Stack TLV Node that receives an MPLS echo request. 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:¶
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-rtn-subcode to Label-stack-depth to report transit switching in the MPLS echo reply message.¶
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 Address field of the Egress TLV to any of the locally configured interfaces or loopback addresses.¶
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.¶
The extensions defined in this document are backward compatible with the procedures described in [RFC8029]. A router that does not support the Egress TLV will ignore it and use 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 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.¶
When the transit node in the path does not support the extensions defined in this document, Best-return-code will be set to 8 ("Label switched at stack-depth") and Best-rtn-subcode to Label-stack-depth to report transit switching in the MPLS echo reply message.¶
IANA has added the following entry to the "TLVs" registry within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group [IANA-MPLS-LSP]:¶
| Type | TLV Name | Reference |
|---|---|---|
| 32771 | Egress | RFC 9655 |
IANA has added the following entry to the "Return Codes" registry within the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry group [IANA-MPLS-LSP]:¶
| Value | Meaning | Reference |
|---|---|---|
| 36 | Replying router is an egress for the address in the Egress TLV for the FEC at stack depth RSC | RFC 9655 |
This document defines an additional TLV for MPLS LSP ping and conforms to the mechanisms defined in [RFC8029]. All the security considerations defined in [RFC8287] are applicable to this document, and they do not impose any additional security challenges to be considered.¶
The authors would like to thank Stewart Bryant, Greg Mirsky, Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for their careful review and comments.¶