| Internet-Draft | Egress TLV for Nil FEC | September 2020 |
| Rathi, et al. | Expires 2 April 2021 | [Page] |
Segment routing supports the creation of explicit paths using adjacency- sids, node-sids, and anycast-sids. The SR-TE paths are built by stacking the labels that represent the nodes and links in the explicit path. A very useful Operations And Maintenance (OAM) requirement is to be able to ping and trace these paths. A simple mpls ping/traceroute mechanism comprises of ability to traverse the SR-TE path without having to validate the control plane state. This document describes mpls ping and traceroute procedures using Nil FEC with additional extensions.¶
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.¶
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 2 April 2021.¶
Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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 ability to traverse multiple ECMP paths and validate each of the ECMP paths.¶
In certain usecases, the traffic engineered (TE) paths are built using mechanisms described in [I.D-ietf-spring-segment-routing-policy]. When the TE paths are built by the controller, the head-end routers may not have the complete database of the network and may not be aware of the FEC associated with labels that are used in the label stack. In such cases, it is useful to have ability to traverse the paths using ping and traceroute without having to obtain the Forwarding Equivalence Class (FEC) for each label. RFC 8029 supports this mechanism with Nil FEC. Nil FEC consists of the label and there is no other associated FEC information. The procedures described in RFC 8029 are mostly applicable when the Nil FEC is used where the Nil FEC is an intermediate FEC in the label stack. When all labels are represented using Nil FEC, it poses some challenges.¶
Section 2 discusses the problems associated with using all Nil FECs in a MPLS ping/traceroute procedure and Section 3 and Section 4 discusses simple extensions needed to solve the problem.¶
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 not known.¶
The MPLS ping/traceroute packet consists of only single Nil FEC corresponding to the complete label stack irrespective of number of segments in the label-stack. When router in the label-stack path receives MPLS ping/traceroute packets, there is no definite way to decide on whether its egress or transit since Nil FEC does not carry any information. So there is high possibility that the packet may be mis-forwarded to incorrect destination but the ping/traceroute might still show success.¶
To avoid this problem, there is a need to add additional information in the MPLS ping/traceroute packet along with Nil FEC that will help to do needed validation on each router of the label-stack path and sends proper information to ingress router on success and failure.¶
Thus it will be useful to add egress information in ping/traceroute packet that will help in validating Nil-FEC on each receiving router on label-stack path to ensure the correct destination.¶
The Egress object is a TLV that MAY be included in an MPLS Echo Request message. Its an optional TLV and should appear before FEC-stack TLV in the MPLS Echo Request packet. In case multiple Nil FEC is present in Target FEC Stack TLV, Egress TLV should be added corresponding to the ultimate egress of the label-stack. 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 = TBD (EGRESS TLV) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
Type : TBD¶
Length : variable based on IPV4/IPV6 prefix. Length excludes the length of Type and length field. 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 egress of Nil FEC corresponding to last label in the label-stack or SR-TE policy endpoint field [I.D-ietf-idr-segment-routing-te-policy].¶
This section describes aspects of LSP Ping and Traceroute operations that require further considerations beyond [RFC8029].¶
As stated earlier, when the sender node builds a Echo Request with target FEC Stack TLV, Egress TLV SHOULD appear before Target FEC-stack TLV in MPLS Echo Request packet.¶
Ping¶
When the sender node builds a Echo Request with target FEC Stack TLV that contains a single NiL FEC corresponding to the last segment of the SR-TE path, sender node MUST add a Egress TLV with 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. In case endpoint is not specified or is equal to 0, sender MUST use the prefix corresponding to last segment of the SR-TE path as prefix for Egress TLV.¶
Traceroute¶
When the sender node builds a Echo Request with target FEC Stack TLV that contains a single NiL FEC corresponding to complete segment-list of the SR-TE path, sender node MUST add a Egress TLV with 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. In case of multiple Nil FEC, Egress TLV SHOULD be added with prefix that indicate endpoint for last Nil-FEC corresponding to respective segment in label-stack. In case endpoint is not specified or is equal to 0, sender MUST use the prefix corresponding to the last segment endpoint of the SR-TE path i.e. ultimate egress as prefix for Egress TLV.¶
Consider the SR-TE policy configured with label-stack as 1001, 1002 , 1003 and end point as X on ingress router N1 to reach egress router N3. Segment 1003 belongs to N3 that has prefix X configured on it locally.¶
In Ping Echo Request, with target FEC Stack TLV that contains a single NiL FEC corresponding to 1003, should add Egress TLV for endpoint X with type as EGRESS-TLV, length depends on if X is IPv4 or IPv6 address and prefix as X.¶
In Traceroute Echo Request, with target FEC Stack TLV that contains a single NiL FEC corresponding to complete label-stack (1001, 1002, 1003) or multiple Nil-FEC corresponding to each label in label-stack, should add single Egress TLV for endpoint X with type as EGRESS-TLV, length depends on if X is IPv4 or IPv6 address and prefix as X or endpoint of segment 1003. In case X is not present or is set to 0, sender should use endpoint of segment 1003 as prefix for Egress TLV.¶
No change in the processing for Nil FEC as defined in [RFC8029] in Target FEC stack TLV Node that receives an MPLS echo request.¶
Additional processing done for Egress TLV on receiver node as follows:¶
1. Get the prefix from the Egress TLV¶
2. Look up for an exact match of the prefix to any of locally configured interface as well loopback address.¶
3. Set Best-return-code to 3 ("Replying router is an egress for the FEC at stack-depth") if found or to 8 ("Label switched at stack-depth") and Best-rtn-subcode to Label-stack-depth to report transit switching in MPLS Echo Reply message.¶
4. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is Nil FEC and look up for EGRESS TLV prefix fails, set the Best-return-code to 10, "Mapping for this FEC is not the given label at stack-depth".¶
5. If the Label-stack-depth is greater than 0 and the Target FEC Stack sub-TLV at FEC-stack-depth is Nil FEC and look up for EGRESS TLV prefix succeeds, set the Best-return-code to 10, "Mapping for this FEC is not the given label at stack-depth".¶
The extension proposed in this document is backward compatible with procedures described in [RFC8029].¶
TBD.¶