diff options
Diffstat (limited to 'doc/rfc/rfc9612.txt')
| -rw-r--r-- | doc/rfc/rfc9612.txt | 470 |
1 files changed, 470 insertions, 0 deletions
diff --git a/doc/rfc/rfc9612.txt b/doc/rfc/rfc9612.txt new file mode 100644 index 0000000..9378c8d --- /dev/null +++ b/doc/rfc/rfc9612.txt @@ -0,0 +1,470 @@ + + + + +Internet Engineering Task Force (IETF) G. Mirsky +Request for Comments: 9612 Ericsson +Category: Experimental J. Tantsura +ISSN: 2070-1721 NVIDIA + I. Varlashkin + Google + M. Chen + Huawei + July 2024 + + + Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label + Switched Paths (LSPs) + +Abstract + + Bidirectional Forwarding Detection (BFD) is expected to be able to + monitor a wide variety of encapsulations of paths between systems. + When a BFD session monitors an explicitly routed unidirectional path, + there may be a need to direct the egress BFD peer to use a specific + path for the reverse direction of the BFD session. This document + describes an extension to the MPLS Label Switched Path (LSP) echo + request that allows a BFD system to request that the remote BFD peer + transmit BFD control packets over the specified LSP. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are candidates for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9612. + +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 + 1.1. Conventions Used in This document + 1.1.1. Terminology + 1.1.2. Requirements Language + 2. Problem Statement + 3. Control of the BFD Reverse Path + 3.1. BFD Reverse Path TLV + 3.2. Return Codes + 3.3. Failure Characterization + 4. Use Case Scenario + 5. Operational Considerations + 6. IANA Considerations + 6.1. BFD Reverse Path TLV + 6.2. Return Codes + 7. Security Considerations + 8. Normative References + Acknowledgments + Authors' Addresses + +1. Introduction + + [RFC5880], [RFC5881], and [RFC5883] established the Bidirectional + Forwarding Detection (BFD) protocol for IP networks. [RFC5884] and + [RFC7726] set rules for using BFD Asynchronous mode over MPLS Label + Switched Paths (LSPs), while not defining means to control the path + that an egress BFD system uses to send BFD control packets towards + the ingress BFD system. + + When BFD is used to detect defects of the traffic-engineered LSP, the + path of the BFD control packets transmitted by the egress BFD system + toward the ingress may be disjoint from the monitored LSP in the + forward direction. The fact that BFD control packets are not + guaranteed to follow the same links and nodes in both forward and + reverse directions may be one of the factors contributing to false + positive defect notifications (i.e., false alarms) at the ingress BFD + peer. Ensuring that both directions of the BFD session use co-routed + paths may, in some environments, improve the determinism of the + failure detection and localization. + + This document defines the BFD Reverse Path TLV as an extension to LSP + ping [RFC8029] and proposes that it be used to instruct the egress + BFD system to use an explicit path for its BFD control packets + associated with a particular BFD session. IANA has registered this + TLV in the "TLVs" registry defined by [RFC8029] (see Section 6.1). + As a special case, forward and reverse directions of the BFD session + can form a bidirectional co-routed associated channel. + + The LSP ping extension described in this document was developed and + implemented as a result of an operational experiment. The lessons + learned from the operational experiment enabled the use of this + extension between systems conforming to this specification. Further + implementation is encouraged to better understand the operational + impact of the mechanism described in the document. + +1.1. Conventions Used in This document + +1.1.1. Terminology + + BFD: Bidirectional Forwarding Detection + + FEC: Forwarding Equivalence Class + + LSP: Label Switched Path + + LSR: Label Switching Router + +1.1.2. 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 Statement + + When BFD is used to monitor an explicitly routed unidirectional path + (e.g., MPLS-TE LSP), BFD control packets in the forward direction + would be in-band using the mechanism defined in [RFC5884]. However, + the reverse direction of the BFD session would follow the shortest + path route, which could be completely or partially disjoint from the + forward path. This creates the potential for the failure of a + disjoint resource on the reverse path to trigger a BFD failure + detection, even though the forward path is unaffected. + + If the reverse path is congruent with the forward path, the potential + for such false positives is greatly reduced. For this purpose, this + specification provides a means for the egress BFD peer to be + instructed to use a specific path for BFD control packets. + +3. Control of the BFD Reverse Path + + To bootstrap a BFD session over an MPLS LSP, LSP ping [RFC8029] MUST + be used with the BFD Discriminator TLV [RFC5884]. This document + defines a new TLV, the BFD Reverse Path TLV, that can be used to + carry information about the reverse path for the BFD session that is + specified by the value in the BFD Discriminator TLV. The BFD Reverse + Path TLV MAY contain zero or more sub-TLVs. + +3.1. BFD Reverse Path TLV + + The BFD Reverse Path TLV is an optional TLV within the LSP ping + [RFC8029]. However, if used, the BFD Discriminator TLV MUST be + included in an echo request message as well. If the BFD + Discriminator TLV is not present when the BFD Reverse Path TLV is + included, then it MUST be treated as a malformed echo request, as + described in [RFC8029]. + + The BFD Reverse Path TLV carries information about the path onto + which the egress BFD peer of the BFD session referenced by the BFD + Discriminator TLV MUST transmit BFD control packets. The format of + the BFD Reverse Path TLV is presented in Figure 1. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BFD Reverse Path TLV Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reverse Path | + ~ ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: BFD Reverse Path TLV + + BFD Reverse Path TLV Type: + This two-octet field has a value of 16384 (see Section 6). + + Length: + This two-octet field defines the length in octets of the Reverse + Path field. + + Reverse Path: + This field contains zero or more sub-TLVs. Only non-multicast + Target FEC Stack sub-TLVs (already defined or to be defined in the + future) for TLV Types 1, 16, and 21 in the "Multiprotocol Label + Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" + registry are permitted to be used in this field. Other sub-TLVs + MUST NOT be used. (This implies that multicast Target FEC Stack + sub-TLVs, e.g., the Multicast P2MP LDP FEC Stack sub-TLV and the + Multicast MP2MP LDP FEC Stack sub-TLV, are not permitted in the + Reverse Path field.) + + If the egress LSR finds a multicast Target FEC Stack sub-TLV, it MUST + send an echo reply with the received BFD Reverse Path TLV and BFD + Discriminator TLV and set the Return Code to 192 ("Inappropriate + Target FEC Stack sub-TLV present") (see Section 3.2). The BFD + Reverse Path TLV includes zero or more sub-TLVs. However, the number + of sub-TLVs in the Reverse Path field MUST be limited. The default + limit is 128 sub-TLV entries, but an implementation MAY be able to + control that limit. An empty BFD Reverse Path TLV (i.e., a BFD + Reverse Path TLV with no sub-TLVs) is used to withdraw any previously + set reverse path for the BFD session identified in the BFD + Discriminator TLV. If no sub-TLVs are found in the BFD Reverse Path + TLV, the egress BFD peer MUST revert to using the decision based on + local policy, i.e., routing over an IP network, as described in + Section 7 of [RFC5884]. + + If the egress peer LSR cannot find the path specified in the BFD + Reverse Path TLV, it MUST send an echo reply with the received BFD + Discriminator TLV and BFD Reverse Path TLV and set the Return Code to + 193 ("Failed to establish the BFD session. The specified reverse + path was not found.") (see Section 3.2). If an implementation + provides additional configuration options, these can control actions + at the egress BFD peer, including when the path specified in the BFD + Reverse Path TLV cannot be found. For example, if the egress peer + LSR cannot find the path specified in the BFD Reverse Path TLV, it + MAY establish the BFD session over an IP network, as defined in + [RFC5884]. Note that the Return Code required by the "MUST" clause + in this paragraph does not preclude the session from being + established over a different path as discussed in the "MAY" clause. + + The BFD Reverse Path TLV MAY be used in the process of bootstrapping + the BFD session as described in Section 6 of [RFC5884]. A system + that supports this specification MUST support using the BFD Reverse + Path TLV after the BFD session has been established. If a system + that supports this specification receives an LSP ping with the BFD + Discriminator TLV and no BFD Reverse Path TLV even though the reverse + path for the specified BFD session was established according to the + previously received BFD Reverse Path TLV, the egress BFD peer MUST + transition to transmitting periodic BFD Control messages as described + in Section 7 of [RFC5884]. If a BFD system that received an LSP ping + with the BFD Reverse Path TLV does not support this specification, it + will result in an echo response with the Return Code set to 2 ("One + or more of the TLVs was not understood"), as described in Section 3 + of [RFC8029]. + +3.2. Return Codes + + This document defines the following Return Codes for the MPLS LSP + echo reply: + + "Inappropriate Target FEC Stack sub-TLV present" (192): + When a multicast Target FEC Stack sub-TLV is found in the received + echo request, the egress BFD peer sends an echo reply with the + Return Code set to 192 ("Inappropriate Target FEC Stack sub-TLV + present") to the ingress BFD peer, as described in Section 3.1. + + "Failed to establish the BFD session. The specified reverse path + was not found." (193): + When a specified reverse path is unavailable, the egress BFD peer + sends an echo reply with the Return Code set to 193 ("Failed to + establish the BFD session. The specified reverse path was not + found.") to the ingress BFD peer, as described in Section 3.1. + +3.3. Failure Characterization + + A failure detected by a BFD session that uses the BFD Reverse Path + TLV could be due to a change in the FEC used in the BFD Reverse Path + TLV. Upon detection of the network failure, the ingress BFD peer + MUST transmit the LSP ping echo request with the Reply Path TLV + [RFC7110] to verify whether the FEC is still valid. If the failure + was caused by a change in the FEC used for the reverse direction of + the BFD session, the ingress BFD peer MUST redirect the reverse path + of the BFD session using another FEC in the BFD Reverse Path TLV and + notify an operator. + +4. Use Case Scenario + + In the network presented in Figure 2, ingress LSR peer A monitors two + tunnels to egress LSR peer H: A-B-C-D-G-H and A-B-E-F-G-H. To + bootstrap a BFD session to monitor the first tunnel, ingress LSR peer + A includes a BFD Discriminator TLV with a Discriminator value (e.g., + foobar-1) [RFC7726]. Ingress LSR peer A includes a BFD Reverse Path + TLV referencing the H-G-D-C-B-A tunnel to control the path from the + egress LSR. To bootstrap a BFD session to monitor the second tunnel, + ingress LSR peer A includes a BFD Discriminator TLV with a different + Discriminator value (e.g., foobar-2) and a BFD Reverse Path TLV that + references the H-G-F-E-B-A tunnel. + + C---------D + | | + A-------B G-----H + | | + E---------F + + Figure 2: Use Case for BFD Reverse Path TLV + + If an operator needs egress LSR peer H to monitor a path to ingress + LSR peer A, e.g., the H-G-D-C-B-A tunnel, then by looking up the list + of known reverse paths, it MAY find and use the existing BFD session. + +5. Operational Considerations + + When an explicit path is set as either Static or RSVP-TE LSP, + corresponding sub-TLVs (defined in [RFC7110]) MAY be used to identify + the explicit reverse path for the BFD session. If a particular set + of sub-TLVs composes the Reply Path TLV [RFC7110] and does not + increase the length of the Maximum Transmission Unit for the given + LSP, that set can be safely used in the BFD Reverse Path TLV. If any + of the sub-TLVs defined in [RFC7110] are used in the BFD Reverse Path + TLV, then the periodic verification of the control plane against the + data plane, as recommended in Section 4 of [RFC5884], MUST use the + Reply Path TLV, as per [RFC7110], with that sub-TLV. By using the + LSP ping with the Reply Path TLV, an operator monitors whether the + reverse LSP is mapped to the same FEC as the BFD session at the + egress BFD node. Selection and control of the rate of the LSP ping + with the Reply Path TLV follows the recommendation in [RFC5884]: + + | The rate of generation of these LSP Ping Echo request messages + | SHOULD be significantly less than the rate of generation of the + | BFD Control packets. An implementation MAY provide configuration + | options to control the rate of generation of the periodic LSP Ping + | Echo request messages. + + Suppose an operator planned a network maintenance activity that + possibly affects the FEC used in the BFD Reverse Path TLV. In that + case, the operator can avoid unnecessary disruption by using the LSP + ping with a new FEC in the BFD Reverse Path TLV. But in some + scenarios, proactive measures cannot be taken because the frequency + of LSP ping messages is lower than the defect detection time provided + by the BFD session. As a result, a change in the reverse-path FEC + will first be detected as the BFD session's failure. An operator + will be notified as described in Section 3.3. + +6. IANA Considerations + +6.1. BFD Reverse Path TLV + + IANA has assigned the following value for the BFD Reverse Path TLV + from the 16384-31739 range in the "TLVs" subregistry within the + "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) + Ping Parameters" registry. + + +=======+=========+===========+====================================+ + | Type | TLV | Reference | Sub-TLV Registry | + | | Name | | | + +=======+=========+===========+====================================+ + | 16384 | BFD | RFC 9612 | Only non-multicast sub-TLVs | + | | Reverse | | (already defined or to be defined | + | | Path | | in the future) in the "Sub-TLVs | + | | | | for TLV Types 1, 16, and 21" | + | | | | registry at | + | | | | <https://www.iana.org/assignments/ | + | | | | mpls-lsp-ping-parameters/mpls-lsp- | + | | | | ping-parameters.xml#sub-tlv- | + | | | | 1-16-21> are permitted to be used | + | | | | in this field. Other sub-TLVs | + | | | | MUST NOT be used. | + +-------+---------+-----------+------------------------------------+ + + Table 1: New BFD Reverse Path TLV + +6.2. Return Codes + + IANA has assigned the following Return Code values from the 192-247 + range in the "Return Codes" subregistry within the "Multiprotocol + Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" + registry. + + +=======+===========================================+===========+ + | Value | Meaning | Reference | + +=======+===========================================+===========+ + | 192 | Inappropriate Target FEC Stack sub-TLV | RFC 9612 | + | | present | | + +-------+-------------------------------------------+-----------+ + | 193 | Failed to establish the BFD session. The | RFC 9612 | + | | specified reverse path was not found. | | + +-------+-------------------------------------------+-----------+ + + Table 2: New Return Codes + +7. Security Considerations + + Security considerations discussed in [RFC5880], [RFC5884], [RFC7726], + [RFC8029], and [RFC7110] apply to this document. + + The BFD Reverse Path TLV may be exploited as an attack vector by + inflating the number of included sub-TLVs. The number of sub-TLVs + MUST be limited to mitigate that threat. The default limit for the + number of sub-TLVs is set to 128 (see Section 3.1). An + implementation MAY use a mechanism to control that limit. + +8. 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>. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, + <https://www.rfc-editor.org/info/rfc5880>. + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, + DOI 10.17487/RFC5881, June 2010, + <https://www.rfc-editor.org/info/rfc5881>. + + [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, + June 2010, <https://www.rfc-editor.org/info/rfc5883>. + + [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, + "Bidirectional Forwarding Detection (BFD) for MPLS Label + Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, + June 2010, <https://www.rfc-editor.org/info/rfc5884>. + + [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, + "Return Path Specified Label Switched Path (LSP) Ping", + RFC 7110, DOI 10.17487/RFC7110, January 2014, + <https://www.rfc-editor.org/info/rfc7110>. + + [RFC7726] Govindan, V., Rajaraman, K., Mirsky, G., Akiya, N., and S. + Aldrin, "Clarifying Procedures for Establishing BFD + Sessions for MPLS Label Switched Paths (LSPs)", RFC 7726, + DOI 10.17487/RFC7726, January 2016, + <https://www.rfc-editor.org/info/rfc7726>. + + [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>. + +Acknowledgments + + The authors greatly appreciate the thorough reviews and helpful + comments from Eric Gray and Carlos Pignataro. The authors much + appreciate the help of Qian Xin, who provided information about the + implementation of this specification. + +Authors' Addresses + + Greg Mirsky + Ericsson + Email: gregimirsky@gmail.com + + + Jeff Tantsura + NVIDIA + Email: jefftant.ietf@gmail.com + + + Ilya Varlashkin + Google + Email: imv@google.com + + + Mach(Guoyi) Chen + Huawei + Email: mach.chen@huawei.com |