RFC 9612

Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)

📅 published July 2024, from ietf

RFC 9612 💖 Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)

Okay bestie, the title block is giving main character energy 🎀. This is RFC 9612, published in July 2024 under the Experimental category (ISSN 2070-1721). The authors are G. Mirsky (Ericsson), J. Tantsura (NVIDIA), I. Varlashkin (Google), and M. Chen (Huawei). It doesn't list anything it obsoletes or updates, so it's standing on its own ✨.

Abstract ✨

Bidirectional Forwarding Detection (BFD) is expected to be able to watch a wide variety of encapsulations of paths between systems 🦋. When a BFD session is monitoring an explicitly routed unidirectional path, sometimes you need to tell the egress BFD peer to take a specific path for the reverse direction of that session 💅. This doc extends the MPLS Label Switched Path (LSP) echo request so a BFD system can ask the remote BFD peer to send its BFD control packets over the specified LSP 🌸.

Status of This Memo

Okay so this is not an Internet Standards Track spec 🧚. It's published for examination, experimental implementation, and evaluation 🔬.

It does define an Experimental Protocol for the Internet community 💜. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.

For the latest status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9612 🍓.

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. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come 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 ✨

Okay, so [RFC5880], [RFC5881], and [RFC5883] are the ones that set up the Bidirectional Forwarding Detection (BFD) protocol for IP networks 💖. Then [RFC5884] and [RFC7726] came in with the rules for running BFD Asynchronous mode over MPLS Label Switched Paths (LSPs) 🦋. What they didn't do is give you a way to control which path an egress BFD system uses to send BFD control packets back toward the ingress BFD system 👀.

Here's the tea 🍵: when BFD is detecting defects on a traffic-engineered LSP, the path the egress BFD system uses for its control packets going back to the ingress can be totally disjoint from the monitored LSP in the forward direction. BFD control packets aren't guaranteed to take the same links and nodes in both directions, and that can be one reason you get false positive defect notifications (aka false alarms) at the ingress BFD peer 😭. In some environments, making sure both directions of the BFD session use co-routed paths can make failure detection and localization more deterministic 💅.

This document defines the BFD Reverse Path TLV as an extension to LSP ping [RFC8029], and it proposes using that TLV to tell the egress BFD system to use an explicit path for the BFD control packets of a particular BFD session 🎀. IANA has registered this TLV in the "TLVs" registry defined by [RFC8029] (see Section 6.1) 🌈. As a special case, the forward and reverse directions of the BFD session can form a bidirectional co-routed associated channel ✨.

The LSP ping extension in this doc was developed and implemented as a result of an operational experiment 🧪. The lessons from that experiment made it possible for systems conforming to this spec to use this extension. More implementation is encouraged so people can better understand the operational impact of the mechanism 🫶.

1.1. Conventions Used in This document 🌸

1.1.1. Terminology

Here are the abbreviations you'll see:

  • 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 💅

So when BFD is monitoring an explicitly routed unidirectional path (e.g., MPLS-TE LSP), the BFD control packets in the forward direction are in-band, using the mechanism from [RFC5884] 🦋. The problem is the reverse direction of that BFD session takes the shortest path route, and that route could be completely or partially disjoint from the forward path 😬. That means a failure on some disjoint resource on the reverse path can trigger a BFD failure detection, even though the forward path is totally fine 💀.

If the reverse path is congruent with the forward path, the chance of those false positives drops a lot 🫶. So this spec gives the egress BFD peer a way to be told which specific path to use for its BFD control packets ✨.

3. Control of the BFD Reverse Path 👑

Okay, bootstrapping a BFD session over an MPLS LSP is a whole thing 🧚. LSP ping [RFC8029] MUST be used with the BFD Discriminator TLV [RFC5884] to get it going 💖.

This document defines a new TLV, the BFD Reverse Path TLV, that carries info about the reverse path for the BFD session identified 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 ✨

okay so the BFD Reverse Path TLV is optional 🎀 it's a TLV that lives inside the LSP ping [RFC8029], and it's giving very "add-on" energy. BUT the moment you do include it, the BFD Discriminator TLV MUST also be in that echo request, no cap 💅. If the Discriminator TLV isn't there when the Reverse Path TLV shows up, then the echo request MUST be treated as malformed, same as described in [RFC8029] 🙈

the Reverse Path TLV tells the egress BFD peer which path it MUST use to send its BFD control packets for the session referenced by the Discriminator TLV 🦋 the layout is in Figure 1, bestie:

 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 is 16384 (see Section 6) 🌸

