Internet DRAFT - draft-ietf-mpls-egress-tlv-for-nil-fec
draft-ietf-mpls-egress-tlv-for-nil-fec
Routing area D. Rathi, Ed.
Internet-Draft Nokia
Intended status: Standards Track S. Hegde, Ed.
Expires: 2 September 2024 Juniper Networks Inc.
K. Arora
Individual Contributor
Z. Ali
N. Nainar
Cisco Systems, Inc.
1 March 2024
Egress Validation in Label Switched Path Ping and Traceroute Mechanisms
draft-ietf-mpls-egress-tlv-for-nil-fec-12
Abstract
The MPLS ping and traceroute mechanism as described in RFC 8029 and
related extensions for Segment Routing(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 Forwarding Equivalence Class
(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 a new Type-Length-Value (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 2 September 2024 [Page 1]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 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 2 September 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 5
4.1.1. Ping Mode . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Traceroute Mode . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8.1. Juniper Networks . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Rathi, et al. Expires 2 September 2024 [Page 2]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 a 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, 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] provides mechanisms to primarily validate the
data plane and secondarily to verify the data plane against the
control plane. It also provides the ability to traverse Equal cost
Mutiple Paths (ECMP) 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 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.
Generic IPv4 and IPv6 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 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
Rathi, et al. Expires 2 September 2024 [Page 3]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
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.
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.
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 on 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 high
possibility that the packet may be mis-forwarded to an incorrect
destination but the MPLS Echo Reply might still return success.
To avoid this problem, there is a need to add additional information
in the MPLS Echo Request message in ping and treaceroute mode 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 MPLS Echo Request
message in ping and traceroute mode 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 [RFC8029] and as per
clarifications from [RFC9041]
Rathi, et al. Expires 2 September 2024 [Page 4]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
3. Egress TLV
The Egress TLV MAY be included in an MPLS Echo Request message. It
is an optional TLV and if it is present it 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 case
multiple Nil FECs are 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. Prefix field of
Egress TLV MUST be derived from 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 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 when present, MUST appear before
Target FEC-stack TLV in the MPLS Echo Request packet.
Rathi, et al. Expires 2 September 2024 [Page 5]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
4.1.1. Ping Mode
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 Policy path, the sender node MUST add an Egress TLV with the
prefix obtained from SR 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 when single Nil FEC is added for multiple
labels in the label stack. 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 Policy as prefix for Egress TLV. Some
specific cases on how to derive the prefix field in the Egress TLV
are listed below:
a. If the last SID in the policy is an Adj-SID, the prefix
represents the node at the remote end of the corresponding
adjacency
b. If the last SID in the policy is a Binding SID, the prefix
represents the last node of the path represented by the Binding
SID.
4.1.2. Traceroute Mode
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 Policy, the sender node MUST add an Egress TLV with
the prefix obtained from the SR policy endpoint field
[I.D-ietf-idr-segment-routing-te-policy] to indicate the egress for
this Nil FEC in the Echo Request packet.
Although there is no requirement to do so, an implementation MAY send
multiple Nil FEC if that makes the it easier for the implementation.
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 Policy),the
sender MUST use the the prefix corresponding to the last segment
endpoint of the SR Policy path i.e. ultimate egress as the prefix for
Egress TLV.
4.1.3. Detailed Example
Rathi, et al. Expires 2 September 2024 [Page 6]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
----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 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.
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 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.
Rathi, et al. Expires 2 September 2024 [Page 7]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
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 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.
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.
Rathi, et al. Expires 2 September 2024 [Page 8]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
+=======+=============+============================+
| 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 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 to reference this
document when published as an RFC.
+=======+================================+=============+
| 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. 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
Rathi, et al. Expires 2 September 2024 [Page 9]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
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
Coverage: Full
Contact: shraddha@juniper.net
9. Acknowledgements
Authors would like to thank Stewart Bryant, Greg Mirsky, Alexander
Vainshtein, Sanga Mitra Rajgopal, 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
Rathi, et al. Expires 2 September 2024 [Page 10]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
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>.
[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-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,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
segment-routing-te-policy-20>.
[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
Rathi, et al. Expires 2 September 2024 [Page 11]
Internet-Draft Egress Validation in LSP Ping/Traceroute March 2024
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 2 September 2024 [Page 12]
