RFC 9521

Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve)

📅 published January 2024, from ietf

Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve) 💖

okay bestie, let's get into it ✨ this one is an RFC (basically the official rulebook the Internet runs on), and it's a Standards Track document, which means it's the real deal 💅 it's from the IETF, it's got consensus, and it was approved by the IESG 🫶

Document number: RFC 9521 Category: Standards Track Date: January 2024 Obsoletes / Updates: this doc isn't listed as obsoleting or updating anything in the title block 👀

Authors: X. Min (ZTE Corp.), G. Mirsky (Ericsson), S. Pallagatti (VMware), J. Tantsura (Nvidia), and S. Aldrin (Google) 🌈

The ISSN is 2070-1721 🎀

Abstract

This doc describes how to use Bidirectional Forwarding Detection (BFD) in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels, the ones that build an overlay network 🦋

Status of This Memo

It's an Internet Standards Track document 💅 It came from the IETF, it represents the IETF community's consensus, it got public review, and the IESG signed off on it. If you want more on Internet Standards, check out Section 2 of RFC 7841. Errata and feedback info live at https://www.rfc-editor.org/info/rfc9521 🔥

Copyright (c) 2024 IETF Trust and the document authors. All rights reserved 🎀

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions. Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Revised BSD License says 🫶

Table of Contents

  • 1. Introduction
  • 2. Conventions Used in This Document
    • 2.1. Abbreviations
    • 2.2. Requirements Language
  • 3. BFD Packet Transmission over a Geneve Tunnel
  • 4. BFD Encapsulation with the Inner Ethernet/IP/UDP Header
    • 4.1. Demultiplexing a BFD Packet When the Payload Is Ethernet
  • 5. BFD Encapsulation with the Inner IP/UDP Header
    • 5.1. Demultiplexing a BFD Packet When the Payload Is IP
  • 6. Security Considerations
  • 7. IANA Considerations
  • 8. References
    • 8.1. Normative References
    • 8.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction ✨

okay so the first part of the story is Geneve 🧚 [RFC8926] gives you an encapsulation scheme for building overlay networks of tunnels, and the big win is that it decouples the address space of the attached virtual hosts from the address space of the network itself. no more address drama 💜

This doc is about using BFD [RFC5880] to keep an eye on whether the path between two Geneve tunnel endpoints is still working. Those endpoints can be a Network Virtualization Edge (NVE) or some other device acting as a Geneve tunnel endpoint 🦋 Specifically, BFD's asynchronous mode (from [RFC5880]) is what gets used to monitor a point-to-point (P2P) Geneve tunnel. BFD Echo support is out of scope here 🙈 For simplicity, the doc uses "NVE" to mean the Geneve tunnel endpoint 💖

Some more vocab, because it's giving alphabet soup 🍓 A Tenant System (TS) is the physical or virtual device hanging off a Geneve tunnel endpoint, seen from the outside. A Virtual Access Point (VAP) is the NVE side of the NVE-to-TS interface, and it's a logical network port (virtual or physical) into one specific virtual network. For the full definitions of NVE, TS, and VAP, go check [RFC7365] and [RFC8014] 🌸

The use cases and deployment of BFD for Geneve are mostly the same as what's in Sections 1 and 3 of [RFC8971] ✨ The one exception is the Management Virtual Network Identifier (VNI). That's covered in [GENEVE-OAM] and it's outside this doc's scope 🫶

Now the serious part 💀 As Section 4.2 of [RFC8926] says, Geneve MUST be used with congestion controlled traffic, or inside a Traffic-Managed Controlled Environment (TMCE), to avoid congestion. That requirement applies to BFD traffic too 👑 Since BFD's congestion control mechanism is complicated and still pretty new, BFD for Geneve MUST be used within a TMCE unless BFD is actually congestion controlled. If you're an operator of a TMCE and you deploy BFD for Geneve, you are REQUIRED to provision the rates BFD is sent at, to avoid congestion and false failure detection 😭 That's the alternative to real congestion control.

2. Conventions Used in This Document

