rfc9655.original | rfc9655.txt | |||
---|---|---|---|---|
Routing area D. Rathi, Ed. | Internet Engineering Task Force (IETF) D. Rathi, Ed. | |||
Internet-Draft Nokia | Request for Comments: 9655 Nokia | |||
Intended status: Standards Track S. Hegde, Ed. | Category: Standards Track S. Hegde, Ed. | |||
Expires: 14 December 2024 Juniper Networks Inc. | ISSN: 2070-1721 Juniper Networks Inc. | |||
K. Arora | K. Arora | |||
Individual Contributor | Individual Contributor | |||
Z. Ali | Z. Ali | |||
N. Nainar | N. Nainar | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
12 June 2024 | September 2024 | |||
Egress Validation in Label Switched Path Ping and Traceroute Mechanisms | Egress Validation in Label Switched Path Ping and Traceroute Mechanisms | |||
draft-ietf-mpls-egress-tlv-for-nil-fec-15 | ||||
Abstract | Abstract | |||
The MPLS ping and traceroute mechanisms, as described in [RFC8029] | The MPLS ping and traceroute mechanisms described in RFC 8029 and the | |||
and the related extensions for Segment Routing (SR) defined in | related extensions for Segment Routing (SR) defined in RFC 8287 are | |||
[RFC8287], is highly valuable for validating control plane and data | highly valuable for validating control plane and data plane | |||
plane synchronization. In certain environments, only some | synchronization. In certain environments, only some intermediate or | |||
intermediate or transit nodes may have been upgraded to support these | transit nodes may have been upgraded to support these validation | |||
validation procedures. A straightforward MPLS ping and traceroute | procedures. A straightforward MPLS ping and traceroute mechanism | |||
mechanism allows traversing any path without validating the control | allows traversal of any path without validation of the control plane | |||
plane state. [RFC8029] supports this mechanism with the Nil | state. RFC 8029 supports this mechanism with the Nil Forwarding | |||
Forwarding Equivalence Class (FEC). The procedures outlined in | Equivalence Class (FEC). The procedures outlined in RFC 8029 are | |||
[RFC8029] is primarily applicable when the Nil FEC is used as an | primarily applicable when the Nil FEC is used as an intermediate FEC | |||
intermediate FEC in the label stack. However, challenges arise when | in the label stack. However, challenges arise when all labels in the | |||
all labels in the label stack are represented using the Nil FEC. | label stack are represented using the Nil FEC. | |||
This document introduces a new Type-Length-Value (TLV) as an | This document introduces a new Type-Length-Value (TLV) as an | |||
extension to the existing Nil FEC. It describes MPLS ping and | extension to the existing Nil FEC. It describes MPLS ping and | |||
traceroute procedures using the Nil FEC with this extension to | traceroute procedures using the Nil FEC with this extension to | |||
address and overcome these challenges. | address and 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 | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This is an Internet Standards Track document. | |||
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 | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Further information on | |||
Internet Standards is available in Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 14 December 2024. | 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 Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
described in Section 4.e of the Trust Legal Provisions and are | include Revised BSD License text as described in Section 4.e of the | |||
provided without warranty as described in the Revised BSD License. | Trust Legal Provisions and are provided without warranty as described | |||
in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
2. Problem with Nil FEC . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Requirements Language | |||
3. Egress TLV . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2. Problem with Nil FEC | |||
4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Egress TLV | |||
4.1. Sending Egress TLV in MPLS Echo Request . . . . . . . . . 6 | 4. Procedure | |||
4.1.1. Ping Mode . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Sending Egress TLV in MPLS Echo Request | |||
4.1.2. Traceroute Mode . . . . . . . . . . . . . . . . . . . 7 | 4.1.1. Ping Mode | |||
4.1.3. Detailed Example . . . . . . . . . . . . . . . . . . 7 | 4.1.2. Traceroute Mode | |||
4.2. Receiving Egress TLV in MPLS Echo Request . . . . . . . . 8 | 4.1.3. Detailed Example | |||
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 | 4.2. Receiving Egress TLV in MPLS Echo Request | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 5. Backward Compatibility | |||
6.1. New TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 6. IANA Considerations | |||
6.2. New Return code . . . . . . . . . . . . . . . . . . . . . 9 | 6.1. New TLV | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 6.2. New Return Code | |||
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations | |||
8.1. Juniper Networks . . . . . . . . . . . . . . . . . . . . 10 | 8. References | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 8.1. Normative References | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 8.2. Informative References | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 | Acknowledgements | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 12 | Authors' Addresses | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
Segment routing supports the creation of explicit paths by using one | Segment routing supports the creation of explicit paths by using one | |||
or more Link State IGP Segments or BGP Segments defined in [RFC8402]. | or more Link-State IGP Segments or BGP Segments defined in [RFC8402]. | |||
In certain use cases, the TE paths are built using mechanisms | In certain use cases, the TE paths are built using mechanisms | |||
described in [RFC9256] by stacking the labels that represent the | described in [RFC9256] by stacking the labels that represent the | |||
nodes and links in the explicit path. Controllers are often deployed | nodes and links in the explicit path. Controllers are often deployed | |||
to construct paths across multi-domain networks. In such | to construct paths across multi-domain networks. In such | |||
deployments, the head-end routers may have the link state database of | deployments, the headend routers may have the link-state database of | |||
its domain and may not be aware of the FEC associated with labels | its domain and may not be aware of the FEC associated with labels | |||
that are used by the controller to build paths across multiple | that are used by the controller to build paths across multiple | |||
domains. A very useful Operations, Administration, and Maintenance | domains. A very useful Operations, Administration, and Maintenance | |||
(OAM) requirement is to be able to ping and trace these paths. | (OAM) requirement is to be able to ping and trace these paths. | |||
[RFC8029] describes a simple and efficient mechanism to detect data- | [RFC8029] describes a simple and efficient mechanism to detect data | |||
plane failures in MPLS Label Switched Paths (LSPs). It defines a | plane failures in MPLS Label Switched Paths (LSPs). It defines a | |||
probe message called an "MPLS echo request" and a response message | probe message called an "MPLS echo request" and a response message | |||
called an "MPLS echo reply" for returning the result of the probe. | called an "MPLS echo reply" for returning the result of the probe. | |||
SR-related extensions to Echo Request/Echo Reply are specified in | SR-related extensions for these are specified in [RFC8287]. | |||
[RFC8287]. [RFC8029] primarily provides mechanisms to validate the | [RFC8029] provides mechanisms primarily to validate the data plane | |||
data plane and, secondarily, to verify the consistency of the data | and secondarily to verify the consistency of the data plane with the | |||
plane with the control plane. It also provides the ability to | control plane. It also provides the ability to traverse Equal-Cost | |||
traverse Equal-cost Multiple Paths (ECMP) and validate each of the | Multipaths (ECMPs) and validate each of the ECMP paths. The Target | |||
ECMP paths. Target FEC Stack TLV [RFC8029] contains sub-TLVs that | FEC Stack TLV [RFC8029] contains sub-TLVs that carry information | |||
carry information about the label. This information gets validated | about the label. This information gets validated on each node for | |||
on each node for traceroute and on the egress for ping. The use of | traceroute and on the egress for ping. The use of the Target FEC | |||
Target FEC requires all nodes in the network to have implemented the | requires all nodes in the network to have implemented the validation | |||
validation procedures. All intermediate nodes may not have been | procedures, but all intermediate nodes may not have been upgraded to | |||
upgraded to support validation procedures. In such cases, it is | support validation procedures. In such cases, it is useful to have | |||
useful to have the ability to traverse the paths in ping/traceroute | the ability to traverse the paths in ping/traceroute mode without | |||
mode without having to obtain the FEC for each label. | having to obtain the FEC for each label. | |||
A simple MPLS Echo Request/Echo Reply mechanism allows for traversing | A simple MPLS echo request/reply mechanism allows for traversing the | |||
the SR Policy path without validating the control plane state. | SR Policy path without validating the control plane state. [RFC8029] | |||
[RFC8029] supports this mechanism with FECs like Nil FEC and Generic | supports this mechanism with FECs like the Nil FEC and Generic FEC. | |||
FEC. However, there are challenges in reusing the Generic FEC and | However, there are challenges in reusing the Nil FEC and Generic FEC | |||
Nil FEC for validation of SR policies [RFC9256]. Generic IPv4 prefix | for validation of SR Policies [RFC9256]. The Generic IPv4 prefix and | |||
and Generic IPv6 prefix FECs are used when the protocol that is | Generic IPv6 prefix FECs are used when the protocol that is | |||
advertising the label is unknown. The information that is carried in | advertising the label is unknown. The information that is carried in | |||
Generic FEC is the IPv4 or IPv6 prefix and prefix length. Thus | the Generic FEC is the IPv4 or IPv6 prefix and prefix length. Thus, | |||
Generic FEC types perform an additional control plane validation. | the Generic FEC types perform an additional control plane validation. | |||
However, the details of Generic FEC and validation procedures are not | However, the details of the Generic FEC and validation procedures are | |||
very detailed in the [RFC8029]. The use-case mostly specifies inter- | not very detailed in [RFC8029]. The use case mostly specifies inter- | |||
AS VPNs as the motivation. Certain aspects of SR such as anycast | AS (Autonomous System) VPNs as the motivation. Certain aspects of | |||
SIDs require clear guidelines on how the validation procedure should | SR, such as anycast Segment Identifiers (SIDs), require clear | |||
work. Also, Generic FEC may not be widely supported and if transit | guidelines on how the validation procedure should work. Also, the | |||
routers are not upgraded to support validation of Generic FEC, | Generic FEC may not be widely supported, and if transit routers are | |||
traceroute may fail. On the other hand, Nil FEC consists of the | not upgraded to support validation of Generic FEC, traceroute may | |||
label and there is no other associated FEC information. Nil FEC is | fail. On the other hand, the Nil FEC consists of the label, and | |||
used to traverse the path without validation for cases where the FEC | there is no other associated FEC information. The Nil FEC is used to | |||
is not defined or routers are not upgraded to support the FECs. | traverse the path without validation for cases where the FEC is not | |||
Thus, it can be used to check any combination of segments on any data | defined or routers are not upgraded to support the FECs. Thus, it | |||
path. The procedures described in [RFC8029] are mostly applicable | can be used to check any combination of segments on any data path. | |||
when the Nil FEC is used where the Nil FEC is intermediate in the | The procedures described in [RFC8029] are mostly applicable when the | |||
label stack. When all labels in the label-stack is represented using | Nil FEC is used as an intermediate FEC in the label stack. | |||
Nil FEC, it poses some challenges. | Challenges arise when all labels in the label stack are represented | |||
using the Nil FEC. | ||||
Section 2 discusses the problems associated with using Nil FEC in an | Section 2 discusses the problems associated with using the Nil FEC in | |||
MPLS ping/traceroute procedure and Section 3 and Section 4 discuss | an MPLS ping/traceroute procedure, and Sections 3 and 4 discuss | |||
simple extensions needed to solve the problem. | simple extensions needed to solve the problem. | |||
The problems and the solutions described in this document apply to | The problems and the solutions described in this document apply to | |||
MPLS data plane. SRv6 is out-of-scope for this document. | the MPLS data plane. Segment Routing over IPv6 (SRv6) is out of | |||
scope for this document. | ||||
1.1. 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. | ||||
2. Problem with Nil FEC | 2. Problem with Nil FEC | |||
The purpose of Nil FEC as described in [RFC8029] is to ensure hiding | The purpose of the Nil FEC, as described in [RFC8029], is to ensure | |||
of transit tunnel information and in some cases to avoid false | that transit tunnel information is hidden and, in some cases, to | |||
negatives when the FEC information is unknown. | avoid false negatives when the FEC information is unknown. | |||
This document uses a Nil FEC to represent the complete label stack in | 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 | 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 | 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 | number of segments in the label stack. Section 4.4.1 of [RFC8029] | |||
[RFC8029], "If the outermost FEC of the Target FEC stack is the Nil | notes: | |||
FEC, then the node MUST skip the Target FEC validation completely." | ||||
When a router in the label-stack path receives an MPLS Echo Request | | 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 | message, there is no definite way to decide whether it is the | |||
intended egress router since Nil FEC does not carry any information | intended egress router since the Nil FEC does not carry any | |||
and no validation is performed by the router. So there is a high | information and no validation is performed by the router. Thus, | |||
possibility that the packet may be mis-forwarded to an incorrect | there is a high possibility that the packet may be misforwarded to an | |||
destination but the MPLS Echo Reply might still return success. | incorrect destination but the MPLS echo reply might still return | |||
success. | ||||
To mitigate this issue, it is necessary to include additional | To mitigate this issue, it is necessary to include additional | |||
information in the MPLS Echo Request message in both ping and | information in the MPLS echo request message in both ping and | |||
traceroute modes, along with the Nil FEC, to perform minimal | traceroute modes, along with the Nil FEC, to perform minimal | |||
validation on the egress/destination router. This will enable the | validation on the egress/destination router. This will enable the | |||
router to send appropriate success and failure information to the | router to send appropriate success and failure information to the | |||
headend router of the SR Policy. This supplementary information | headend router of the SR Policy. This supplementary information | |||
should assist in reporting transit router details to the headend | should assist in reporting transit router details to the headend | |||
router, which can be utilized by an offline application to validate | router, which can be utilized by an offline application to validate | |||
the traceroute path. | the traceroute path. | |||
Consequently, the inclusion of egress information in the MPLS Echo | Consequently, the inclusion of egress information in the MPLS echo | |||
Request messages in ping and traceroute modes will facilitate the | request messages in ping and traceroute modes will facilitate the | |||
validation of Nil FEC on the egress router ensuring the correct | validation of the Nil FEC on the egress router, ensuring the correct | |||
destination. It can be employed to verify any combination of | destination. It can be employed to verify any combination of | |||
segments on any path without requiring upgrades to transit nodes. | segments on any path without requiring upgrades to transit nodes. | |||
The code point used for Egress TLV is from the range 32768-65535 and | The Egress TLV can be silently dropped if not recognized, as per | |||
can be silently dropped if not recognized as per [RFC8029] and as per | [RFC8029] and the clarifications in [RFC9041] regarding code points | |||
clarifications from [RFC9041]. Alternately, the un-recognized TLV | in the range 32768-65535. Alternately, the unrecognized TLV may be | |||
may be stepped over or an error message may be sent. | stepped over, or an error message may be sent. | |||
If a transit node does not recognize the Egress TLV and chooses to | 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 | silently drop or step over the Egress TLV, the headend will continue | |||
send Egress TLV in the next echo request message and if egress | to send the Egress TLV in the next echo request message, and if | |||
recognizes the Egress TLV, egress validation will be executed at the | egress recognizes the Egress TLV, egress validation will be executed | |||
egress. If a transit node does not recognize the Egress TLV and | at the egress. If a transit node does not recognize the Egress TLV | |||
chooses to send an error message, the headend will log the message | and chooses to send an error message, the headend will log the | |||
for informational purposes and continue to send echo requests with | message for informational purposes and continue to send echo requests | |||
Egress TLV, with TTL incremented. If the egress node does not | with the Egress TLV, with the TTL incremented. If the egress node | |||
recognize the Egress TLV and chooses to silently drop or step over | does not recognize the Egress TLV and chooses to silently drop or | |||
the Egress TLV, egress validation will not be done and the ping/ | step over the Egress TLV, egress validation will not be done, and the | |||
traceroute procedure will proceed as if Egress TLV is not received. | ping/traceroute procedure will proceed as if the Egress TLV were not | |||
received. | ||||
3. Egress TLV | 3. Egress TLV | |||
The Egress TLV MAY be included in an MPLS Echo Request message. It | 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 | is an optional TLV and, if present, MUST appear before the Target FEC | |||
TLV in the MPLS Echo Request packet. This TLV can only be used in | Stack TLV in the MPLS echo request packet. This TLV can only be used | |||
LSP ping/traceroute requests, generated by the head-end node of an | in LSP ping/traceroute requests that are generated by the headend | |||
LSP or SR policy for which verification is performed. In cases where | node of an LSP or SR Policy for which verification is performed. In | |||
multiple Nil FECs are present in the Target FEC Stack TLV, the Egress | cases where multiple Nil FECs are present in the Target FEC Stack | |||
TLV must be added corresponding to the ultimate egress of the label | TLV, the Egress TLV must be added corresponding to the ultimate | |||
stack. Explicit paths can be created using Node-SID, Adj-SID, | egress of the label stack. Explicit paths can be created using Node- | |||
Binding-SID, etc. The address field of the Egress TLV must be | SID, Adj-SID, Binding SID, etc. The Address field of the Egress TLV | |||
derived from the path egress/destination. The format is as specified | must be derived from the path egress/destination. The format is as | |||
below: | specified in Figure 1. | |||
0 1 2 3 | 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 | 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 | | | Type = 32771 (Egress TLV) | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Address (4 or 16 octets) | | | Address (4 or 16 octets) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 1: Egress TLV | Figure 1: Egress TLV | |||
Type : 32771 (Section 6.1) | 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 | Length: Variable, based on IPv4/IPv6 address. Length excludes the | |||
or a valid IPv6 address of length 16 octets. It can be obtained from | length of the Type and Length fields. Length is 4 octets for IPv4 | |||
the egress of the path. It corresponds to the last label in the | and 16 octets for IPv6. | |||
label stack or the SR policy endpoint field | ||||
[I.D-ietf-idr-sr-policy-safi]. | Address: This field carries a valid 4-octet IPv4 address or a valid | |||
16-octet IPv6 address. The address can be obtained from the | ||||
egress of the path and corresponds to the last label in the label | ||||
stack or the SR Policy Endpoint field [SR-POLICY-BGP]. | ||||
4. Procedure | 4. Procedure | |||
This section describes aspects of LSP ping and traceroute operations | This section describes aspects of LSP ping and traceroute operations | |||
that require further considerations beyond [RFC8029]. | that require further considerations beyond those detailed in | |||
[RFC8029]. | ||||
4.1. Sending Egress TLV in MPLS Echo Request | 4.1. Sending Egress TLV in MPLS Echo Request | |||
As previously mentioned, when the sender node constructs an Echo | As previously mentioned, when the sender node constructs an echo | |||
Request with a Target FEC Stack TLV, the Egress TLV, if present, MUST | 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 | appear before the Target FEC Stack TLV in the MPLS echo request | |||
packet. | packet. | |||
4.1.1. Ping Mode | 4.1.1. Ping Mode | |||
When the sender node constructs an Echo Request with target FEC Stack | When the sender node constructs an echo request with a Target FEC | |||
TLV that contains a single Nil FEC corresponding to the last segment | Stack TLV that contains a single Nil FEC corresponding to the last | |||
of the SR Policy path, the sender node MUST add an Egress TLV with | segment of the SR Policy path, the sender node MUST add an Egress TLV | |||
the address obtained from the SR policy endpoint field | with the address obtained from the SR Policy Endpoint field | |||
[I.D-ietf-idr-sr-policy-safi]. The Label value in the Nil FEC MAY be | [SR-POLICY-BGP]. The Label value in the Nil FEC MAY be set to zero | |||
set to zero when a single Nil FEC is added for multiple labels in the | when a single Nil FEC is added for multiple labels in the label | |||
label stack. In case the endpoint is not specified or is equal to | stack. In case the endpoint is not specified or is equal to zero | |||
zero (Sec 8.8.1 [RFC9256]), the sender MUST use the address | (Section 8.8.1 of [RFC9256]), the sender MUST use the address | |||
corresponding to the last segment of the SR Policy in the address | corresponding to the last segment of the SR Policy in the Address | |||
field for Egress TLV. Some specific cases on how to derive the | field of the Egress TLV. Some specific cases on how to derive the | |||
address field in the Egress TLV are listed below: | Address field in the Egress TLV are listed below: | |||
a. If the last SID in the SR policy is an Adj-SID, the address | * If the last SID in the SR Policy is an Adj-SID, the Address field | |||
field in the Egress TLV is derived from the node at the remote end | in the Egress TLV is derived from the node at the remote end of | |||
of the corresponding adjacency. | the corresponding adjacency. | |||
b. If the last SID in the SR policy is a Binding SID, the address | * 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 | field in the Egress TLV is derived from the last node of the path | |||
represented by the Binding SID. | represented by the Binding SID. | |||
4.1.2. Traceroute Mode | 4.1.2. Traceroute Mode | |||
When the sender node builds an Echo Request with target FEC Stack TLV | When the sender node builds an echo request with a Target FEC Stack | |||
that contains Nil FEC corresponding to the last segment of the | 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 | segment list of the SR Policy, the sender node MUST add an Egress TLV | |||
with the address obtained from the SR policy endpoint field | with the address obtained from the SR Policy Endpoint field | |||
[I.D-ietf-idr-sr-policy-safi]. | [SR-POLICY-BGP]. | |||
Although there is no requirement to do so, an implementation MAY send | Although there is no requirement to do so, an implementation MAY send | |||
multiple Nil FECs if that makes it easier for the implementation. In | multiple Nil FECs if that makes it easier for the implementation. If | |||
case the SR Policy headend sends multiple Nil FECs the last one MUST | 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 | 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 | set to zero for the last Nil FEC. If the endpoint is not specified | |||
specified or is equal to zero (Sec 8.8.1 [RFC9256]), the sender MUST | or is equal to zero (Section 8.8.1 of [RFC9256]), the sender MUST use | |||
use the address corresponding to the last segment endpoint of the SR | the address corresponding to the last segment endpoint of the SR | |||
Policy path i.e. ultimate egress as the address for the Egress TLV. | Policy path (i.e., the ultimate egress is used as the address in the | |||
Egress TLV). | ||||
4.1.3. Detailed Example | 4.1.3. Detailed Example | |||
----R3---- | ----R3---- | |||
/ (1003) \ | / (1003) \ | |||
(1001) / \(1005) (1007) | (1001) / \(1005) (1007) | |||
R1----R2(1002) R5----R6----R7(address X) | R1----R2(1002) R5----R6----R7(address X) | |||
\ / (1006) | \ / (1006) | |||
\ (1004) / | \ (1004) / | |||
----R4---- | ----R4---- | |||
Figure 2: Egress TLV processing on sample topology | Figure 2: Egress TLV Processing in Sample Topology | |||
Consider the SR Policy configured on router R1, to destination X, | Consider the SR Policy configured on router R1 to destination X, | |||
configured with label-stack as 1002, 1004, 1007. Segment 1007 | configured with label stack as 1002, 1004, 1007. Segment 1007 | |||
belongs to R7, which has the address X locally configured on it. | 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 | 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- | 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 | TLV. An Egress TLV is added before the Target FEC Stack TLV. The | |||
address field contains X (corresponding to a locally configured | Address field contains X (corresponding to a locally configured | |||
address on R7). X could be an IPv4 or IPv6 address and the Length | address on R7). X could be an IPv4 or IPv6 address, and the Length | |||
field in the Egress TLV will be 4 or 16 based on the address X's | field in the Egress TLV will be either 4 or 16 octets, based on the | |||
address type. | address type of address X. | |||
Let us look at an example of an Echo Request message in a traceroute | 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 | packet. The echo request message contains a Target FEC Stack TLV | |||
with the Nil FEC sub-TLV corresponding to the complete label-stack | with the Nil FEC sub-TLV corresponding to the complete label stack | |||
(1002, 1004, 1007). An Egress TLV is added before the Target FEC | (1002, 1004, 1007). An Egress TLV is added before the Target FEC | |||
Stack TLV. The address field contains X (corresponding to a locally | Stack TLV. The Address field contains X (corresponding to a locally | |||
configured address on destination R7). X could be an IPv4 or IPv6 | configured address on destination R7). X could be an IPv4 or IPv6 | |||
address and the Length field in the Egress TLV will be 4 or 16 based | address, and the Length field in the Egress TLV will be either 4 or | |||
on the address X's address type. If the destination/endpoint is set | 16 octets, based on the address type of address X. If the | |||
to zero (as in the case of the color-only SR Policy) sender should | destination/endpoint is set to zero (as in the case of the color-only | |||
use the endpoint of segment 1007 (the last segment in the segment | SR Policy), the sender should use the endpoint of segment 1007 (the | |||
list) as an address for the Egress TLV. | last segment in the segment list) as the address for the Egress TLV. | |||
4.2. Receiving Egress TLV in MPLS Echo Request | 4.2. Receiving Egress TLV in MPLS Echo Request | |||
Any node that receives the MPLS Echo Request message and processes | Any node that receives an MPLS echo request message and processes it | |||
it, is referred to as the "receiver". In case of the ping procedure, | is referred to as the "receiver". In the case of the ping procedure, | |||
the actual destination/egress is the receiver. In the case of | the actual destination/egress is the receiver. In the case of | |||
traceroute, every node is a receiver. This document does not propose | traceroute, every node is a receiver. This document does not propose | |||
any change in the processing for Nil FEC as defined in [RFC8029] in | any change in the processing of the Nil FEC (as defined in [RFC8029]) | |||
the Target FEC stack TLV Node that receives an MPLS echo request. | in the Target FEC Stack TLV Node that receives an MPLS echo request. | |||
The presence of Egress TLV does not affect the validation of Target | The presence of the Egress TLV does not affect the validation of the | |||
FEC Stack sub-TLV at FEC-stack-depth if it is different than Nil FEC. | 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 | Additional processing MUST be done for the Egress TLV on the receiver | |||
node as follows: | node as follows: | |||
1. If the Label-stack-depth is greater than 0 and the Target FEC | 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 | Stack sub-TLV at FEC-stack-depth is Nil FEC, set Best-return-code | |||
8 ("Label switched at stack-depth") and Best-return-subcode to Label- | to 8 ("Label switched at stack-depth") and Best-rtn-subcode to | |||
stack-depth to report transit switching in MPLS Echo Reply message. | Label-stack-depth to report transit switching in the MPLS echo | |||
reply message. | ||||
2. If the Label-stack-depth is 0 and the Target FEC Stack sub-TLV at | 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 | FEC-stack-depth is Nil FEC, then do a lookup for an exact match | |||
the Egress TLV address field to any of the locally configured | of the Address field of the Egress TLV to any of the locally | |||
interfaces or loopback addresses. | configured interfaces or loopback addresses. | |||
2a. If the Egress TLV address lookup succeeds, set Best-return-code | a. If the Egress TLV address lookup succeeds, set Best-return- | |||
to 36 ("Replying router is an egress for the address in Egress TLV | code to 36 ("Replying router is an egress for the address in | |||
for the FEC at stack depth RSC") (Section 6.2) in MPLS Echo Reply | the Egress TLV for the FEC at stack depth RSC") (Section 6.2) | |||
message. | in the MPLS echo reply message. | |||
2b. If the Egress TLV address lookup fails, set the Best-return-code | b. If the Egress TLV address lookup fails, set the Best-return- | |||
to 10, "Mapping for this FEC is not the given label at stack-depth | code to 10 ("Mapping for this FEC is not the given label at | |||
RSC" | stack-depth RSC"). | |||
3. In cases where multiple Nil FECs are sent from the SR Policy | 3. In cases where multiple Nil FECs are sent from the SR Policy | |||
headend, one each corresponding to the labels in the label stack | headend, one each corresponding to the labels in the label stack | |||
along with Egress TLV, when the packet reaches the egress, the number | along with the Egress TLV, when the packet reaches the egress, | |||
of labels in the received packet (Size of stack-R) becomes zero or a | the number of labels in the received packet (Size of stack-R) | |||
label with Bottom-of-Stack bit set to 1 is processed, all Nil FEC | becomes zero or a label with the Bottom-of-Stack bit set to 1 is | |||
sub-TLVs MUST be removed and the Egress TLV MUST be validated. | processed, all Nil FEC sub-TLVs MUST be removed and the Egress | |||
TLV MUST be validated. | ||||
5. Backward Compatibility | 5. Backward Compatibility | |||
The extensions defined in this document is backward compatible with | The extensions defined in this document are backward compatible with | |||
procedures described in [RFC8029]. A Router that does not support | the procedures described in [RFC8029]. A router that does not | |||
Egress TLV, will ignore it and use current the Nil-FEC procedures | support the Egress TLV will ignore it and use the Nil FEC procedures | |||
described in [RFC8029]. | described in [RFC8029]. | |||
When the egress node in the path does not support the extensions | When the egress node in the path does not support the extensions | |||
defined in this document egress validation will not be done and Best- | defined in this document, egress validation will not be done, and | |||
return-code as 3 ("Replying router is an egress for the FEC at stack- | Best-return-code will be set to 3 ("Replying router is an egress for | |||
depth") and Best-return- subcode set to stack-depth to will be set in | the FEC at stack-depth") and Best-rtn-subcode to stack-depth in the | |||
the MPLS Echo Reply message. | MPLS echo reply message. | |||
When the transit node in the path does not support the extensions | When the transit node in the path does not support the extensions | |||
defined in this document Best-return-code as 8 ("Label switched at | defined in this document, Best-return-code will be set to 8 ("Label | |||
stack-depth") and Best-return-subcode as Label-stack-depth to report | switched at stack-depth") and Best-rtn-subcode to Label-stack-depth | |||
transit switching will be set in the MPLS Echo Reply message. | to report transit switching in the MPLS echo reply message. | |||
6. IANA Considerations | 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 | 6.1. New TLV | |||
[IANA] is requested to update the early allocation for Egress TLV in | IANA has added the following entry to the "TLVs" registry within the | |||
the "Multi-Protocol Label Switching (MPLS) Label Switched Paths | "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) | |||
(LSPs) Ping Parameters" in the "TLVs" sub-registry to reference this | Ping Parameters" registry group [IANA-MPLS-LSP]: | |||
document when published as an RFC. | ||||
+=======+=============+============================+ | +=======+==========+===========+ | |||
| Value | Description | Reference | | | Type | TLV Name | Reference | | |||
+=======+=============+============================+ | +=======+==========+===========+ | |||
| 32771 | Egress TLV | Section 3 of this document | | | 32771 | Egress | RFC 9655 | | |||
+-------+-------------+----------------------------+ | +-------+----------+-----------+ | |||
Table 1: TLVs Sub-Registry | Table 1: TLVs Registry | |||
6.2. New Return code | 6.2. New Return Code | |||
[IANA] is requested to update the early allocation of the Return Code | IANA has added the following entry to the "Return Codes" registry | |||
for "Replying router is an egress for the address in Egress TLV" in | within the "Multiprotocol Label Switching (MPLS) Label Switched Paths | |||
the "Multi-Protocol Label Switching (MPLS) Label Switched Paths | (LSPs) Ping Parameters" registry group [IANA-MPLS-LSP]: | |||
(LSPs) Ping Parameters" in the "Return Codes" sub-registry to | ||||
reference this document when published as an RFC. | ||||
+=======+================================+=============+ | +=======+==================================+===========+ | |||
| Value | Description | Reference | | | Value | Meaning | Reference | | |||
+=======+================================+=============+ | +=======+==================================+===========+ | |||
| 36 | Replying router is an egress | Section 4.2 | | | 36 | Replying router is an egress for | RFC 9655 | | |||
| | for the address in Egress TLV | of this | | | | the address in the Egress TLV | | | |||
| | for the FEC at stack depth RSC | document | | | | for the FEC at stack depth RSC | | | |||
+-------+--------------------------------+-------------+ | +-------+----------------------------------+-----------+ | |||
Table 2: Return code Sub-Registry | Table 2: Return Codes Registry | |||
7. Security Considerations | 7. Security Considerations | |||
This document defines additional MPLS LSP ping TLVs and follows the | This document defines an additional TLV for MPLS LSP ping and | |||
mechanisms defined in [RFC8029]. All the security considerations | conforms to the mechanisms defined in [RFC8029]. All the security | |||
defined in [RFC8287] will be applicable for this document and, in | considerations defined in [RFC8287] are applicable to this document, | |||
addition, they do not impose any additional security challenges to be | and they do not impose any additional security challenges to be | |||
considered. | considered. | |||
8. Implementation Status | 8. References | |||
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 | ||||
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 | ||||
The authors would like to thank Stewart Bryant, Greg Mirsky, | ||||
Alexander Vainshtein, Sanga Mitra Rajgopal, and Adrian Farrel for | ||||
their careful review and comments. | ||||
10. References | ||||
10.1. Normative References | 8.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., | [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., | |||
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label | Aldrin, S., and M. Chen, "Detecting Multiprotocol Label | |||
Switched (MPLS) Data-Plane Failures", RFC 8029, | Switched (MPLS) Data-Plane Failures", RFC 8029, | |||
DOI 10.17487/RFC8029, March 2017, | DOI 10.17487/RFC8029, March 2017, | |||
skipping to change at page 12, line 5 ¶ | skipping to change at line 478 ¶ | |||
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., | |||
Decraene, B., Litkowski, S., and R. Shakir, "Segment | Decraene, B., Litkowski, S., and R. Shakir, "Segment | |||
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, | |||
July 2018, <https://www.rfc-editor.org/info/rfc8402>. | July 2018, <https://www.rfc-editor.org/info/rfc8402>. | |||
[RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad, | [RFC9041] Andersson, L., Chen, M., Pignataro, C., and T. Saad, | |||
"Updating the MPLS Label Switched Paths (LSPs) Ping | "Updating the MPLS Label Switched Paths (LSPs) Ping | |||
Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041, | Parameters IANA Registry", RFC 9041, DOI 10.17487/RFC9041, | |||
July 2021, <https://www.rfc-editor.org/info/rfc9041>. | July 2021, <https://www.rfc-editor.org/info/rfc9041>. | |||
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Bogdanov, A., Mattes, | [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, | |||
P., and D. Voyer, "Segment Routing Policy Architecture", | A., and P. Mattes, "Segment Routing Policy Architecture", | |||
RFC 9256, DOI 10.17487/RFC9256, July 2020, | RFC 9256, DOI 10.17487/RFC9256, July 2022, | |||
<https://www.rfc-editor.org/info/rfc9256>. | <https://www.rfc-editor.org/info/rfc9256>. | |||
10.2. Informative References | 8.2. Informative References | |||
[I.D-ietf-idr-sr-policy-safi] | ||||
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-sr- | ||||
policy-safi-04, work in progress, April 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- | ||||
policy-safi-04>. | ||||
[IANA] IANA, "Multiprotocol Label Switching (MPLS) Label Switched | [IANA-MPLS-LSP] | |||
IANA, "Multiprotocol Label Switching (MPLS) Label Switched | ||||
Paths (LSPs) Ping Parameters", | Paths (LSPs) Ping Parameters", | |||
<http://www.iana.org/assignments/mpls-lsp-ping- | <http://www.iana.org/assignments/mpls-lsp-ping- | |||
parameters>. | parameters>. | |||
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | [SR-POLICY-BGP] | |||
Code: The Implementation Status Section", BCP 205, | Previdi, S., Filsfils, C., Talaulikar, K., Ed., Mattes, | |||
RFC 7942, DOI 10.17487/RFC7942, July 2016, | P., and D. Jain, "Advertising Segment Routing Policies in | |||
<https://www.rfc-editor.org/info/rfc7942>. | BGP", Work in Progress, Internet-Draft, draft-ietf-idr-sr- | |||
policy-safi-06, 26 July 2024, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr- | ||||
policy-safi-06>. | ||||
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 | Authors' Addresses | |||
Deepti N. Rathi (editor) | Deepti N. Rathi (editor) | |||
Nokia | Nokia | |||
Manyata Embassy Business Park | Manyata Embassy Business Park | |||
Bangalore 560045 | Bangalore 560045 | |||
Karnataka | Karnataka | |||
India | India | |||
Email: deepti.nirmalkumarji_rathi@nokia.com | Email: deepti.nirmalkumarji_rathi@nokia.com | |||
Shraddha Hegde (editor) | Shraddha Hegde (editor) | |||
Juniper Networks Inc. | Juniper Networks Inc. | |||
Exora Business Park | Exora Business Park | |||
Bangalore 560103 | Bangalore 560103 | |||
KA | Karnataka | |||
India | India | |||
Email: shraddha@juniper.net | Email: shraddha@juniper.net | |||
Kapil Arora | Kapil Arora | |||
Individual Contributor | Individual Contributor | |||
Email: kapil.it@gmail.com | Email: kapil.it@gmail.com | |||
Zafar Ali | Zafar Ali | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Email: zali@cisco.com | Email: zali@cisco.com | |||
Nagendra Kumar Nainar | Nagendra Kumar Nainar | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Email: naikumar@cisco.com | Email: naikumar@cisco.com | |||
End of changes. 70 change blocks. | ||||
333 lines changed or deleted | 297 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |