RFC 7130

Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces

📅 published February 2014, from ietf

okay bestie, RFC 7130 is about running BFD on LAG interfaces and I am so obsessed 😭💖

RFC 7130: Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces 🎀

  • Authors: M. Bhatia, Ed. (Alcatel-Lucent), M. Chen, Ed. (Huawei Technologies), S. Boutros, Ed., M. Binderberger, Ed. (Cisco Systems), J. Haas, Ed. (Juniper Networks) 🧑‍💻
  • Category: Standards Track 🔥
  • ISSN: 2070-1721
  • Date: February 2014 📅
  • Obsoletes / Updates: nothing is listed in the title block, so it doesn't obsolete or update anything 🙅

Abstract 💖

Okay so this doc defines a mechanism for running Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) interfaces. The move is to run an independent Asynchronous mode BFD session on every single LAG member link 🧚

This lets you verify member link continuity, either together with the Link Aggregation Control Protocol (LACP) or without it. It's also faster at detection than LACP. The continuity check can even cover parts of Layer 3 (L3) bidirectional forwarding. It's giving main character energy ✨

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

For info about the current status of this document, any errata, and how to give feedback on it, check http://www.rfc-editor.org/info/rfc7130 🔗

Copyright (c) 2014 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 (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📜

Table of Contents 🧾

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
2.  BFD on LAG Member Links . . . . . . . . . . . . . . . . . . .   3
  2.1.  Micro-BFD Session Address Family  . . . . . . . . . . . .   4
  2.2.  Micro-BFD Session Negotiation . . . . . . . . . . . . . .   4
  2.3.  Micro-BFD Session Ethernet Details  . . . . . . . . . . .   5
3.  Interaction between LAG and BFD . . . . . . . . . . . . . . .   6
4.  BFD on LAG Member Links and L3 Applications . . . . . . . . .   6
5.  Detecting a Member Link Failure . . . . . . . . . . . . . . .   6
6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  10.1.  Normative References . . . . . . . . . . . . . . . . . .   9
  10.2.  Informative References . . . . . . . . . . . . . . . . .   9
Appendix A.  Considerations When Using BFD on Member Links  . . .  10

1. Introduction ✨

Okay so BFD [RFC5880] is the protocol that detects faults in the bidirectional path between two forwarding engines. That covers interfaces, data links, and, as far as possible, the forwarding engines themselves, and it can do this with potentially very low latency. It's also a fast way to catch communication failures on any data link. It can run over any media and at any protocol layer 🚀

LAG, defined in [IEEE802.1AX], combines multiple physical links into one logical link. That gives you more bandwidth and better resiliency, since if one physical member link dies, the aggregate logical link can keep forwarding traffic over the remaining working physical member links 💪

Right now LACP is used to detect failures on each physical member link. But using BFD for failure detection would (1) detect things faster, (2) work even without LACP, and (3) be able to verify that each member link can actually forward L3 packets. Iconic behaviour 👑

Running one single BFD session over the aggregation, without knowing anything about the member links, would make it impossible for BFD to guarantee detection of physical member link failures. Nope, not doing that 🙅‍♀️

The goal is to verify link continuity for every member link. This lines up with [RFC5882], Section 7.3 🎯

So the approach here is to run an Asynchronous mode BFD session over each LAG member link, and let BFD control whether the LAG member link should be part of the L2 load-balancing table of the LAG interface, with or without LACP. 🧠

This document describes how to set up an Asynchronous mode BFD session per physical LAG member link of the LAG interface 🛠️

Yes, Ethernet has native mechanisms to detect failures (802.1ax, .3ah) that could be used for LAG. But the solution in this document lets operators who already deployed BFD over other technologies (e.g., IP, MPLS) use one common failure detection mechanism. Efficiency queen 🐝

1.1. Requirements Language 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

The mechanism defined for fast detection of LAG member link failure is to run Asynchronous mode BFD sessions on every LAG member link. For the rest of this document, we call these per-LAG-member-link BFD sessions "micro-BFD sessions" 💅

2.1. Micro-BFD Session Address Family 🧚

Micro-BFD sessions on member links can use IPv4 or IPv6 addresses when they use IP/UDP encapsulation. Two micro-BFD sessions MAY exist per member link: one IPv4 and another IPv6. Once an address family is used on one member link, it MUST be used on all member links of that particular LAG 🫶

2.2. Micro-BFD Session Negotiation 💅

Each member link of the LAG runs a single micro-BFD session for every enabled address family. The negotiation of a micro-BFD session MUST follow the same procedures defined in [RFC5880] and [RFC5881] 🤝

Only Asynchronous mode BFD is covered in this document. The BFD echo function is out of scope here 🙈 At least one system MUST take the Active role (possibly both). The micro-BFD sessions on the member links are independent BFD sessions. They each use their own unique local discriminator values, keep their own set of state variables, and have their own independent state machines. Timer values MAY be different, even among the micro-BFD sessions in the same aggregation, although it's expected that micro-BFD sessions in the same aggregation will use the same timer values 🕰️

A received BFD packet is demultiplexed solely based on the Your Discriminator field, if that field is nonzero. For the initial Down BFD packets of a BFD session, this value MAY be zero. In that case, demultiplexing MUST be based on some combination of other fields, and those MUST include the interface information of the member link and the destination UDP port of the received BFD packet 🔍

For per-LAG-member-link micro-BFD sessions, the procedure for receiving BFD control packets in Section 6.8.6 of [RFC5880] is amended as follows:

If the Your Discriminator field is nonzero and a micro-BFD over a LAG session is found, the interface on which the micro-BFD control packet arrived MUST correspond to the interface associated with that session.

This document defines the BFD control packets for each micro-BFD session to be IP/UDP encapsulated as defined in [RFC5881], but with a new UDP destination port 6784 🎀

That new UDP port removes the ambiguity between BFD over LAG packets and BFD over single-hop IP. For example, if you (mis-)configure a LAG with micro-BFD sessions on one side but use a [RFC5881] BFD session for the LAG (treated as a single interface) on the other side, things get messy. Nobody wants that 😬

The procedures in this document MUST be used for BFD messages addressed to port 6784, and they MUST NOT be used for other ports assigned in RFCs describing other BFD modes 🚫

Control packets use a destination IP address that is configured on the peer system and can be reached via the LAG interface.

Implementations can do anything from explicitly configuring IP addresses for the BFD sessions to using out-of-band methods for learning the destination IP address. The details are outside the scope of this document 🗺️

2.3. Micro-BFD Session Ethernet Details 🫶

On Ethernet-based LAG member links, the destination Media Access Control (MAC) address is the dedicated multicast MAC address 01-00-5E-90-00-01, which acts as the immediate next hop. This dedicated MAC address MUST be used for the initial BFD packets of a micro-BFD session when it's in the Down/AdminDown and Init states. When a micro-BFD session is changing into the Up state, the first bfd.DetectMult packets in the Up state MUST be sent with the dedicated MAC. For BFD packets in the Up state after those first bfd.DetectMult packets, the source MAC address from the received BFD packets for the session MAY be used instead of the dedicated MAC 💜

All implementations MUST be able to send and receive BFD packets in the Up state using the dedicated MAC address. Implementations that support both sending BFD Up packets with the dedicated MAC and with the received MAC need to offer a way to control that behaviour 🎛️

On Ethernet-based LAG member links, the source MAC SHOULD be the MAC address of the member link transmitting the packet. 🌈

This mechanism helps reduce the use of additional MAC addresses, which in turn cuts down the resources the Ethernet hardware needs on the receiving member link 🧠

Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, the micro-BFD packets may either be untagged or be sent with a vlan tag of Zero (802.1p priority tagged). Implementations compliant with this standard MUST be able to receive both untagged and 802.1p priority tagged micro-BFD packets 💖

3. Interaction between LAG and BFD ✨

okay so this section is literally about who gets to carry traffic 🎀 the micro-BFD sessions for a particular LAG member link MUST be requested when the member link state is either Distributing or Standby 💖 and they MUST be deleted when the member link is in neither Distributing nor Standby state anymore 🧚

bestie, this is the big one 💅 even when LACP is used and says "yep, this link is ready to forward traffic" 🦋, the member link MUST NOT be used by the load balancer until all the micro-BFD sessions of that particular member link are in Up state 🔥 no shortcuts, periodt 💀

now, if an implementation has separate load-balancing tables for IPv4 and IPv6 🌈 and both an IPv4 and IPv6 micro-BFD session exist for a member link, then an implementation MAY enable the member link in the load-balancing algorithm based on the BFD session with a matching address family alone 🍓 it's giving flexible, iykyk

and then there's the exception 🙈 the BFD packet itself is allowed to slip through. implementations MAY receive and transmit BFD packets via the Aggregator's MAC service interface, independent of the session state ✨ so the BFD packets can keep flowing no matter what state the session is in 💜

so the mechanism in this document is likely to be used by modules that manage Interfaces or LAGs, which means they're the ones managing the member links of a LAG 👑 typical L3 protocols like OSPF don't have an insight into the LAG 🙈 they just treat it as one bigger interface, and that's giving main character energy for the LAG itself 💅

the signaling from micro sessions up to L3 protocols happens sideways 🦋 through the impact micro-BFD sessions have on the load-balancing table, plus the Interface/LAG managing module's potential decision to shut down the LAG 🔥 an active way to test that impact is for L3 protocols to request a single BFD session per LAG 🫶

when a micro-BFD session goes down, this member link MUST be taken out of the LAG load-balancing table(s) 🚫 no exceptions, bestie 😭

if an implementation has separate load-balancing tables for IPv4 and IPv6, and both an IPv4 and IPv6 micro-BFD session exist for a member link, an implementation MAY remove the member link only from the load-balancing table that matches the address family of the failing BFD session 🌈 for example, if the IPv4 micro-BFD session fails but the IPv6 one stays Up, then the member link MAY be removed from only the IPv4 load-balance table, and the link MAY remain in the IPv6 load-balancing table ✨ alternatively, the member link may be removed from both the IPv4 and IPv6 load-balancing tables 💜 this decision is an implementation detail, so you get to choose 🧚

6. Security Considerations 🔐

okay this part is SERIOUS 😭 this document does not introduce any additional security issues 🫶 and the security mechanisms defined in [RFC5880] apply in this document 🛡️ go read those, no cap 💖

7. IANA Considerations 🎀

IANA assigned a dedicated MAC address 01-00-5E-90-00-01 (see [RFC7042]) as well as UDP port 6784 for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces 🦋 IANA has changed the reference to [RFC7130] 💅

IANA has also changed the registry for port 6784 to show the Assignee as [IESG] and the Contact as [BFD_Chairs] 👑 the expansion of [BFD_Chairs] is shown as mailto:bfd-chairs@tools.ietf.org 📬 and yep, IANA changed the reference to [RFC7130] again 🌸

8. Acknowledgements 🫶

we would like to thank Dave Katz, Alexander Vainshtein, Greg Mirsky, and Jeff Tantsura for their comments 💖

the initial event that started this discussion was the distribution of "Bidirectional Forwarding Detection (BFD) for Interface" (July 2011) ✨ wild that it all started there 🌈

9. Contributors 💜

  • Paul Hitchen, BT, EMail: paul.hitchen@bt.com 🦋
  • George Swallow, Cisco Systems, EMail: swallow@cisco.com 🌸
  • Wim Henderickx, Alcatel-Lucent, EMail: wim.henderickx@alcatel-lucent.com ✨
  • Nobo Akiya, Cisco Systems, EMail: nobo@cisco.com 💅
  • Neil Ketley, Cisco Systems, EMail: nketley@cisco.com 🍓
  • Carlos Pignataro, Cisco Systems, EMail: cpignata@cisco.com 🧚
  • Nitin Bahadur, Bracket Computing, EMail: nitin@brkt.com 🎀
  • Zuliang Wang, Huawei Technologies, EMail: liang_tsing@huawei.com 👑
  • Liang Guo, China Telecom, EMail: guoliang@gsta.com 🌈
  • Jeff Tantsura, Ericsson, EMail: jeff.tantsura@ericsson.com 💖

10. References 📚

10.1. Normative References 🔒

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD)", RFC 5880, June 2010.

[RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
           (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
           2010.

[RFC5882]  Katz, D. and D. Ward, "Generic Application of
           Bidirectional Forwarding Detection (BFD)", RFC 5882, June
           2010.

10.2. Informative References 🔍

[IEEE802.1AX]
           IEEE Std. 802.1AX, "IEEE Standard for Local and
           metropolitan area networks - Link Aggregation", November
           2008.

[RFC7042]  Eastlake, D. and J. Abley, "IANA Considerations and IETF
           Protocol and Documentation Usage for IEEE 802 Parameters",
           BCP 141, RFC 7042, October 2013.

if the BFD-over-LAG feature were provisioned on an aggregated link member after the link was already active within a LAG, BFD session state should not influence the load-balancing algorithm until the BFD session state transitions to Up 🦋 if the BFD session never transitions to Up but the LAG becomes inactive, the previously documented procedures would then normally apply 💜

this procedure ensures that the sequence of events (enabling the LAG and enabling BFD on the LAG) has no impact on the forwarding service ✨ how clean is that 😭

if the BFD-over-LAG feature were deprovisioned on an aggregate link member while the associated micro-BFD session was in Up state, BFD should transition its state to AdminDown and should attempt to communicate this state change to the peer 🌸

if the local or the remote state of a micro-BFD session is AdminDown, the system should not indicate a connectivity failure to any client and should not remove the particular LAG member link from forwarding 🫶 this behaviour is independent from the use of Link Aggregation Control Protocol (LACP) for the LAG 💅

when traffic is forwarded across a link while the corresponding micro-BFD session is not in Up state, an implementation may use a configurable timeout value after which the BFD session must have reached Up state, otherwise the link is taken out of forwarding ⏱️ when such timeout values exist, the configuration must allow the ability to turn off the timeout function 🧚

the configurable timeout value shall ensure that a LAG does not remain forever in an "inconsistent" state, where forwarding occurs on a link with no confirmation from the micro-BFD session that the link is healthy 🔥

note that if one device is not operating a micro-BFD session on a link, while the other device is and perceives the session to be Down, this will result in the two devices having a different view of the status of the link 😬 this would likely lead to traffic loss across the LAG 💔 the use of another protocol to bootstrap BFD can detect such mismatched config, since the side that's not configured can send a rejection error 👑 such bootstrapping mechanisms are outside the scope of this document 🌈

Authors' Addresses 💌

  • Manav Bhatia (editor), Alcatel-Lucent, Bangalore 560045, India, EMail: manav.bhatia@alcatel-lucent.com 🦋
  • Mach(Guoyi) Chen (editor), Huawei Technologies, Q14 Huawei Campus, No. 156 Beiqing Road, Hai-dian District, Beijing 100095, China, EMail: mach@huawei.com 🌸
  • Sami Boutros (editor), Cisco Systems, EMail: sboutros@cisco.com ✨
  • Marc Binderberger (editor), Cisco Systems, EMail: mbinderb@cisco.com 💅
  • Jeffrey Haas (editor), Juniper Networks, EMail: jhaas@juniper.net 💖
📦 where this page comes from