2.1. Abbreviations

  • BFD: Bidirectional Forwarding Detection
  • FCS: Frame Check Sequence
  • Geneve: Generic Network Virtualization Encapsulation
  • NVE: Network Virtualization Edge
  • TMCE: Traffic-Managed Controlled Environment
  • TS: Tenant System
  • VAP: Virtual Access Point
  • VNI: Virtual Network Identifier
  • VXLAN: Virtual eXtensible Local Area Network

2.2. Requirements Language

Okay this part is important 🎀 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 read as described in BCP 14 [RFC2119] [RFC8174], but ONLY when they show up in ALL CAPITALS, exactly like that 💅

3. BFD Packet Transmission over a Geneve Tunnel

Since a Geneve data packet's payload can be either an Ethernet frame or an IP packet, this doc defines two formats for BFD packet encapsulation in Geneve 🦋 The BFD session is originated and terminated at the VAP of an NVE. Which encapsulation you get depends on how the VAP encapsulates its data packets. If the payload is IP, then BFD over IP rides in the payload. If the payload is Ethernet, then BFD over IP over Ethernet rides in the payload. That works the same way as BFD over IP in the IP payload case, no matter what the Ethernet payload would normally carry 🧚

4. BFD Encapsulation with the Inner Ethernet/IP/UDP Header ✨

If the VAP that originates the BFD packets is used to encapsulate Ethernet data frames, then the BFD packets get encapsulated in Geneve like this 🌈 The Geneve packet formats over IPv4 and IPv6 are defined in Sections 3.1 and 3.2 of [RFC8926], respectively. The sender encodes the outer IP/UDP and Geneve headers as defined in [RFC8926] 💜 Heads up: the outer IP header and the inner IP header don't have to be the same address family 👀 So an outer IPv6 header with an inner IPv4 header is possible, and so is an outer IPv4 header with an inner IPv6 header 🫶

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Outer Ethernet Header                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Outer IPvX Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Outer UDP Header                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Geneve Header                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Inner Ethernet Header                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Inner IPvX Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Inner UDP Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        BFD Control Packet                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Outer Ethernet FCS                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: Geneve Encapsulation of a BFD Control Packet with the Inner
                           Ethernet/IP/UDP Header

The BFD packet MUST be carried inside the inner Ethernet frame of the Geneve packet 🫶 The inner Ethernet frame that carries the BFD Control packet has this format:

  • Inner Ethernet Header:
    • Destination MAC: Media Access Control (MAC) address of a VAP of the terminating NVE.
    • Source MAC: MAC address of a VAP of the originating NVE.
  • IP Header:
    • Source IP: IP address of a VAP of the originating NVE. If the originating NVE's VAP has no IP address, then the IP address 0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used 🌸
    • Destination IP: IP address of a VAP of the terminating NVE. If the terminating NVE's VAP has no IP address, then the IP address 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used 💖
    • TTL or Hop Limit: The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255, following [RFC5881], which covers IPv4/IPv6 single-hop BFD ✨
  • The fields of the UDP header and the BFD Control packet are encoded as [RFC5881] specifies 🧚

When BFD packets are encapsulated in Geneve this way, the Geneve header from [RFC8926] follows the values set below 🍓

  • The Opt Len field MUST be set consistently with the Geneve specification ([RFC8926]), depending on whether or not Geneve options are present in the frame. Using Geneve options with BFD is outside this doc's scope 🙈
  • The O bit MUST be set to 1, which indicates this packet contains a control message 💅
  • The C bit MUST be set to 0, which indicates there isn't any critical option 🌈
  • The Protocol Type field MUST be set to 0x6558 (Ethernet frame) 🦋
  • The Virtual Network Identifier (VNI) field MUST be set to the VNI number that the originating VAP is mapped to 💜

Part 1 of 3 is done, bestie 🎀 Keep the next part coming, I'm obsessed 🫶

4.1. Demultiplexing a BFD Packet When the Payload Is Ethernet 💖