Length: two octets that tell you how many octets long the Reverse Path field is 🍓

Reverse Path: this field holds zero or more sub-TLVs 🧚 only non-multicast Target FEC Stack sub-TLVs are allowed here, whether they're already defined or defined later, and only the ones for TLV Types 1, 16, and 21 in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" registry 💜 anything else MUST NOT be used. (So yeah, multicast ones like the Multicast P2MP LDP FEC Stack sub-TLV and the Multicast MP2MP LDP FEC Stack sub-TLV are a no-go in the Reverse Path field 🙅‍♀️)

if the egress LSR spots a multicast Target FEC Stack sub-TLV, it MUST send back an echo reply that includes the received BFD Reverse Path TLV and BFD Discriminator TLV, with the Return Code set to 192 ("Inappropriate Target FEC Stack sub-TLV present") (see Section 3.2) 💀

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 (no sub-TLVs at all) is how you withdraw a reverse path you set earlier for the BFD session identified in the Discriminator TLV 🦋 and if there are no sub-TLVs in the Reverse Path TLV, the egress BFD peer MUST go back to its local policy decision, i.e., routing over an IP network, as described in Section 7 of [RFC5884] 🌈

if the egress peer LSR can't find the path given in the BFD Reverse Path TLV, it MUST send an echo reply with the received BFD Discriminator TLV and BFD Reverse Path TLV, and the Return Code set to 193 ("Failed to establish the BFD session. The specified reverse path was not found.") (see Section 3.2) 😭 if an implementation has extra configuration options, those can control what the egress BFD peer does, including when that path can't be found ✨ for example, if the egress peer LSR can't find the path, it MAY establish the BFD session over an IP network, as defined in [RFC5884] 🧚 and yes, the Return Code the MUST clause requires doesn't stop the session from being established over a different path, as the MAY clause talks about 🫶

the BFD Reverse Path TLV MAY be used when 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 ✨ and if a system that supports this spec gets an LSP ping with the BFD Discriminator TLV and no BFD Reverse Path TLV, even though the reverse path for that session was set up from a previously received BFD Reverse Path TLV, the egress BFD peer MUST switch to sending periodic BFD Control messages as described in Section 7 of [RFC5884] 🔥 the tricky part: if a BFD system that got an LSP ping with the BFD Reverse Path TLV doesn't support this spec, it will reply with an echo response whose Return Code is 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 caused by a change in the FEC used in that TLV 👀 when the network failure is detected, the ingress BFD peer MUST send the LSP ping echo request with the Reply Path TLV [RFC7110] to check 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 in Figure 2, ingress LSR peer A is watching 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 that monitors 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 also includes a BFD Reverse Path TLV referencing the H-G-D-C-B-A tunnel, to control the path from the egress LSR 💜 for 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 through the list of known reverse paths, it MAY find and use the existing BFD session 🦋

5. Operational Considerations 💅

when an explicit path is set up as either Static or RSVP-TE LSP, the 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 makes up the Reply Path TLV [RFC7110] and doesn't 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 🫶 with the LSP ping and the Reply Path TLV, an operator can check whether the reverse LSP is mapped to the same FEC as the BFD session at the egress BFD node 🔍 the rate of that LSP ping 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.

say an operator planned network maintenance that might affect 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 can't be taken, because the frequency of LSP ping messages is lower than the defect detection time provided by the BFD session 😬 so a change in the reverse-path FEC will first show up 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 🔒

okay bestie, security time 😭 the security considerations from [RFC5880], [RFC5884], [RFC7726], [RFC8029], and [RFC7110] all still apply to this doc 🫶 no escaping them.

The BFD Reverse Path TLV can get abused as an attack vector if someone just keeps stuffing in more and more sub-TLVs 💀 so the number of sub-TLVs MUST be limited to mitigate that threat. The default limit is set to 128 (see Section 3.1) 🍓, and an implementation MAY use a mechanism to control that limit ✨.

8. Normative References 📚

these are the references the spec leans on so hard, and every single one is listed here with all its details 💅

Acknowledgments 💜

the authors are so grateful to Eric Gray and Carlos Pignataro for their thorough reviews and super helpful comments 🙌 they also really appreciate Qian Xin, who shared info about how this spec gets implemented 🫶

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

that's the whole RFC, bestie 🎀✨

📦 where this page comes from