Routing area D. Rathi, Ed. Internet-Draft Nokia Intended status: Standards Track S. Hegde, Ed. Expires: 23 June 2024 Juniper Networks Inc. K. Arora Individual Contributor Z. Ali N. Nainar Cisco Systems, Inc. 21 December 2023 Egress TLV for Nil FEC in Label Switched Path Ping and Traceroute Mechanisms draft-ietf-mpls-egress-tlv-for-nil-fec-09 Abstract MPLS ping and traceroute mechanism as described in RFC 8029 and related extensions for SR as defined in RFC 8287 is very useful to validate the control plane and data plane synchronization. In some environments, only some intermediate or transit nodes may have been upgraded to support these validation procedures. A simple MPLS ping and traceroute mechanism allows traversing any path without validating the control plane state. RFC 8029 supports this mechanism with Nil FEC. The procedures described in RFC 8029 mostly apply when the Nil FEC is used as an intermediate FEC in the label stack. When all labels in the label stack are represented using Nil FEC, it poses some challenges. This document introduces the new TLV as an extension to exisiting Nil FEC. It describes MPLS ping and traceroute procedures using Nil FEC with this extension to 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 23 June 2024 [Page 1] Internet-Draft Egress TLV for Nil FEC December 2023 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 23 June 2024. Copyright Notice Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 5 4.1.1. Ping Procedure . . . . . . . . . . . . . . . . . . . 5 4.1.2. Traceroute Procedure . . . . . . . . . . . . . . . . 6 4.1.3. Detailed Example . . . . . . . . . . . . . . . . . . 6 4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 7 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. New Return code . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Rathi, et al. Expires 23 June 2024 [Page 2] Internet-Draft Egress TLV for Nil FEC December 2023 1. Introduction Segment routing supports the creation of explicit paths using Adj- SIDs, Node-SIDs, and Anycast-SIDs defined in [RFC8402]. In certain usecases, 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 database of its own 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 And Maintenance (OAM) requirement is to be able to ping and trace these paths. MPLS ping and traceroute mechanism as described in [RFC8029] and related extensions for SR as defined in [RFC8287] is very useful to precisely validate the control plane and data plane synchronization. It also provides the ability to traverse multiple ECMP paths and validate each of the ECMP paths. 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 using ping and traceroute without having to obtain the Forwarding Equivalence Class (FEC) for each label.A simple MPLS ping and traceroute mechanism allows for traversing the SR-TE path without validating the control plane state.[RFC8029] supports this mechanism with FECs like Nil FEC and Generic FEC. Generic IPv4 and IPv6 FEC 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 Segment Routing 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 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 an intermediate FEC in the label stack. When all labels in the label-stack are represented using Nil FEC, it poses some challenges. Rathi, et al. Expires 23 June 2024 [Page 3] Internet-Draft Egress TLV for Nil FEC December 2023 Section 2 discusses the problems associated with using Nil FEC in an MPLS ping/traceroute procedure and Section 3 and Section 4 discusses simple extensions needed to solve the problem. 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 draft uses a single Nil FEC to represent the complete label stack in MPLS ping/traceroute packet irrespective of number of segments in the label-stack. When a router in the label-stack path receives an MPLS ping/traceroute packet, there is no definite way to decide on whether it is the intended egress router since Nil FEC does not carry any information. So there is high possibility that the packet may be mis-forwarded to an incorrect destination but the ping/ traceroute might still return success. To avoid this problem, there is a need to add additional information in the MPLS ping and traceroute packet along with Nil FEC to do minimal validation on the egress/destination router and send proper information on success and failure to the ingress router. This additional information should help to report transit router information to the ingress/initiator router that can be used by an offline application to validate the traceroute path. Thus the addition of egress information in the ping/traceroute packet will help in validating Nil-FEC on each receiving router on the label-stack path to ensure the correct destination. It can be used to check any combination of segments on any path without upgrading transit nodes. The code point used for Egress TLV is from the range 32768-65535 and can can be silently dropped if not recognised as per [RFC9041] 3. Egress TLV The Egress object is a TLV that MAY be included in an MPLS Echo Request message. It is an optional TLV and MUST appear before 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 case multiple Nil FEC is present in Target FEC Stack TLV, Egress TLV MUST be added corresponding to the ultimate egress of the label-stack. It can be used for any kind of path with Egress TLV added corresponding to the endpoint of the path. Explicit Path can be created using Node-SID, Adj-SID, Binding-SID etc, Egress TLV prefix MUST be derived from path egress/destination. The format is as specified below: Rathi, et al. Expires 23 June 2024 [Page 4] Internet-Draft Egress TLV for Nil FEC December 2023 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (4 or 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Egress TLV Type : 32771 (Section 6.1) Length : variable based on IPV4/IPV6 prefix. Length excludes the length of the Type and Length fields. Length will be 4 octets for IPv4 and 16 octets for IPv6. Prefix : This field carries the valid IPv4 prefix of length 4 octets or valid IPv6 Prefix of length 16 octets. It can be obtained from the egress of Nil FEC corresponding to the last label in the label- stack or SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy]. 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 stated earlier, when the sender node builds an Echo Request with target FEC Stack TLV, Egress TLV MUST appear before Target FEC-stack TLV in the MPLS Echo Request packet. 4.1.1. Ping Procedure When sender node builds an Echo Request with target FEC Stack TLV that contains a single NiL FEC corresponding to the last segment of the SR-TE path, the sender node MUST add an Egress TLV with the prefix obtained from SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for this Nil FEC in the Echo Request packet. The Label value in the Nil FEC MAY be set to zero. In case the endpoint is not specified or is equal to 0, the sender MUST use the prefix corresponding to the last segment of the SR-TE path as prefix for Egress TLV. Some specific cases on how to derive the Prefix in Egress TLV are listed below: Rathi, et al. Expires 23 June 2024 [Page 5] Internet-Draft Egress TLV for Nil FEC December 2023 a. If the last SID in the policy is an Adj-SID, it represents the node at the remote end of the corresponding adjacency b. If the last SID in the policy is a Binding SID, it represents the last node of the path represented by the Binding SID. 4.1.2. Traceroute Procedure when sender node builds an Echo Request with target FEC Stack TLV that contains NiL FEC corresponding to last segment of the segment- list of the SR-TE path, the sender node MUST add an Egress TLV with the prefix obtained from the SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for this Nil FEC in the Echo Request packet. Some implementations may send multiple Nil FEC but it is not really required. In case the 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 0 ( as in case of color-only SR-TE policy),the sender MUST use the the prefix corresponding to the last segment endpoint of the SR-TE path i.e. ultimate egress as the prefix for Egress TLV. 4.1.3. Detailed Example ----R3---- / (1003) \ (1001) / \(1005) (1007) R1----R2(1002) R5----R6----R7(prefix X) \ / (1006) \ (1004) / ----R4---- Figure 2: Egress TLV processing on sample topology Consider the SR-TE policy configured with label-stack as 1002, 1004 , 1007 and end point/destination as prefix X on ingress router R1 to reach egress router R7. Segment 1007 belongs to R7, which has the prefix X locally configured on it. In Ping Echo Request, with target FEC Stack TLV that contains a single NiL FEC corresponding to 1007, should add Egress TLV for endpoint/destination prefix X with type as Egress TLV, length depends on if X is IPv4 or IPv6 address and prefix as X. Rathi, et al. Expires 23 June 2024 [Page 6] Internet-Draft Egress TLV for Nil FEC December 2023 In Traceroute Echo Request, with target FEC Stack TLV that contains a single NiL FEC corresponding to the complete label-stack (1002, 1004, 1007) or multiple Nil-FEC corresponding to each label in the label- stack, should add single Egress TLV for endpoint/destination prefix X with type as Egress TLV, length depends on if X is IPv4 or IPv6 address and prefix as X. In case X is not present or is set to 0 ( as in the case of color-only SR-TE policy), sender should use the endpoint of segment 1007 as a prefix for Egress TLV. 4.2. Receiving Egress TLV in MPLS Echo Request No change in the processing for Nil FEC as defined in [RFC8029] in 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 is 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 prefix to any of the locally configured interfaces or loopback addresses. 2a. If the Egress TLV prefix lookup succeeds, set Best-return-code to 36 ("Replying router is an egress for the prefix in Egress TLV for the FEC at stack depth RSC") (Section 6.2) egress ok in MPLS Echo Reply message. 2b. If the Egress TLV prefix 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 ingress, one each corresponding to the labels in the label stack along with Egress TLV,When the packet reaches egress, the label stack becomes zero, all Nil FEC sub-TLVs MUST be removed and the Egress TLV MUST be validated. Rathi, et al. Expires 23 June 2024 [Page 7] Internet-Draft Egress TLV for Nil FEC December 2023 5. Backward Compatibility The extension proposed 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 proposed in this draft 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 proposed in this draft 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] needs to assign new value for Egress TLV in the "Multi- Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "TLVs" sub-registry. +=======+=============+============================+ | Value | Description | Reference | +=======+=============+============================+ | 32771 | Egress TLV | Section 3 of this document | +-------+-------------+----------------------------+ Table 1: TLVs Sub-Registry 6.2. New Return code [IANA] need to assign new Return Code for "Replying router is an egress for the prefix in Egress TLV" in the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in "Return Codes" sub-registry. Rathi, et al. Expires 23 June 2024 [Page 8] Internet-Draft Egress TLV for Nil FEC December 2023 +=======+================================+=============+ | Value | Description | Reference | +=======+================================+=============+ | 36 | Replying router is an egress | Section 4.2 | | | for the prefix 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. Acknowledgements Authors would like to thank Stewart Bryant, Greg Mirsky, Alexander Vainshtein and Sanga Mitra Rajgopal for their careful review and comments. 9. References 9.1. Normative References [I.D-ietf-idr-segment-routing-te-policy] 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-segment- routing-te-policy-20, work in progress, May 2020, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . Rathi, et al. Expires 23 June 2024 [Page 9] Internet-Draft Egress TLV for Nil FEC December 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . [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, . [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, . 9.2. Informative References [IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", . Authors' Addresses Deepti N. Rathi (editor) Nokia Manyata Embassy Business Park Bangalore 560045 Karnataka India Email: deepti.nirmalkumarji_rathi@nokia.com Rathi, et al. Expires 23 June 2024 [Page 10] Internet-Draft Egress TLV for Nil FEC December 2023 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 Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com Nagendra Kumar Nainar Cisco Systems, Inc. Email: naikumar@cisco.com Rathi, et al. Expires 23 June 2024 [Page 11]