okay bestie, once a packet lands, the NVE validates it as described in [RFC8926] 🫶 When the payload is Ethernet, the Protocol Type field equals 0x6558 ✨ The destination MAC address of the inner Ethernet frame has to match the MAC address of a VAP that's mapped to the same VNI as the received VNI 🦋 Then the destination IP, the UDP destination port, and the TTL or Hop Limit of the inner IP packet MUST be validated to see if BFD can process the packet. The three field values MUST be in compliance with what's defined in Section 4 of this document, as well as Section 4 of [RFC5881] 🔥 If validation fails, the received packet MUST NOT be processed by BFD 💀

In BFD over Geneve, a BFD session is originated and terminated at a VAP 🌸 Usually one NVE owns multiple VAPs 👑 Since multiple BFD sessions may be running between two NVEs, there needs to be a way to demultiplex received BFD packets to the right session 🧚 Also, [RFC8014] allows N-to-1 mapping between VAPs and VNIs at one NVE, so multiple BFD sessions between two NVEs for the same VNI are allowed 🌈 Just note that a BFD session can only be established between two VAPs that are mapped to the same VNI and that use the same way to encapsulate data packets 🙈

If the BFD packet is received with the value of the Your Discriminator field set to 0, then the BFD session SHOULD be identified using the VNI number and the inner Ethernet/IP header 🎀 The inner Ethernet/IP header covers the source MAC, the source IP, the destination MAC, and the destination IP. An implementation MAY use the inner UDP port source number to help with demultiplexing incoming BFD Control packets 💜 If it fails to identify the BFD session, the incoming BFD Control packets MUST be dropped, and an exception event indicating the failure should be reported to the management 😭

If the BFD packet is received with a non-zero Your Discriminator, then the BFD session MUST be demultiplexed only with the Your Discriminator as the key 🍓

5. BFD Encapsulation with the Inner IP/UDP Header ✨

If the VAP that originates the BFD packets is used to encapsulate IP data packets, then the BFD packets are encapsulated in Geneve as described below 🦋 The Geneve packet formats over IPv4 and IPv6 are defined in Sections 3.1 and 3.2 of [RFC8926], respectively. The outer IP/UDP and Geneve headers are encoded by the sender as defined in [RFC8926] 🫶 Also, the outer IP header and the inner IP header don't have to be the same address family. So an outer IPv6 header with an inner IPv4 header is possible, and so is an outer IPv4 header with an inner IPv6 header 🌈

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Ethernet Header                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Outer IPvX Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Outer UDP Header                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          Geneve Header                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Inner IPvX Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Inner UDP Header                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        BFD Control Packet                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               FCS                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 2: Geneve Encapsulation of a BFD Control Packet with the
                            Inner IP/UDP Header

The BFD packet MUST be carried inside the inner IP packet of the Geneve packet 🎀 The inner IP packet carrying the BFD Control packet has the following format:

Inner IP Header:

  • Source IP: IP address of a VAP of the originating NVE. 🌸
  • Destination IP: IP address of a VAP of the terminating NVE. 🌸
  • TTL or Hop Limit: The TTL for IPv4 or Hop Limit for IPv6 MUST be set to 255 in accordance with [RFC5881], which specifies the IPv4/IPv6 single-hop BFD 🔥

The fields of the UDP header and the BFD Control packet are encoded as specified in [RFC5881] 🦋

When the BFD packets are encapsulated in Geneve this way, the Geneve header defined in [RFC8926] follows the values set below 💅

  • The Opt Len field MUST be set as consistent with the Geneve specification ([RFC8926]) depending on whether or not Geneve options are present in the frame. The use of Geneve options with BFD is beyond the scope of this document 🧚
  • The O bit MUST be set to 1, which indicates this packet contains a control message 👑
  • The C bit MUST be set to 0, which indicates there isn't any critical option 🫶
  • The Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), depending on the address family of the inner IP packet 🌈
  • The Virtual Network Identifier (VNI) field MUST be set to the VNI number that the originating VAP is mapped to 💖

5.1. Demultiplexing a BFD Packet When the Payload Is IP 🌸

Once a packet is received, the NVE validates the packet as described in [RFC8926] ✨ When the payload is IP, the Protocol Type field equals 0x0800 or 0x86DD 🦋 The destination IP address of the inner IP packet has to match the IP address of a VAP that's mapped to the same VNI as the received VNI. Then the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to see whether or not BFD can process the received packet. The two field values of the inner IP packet MUST be in compliance with what's defined in Section 5 of this document, as well as Section 4 of [RFC5881] 🔥 If the validation fails, the received packet MUST NOT be processed by BFD 💀

If the BFD packet is received with the value of the Your Discriminator field set to 0, then the BFD session SHOULD be identified using the VNI number and the inner IP header 🎀 The inner IP header covers the source IP and the destination IP. An implementation MAY use the inner UDP port source number to help with demultiplexing incoming BFD Control packets 💜 If it fails to identify the BFD session, the incoming BFD Control packets MUST be dropped, and an exception event indicating the failure should be reported to the management 😭

If the BFD packet is received with a non-zero Your Discriminator, then the BFD session MUST be demultiplexed only with the Your Discriminator as the key 🍓

6. Security Considerations 🔐

Okay bestie, this section is seriously important, so read it carefully 💀

Security issues discussed in [RFC8926] and [RFC5880] apply to this document. Particularly, BFD is an application that runs at the two Geneve tunnel endpoints 😭 The IP underlay network and/or the Geneve option can provide security between the peers, which are subject to the issue of overload described below 🛡️ BFD introduces no security vulnerabilities when run in this manner. Since Geneve doesn't have any inherent security mechanisms, BFD authentication as specified in [RFC5880] is RECOMMENDED to be utilized 🔥

This document supports establishing multiple BFD sessions between the same pair of NVEs. For each BFD session over a pair of VAPs residing in the same pair of NVEs, there SHOULD be a mechanism to control the maximum number of such sessions that can be active at the same time 🧯 Particularly, imagine each NVE of the pair has N VAPs using Ethernet as the payload. Then there could be N squared BFD sessions running between the pair of NVEs 💀 Since N could be a high number, those N squared BFD sessions could result in overload of the NVE. In this case, it's recommended that N BFD sessions covering all N VAPs are run for the pair of NVEs 🫶 Generally speaking, the number of BFD sessions is supposed to be enough as long as all VAPs of the pair of NVEs are covered ✨

7. IANA Considerations 🌈

This document has no IANA actions. 🌸

8. References 📚

8.1. Normative References

8.2. Informative References ✨

okay so these are the "good to know" reads 📚 they're not required to implement the spec, but they give you the background 💅

Acknowledgements 🫶

the authors wanna give a huge shoutout to Reshad Rahman, Jeffrey Haas, and Matthew Bocci for their guidance on this work 🙌

they also thanked David Black for explaining the mapping relation between VAPs and VNIs 🧠

and a massive thank you to Stewart Bryant, Anoop Ghanwani, Jeffrey Haas, Reshad Rahman, Matthew Bocci, Andrew Alston, Magnus Westerlund, Paul Kyzivat, Sheng Jiang, Carl Wallace, Roman Danyliw, John Scudder, Donald Eastlake 3rd, Éric Vyncke, Zaheduzzaman Sarker, and Lars Eggert for their thorough review and super helpful comments 💖 the whole review squad is iconic 👑

Authors' Addresses 💌

these are the people who wrote it, so here's how to reach them 🦋

Xiao Min

Xiao Min
ZTE Corp.
Nanjing
China
Phone: +86 18061680168
Email: xiao.min2@zte.com.cn

Greg Mirsky

Greg Mirsky
Ericsson
United States of America
Email: gregimirsky@gmail.com

Santosh Pallagatti

Santosh Pallagatti
VMware
India
Email: santosh.pallagatti@gmail.com

Jeff Tantsura

Jeff Tantsura
Nvidia
United States of America
Email: jefftant.ietf@gmail.com

Sam Aldrin

Sam Aldrin
Google
United States of America
Email: aldrin.ietf@gmail.com

and that's a wrap on RFC 9521!! 🌈✨ the whole squad is slay 💅🎀

📦 where this page comes from