rfc9521xml2.original.xml   rfc9521.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-ietf-nvo3-bfd-geneve-13" co <!DOCTYPE rfc [
nsensus="true" submissionType="IETF"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<front> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<title abbrev="BFD for Geneve"> BFD for Geneve </title> std" consensus="true" docName="draft-ietf-nvo3-bfd-geneve-13" number="9521" ipr=
"trust200902" tocInclude="true" symRefs="true" sortRefs="true" updates="" obsole
tes="" xml:lang="en" version="3">
<author fullname="Xiao Min" initials="X" surname="Min"> <!-- xml2rfc v2v3 conversion 3.18.0 -->
<organization>ZTE Corp.</organization> <front>
<address>
<postal>
<street/>
<!-- Reorder these if your country does things differently --> <title abbrev="BFD for Geneve">Bidirectional Forwarding Detection (BFD) for
Generic Network
Virtualization Encapsulation (Geneve)</title>
<seriesInfo name="RFC" value="9521"/>
<author fullname="Xiao Min" initials="X" surname="Min">
<organization>ZTE Corp.</organization>
<address>
<postal>
<street/>
<city>Nanjing</city> <city>Nanjing</city>
<region/>
<code/>
<country>China</country>
</postal>
<phone>+86 18061680168</phone>
<email>xiao.min2@zte.com.cn</email>
<region/>
<code/>
<country>China</country>
</postal>
<phone>+86 18061680168</phone>
<email>xiao.min2@zte.com.cn</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<author fullname="Greg Mirsky" initials="G" surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<!-- Reorder these if your country does things differently -->
<city></city>
<region></region>
<code></code>
<country>United States of America</country>
</postal>
<phone></phone>
<email>gregimirsky@gmail.com</email> <city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone/>
<email>gregimirsky@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti">
<author fullname="Santosh Pallagatti" initials="S" surname="Pallagatti">
<organization>VMware</organization> <organization>VMware</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city></city>
<region/>
<code/>
<country>India</country>
</postal>
<phone></phone>
<email>santosh.pallagatti@gmail.com</email> <city/>
<region/>
<code/>
<country>India</country>
</postal>
<phone/>
<email>santosh.pallagatti@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Nvidia</organization> <organization>Nvidia</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city></city>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone></phone>
<email>jefftant.ietf@gmail.com</email> <city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone/>
<email>jefftant.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<author fullname="Sam Aldrin" initials="S" surname="Aldrin">
<author fullname="Sam Aldrin" initials="S" surname="Aldrin">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<!-- Reorder these if your country does things differently -->
<city></city>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone></phone> <city/>
<region/>
<code/>
<country>United States of America</country>
</postal>
<phone/>
<email>aldrin.ietf@gmail.com</email>
<email>aldrin.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address> </address>
</author> </author>
<date year="2024" month="January" />
<date year="2023"/> <area>rtg</area>
<workgroup>nvo3</workgroup>
<area>Routing</area>
<workgroup>NVO3 Working Group</workgroup>
<keyword>Request for Comments</keyword>
<keyword>RFC</keyword>
<keyword>Internet Draft</keyword>
<keyword>I-D</keyword>
<abstract> <abstract>
<t> This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point <t> This document describes the use of the Bidirectional Forwarding Detect ion (BFD) protocol in point-to-point
Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. </t> Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. </t>
</abstract> </abstract>
</front>
</front> <middle>
<section>
<middle> <name>Introduction</name>
<t>"Geneve: Generic Network Virtualization Encapsulation" <xref target="RF
<section title="Introduction"> C8926" format="default"/> provides an encapsulation scheme
<t> "Generic Network Virtualization Encapsulation" (Geneve) <xref target="RFC8
926"/> provides an encapsulation scheme
that allows building an overlay network of tunnels by decoupling the address s pace of the attached virtual hosts from that allows building an overlay network of tunnels by decoupling the address s pace of the attached virtual hosts from
that of the network. </t> that of the network. </t>
<t> This document describes the use of the Bidirectional Forwarding Detect
<t> This document describes the use of Bidirectional Forwarding Detection (BFD ion (BFD) protocol <xref target="RFC5880"/>
) protocol <xref target="RFC5880"/> to enable monitoring the continuity of the path between two Geneve tunnel endp
to enable monitoring the continuity of the path between two Geneve tunnel endp oints, which may be a Network
oints, which may be a NVE (Network Virtualization Edge (NVE) or another device acting as a Geneve tunnel endpoint
Virtualization Edge) or another device acting as a Geneve tunnel endpoint. Spe . Specifically, the asynchronous mode of BFD,
cifically, the asynchronous mode of BFD, as defined in <xref target="RFC5880"/>, is used to monitor a point-to-point (P
as defined in <xref target="RFC5880"/>, is used to monitor a P2P Geneve tunnel 2P) Geneve tunnel. The support for the BFD Echo function is outside
. The support for BFD Echo function is outside the scope of this document. For simplicity, an NVE is used to represent the Ge
the scope of this document. For simplicity, NVE is used to represent the Genev neve tunnel endpoint.
e tunnel endpoint. A Tenant System (TS) is used to represent the physical or virtual device attac
TS (Tenant System) is used to represent the physical or virtual device attache hed to a Geneve tunnel endpoint from the
d to a Geneve tunnel endpoint from the outside. A Virtual Access Point (VAP) is the NVE side of the interface between
outside. VAP (Virtual Access Point) is the NVE side of the interface between t the NVE and the TS, and a VAP is a
he NVE and the TS, and a VAP is a
logical network port (virtual or physical) into a specific virtual network. Fo r detailed definitions and descriptions logical network port (virtual or physical) into a specific virtual network. Fo r detailed definitions and descriptions
of NVE, TS and VAP, please refer to <xref target="RFC7365"/> and <xref target= of NVE, TS, and VAP, please refer to <xref target="RFC7365"/> and <xref target
"RFC8014"/>. </t> ="RFC8014"/>. </t>
<t> The use cases and the deployment of BFD for Geneve are mostly
<t> The use cases and the deployment of BFD for Geneve are mostly consistent w consistent with what's described in Sections <xref target="RFC8971" section=
ith what's described in Section 1 and 3 of "1"
<xref target="RFC8971"/> ("Bidirectional Forwarding Detection (BFD) for Virtua sectionFormat="bare"/> and <xref target="RFC8971" section="3"
l eXtensible Local Area Network (VXLAN)"). sectionFormat="bare"/> of <xref target="RFC8971"/>. One exception is the
One exception is on the usage of Management VNI, which is described in <xref t usage of the Management Virtual Network Identifier (VNI), which is described
arget="I-D.ietf-nvo3-geneve-oam"/> and outside in <xref
the scope of this document. </t> target="I-D.ietf-nvo3-geneve-oam"/> and is outside the scope of this
document. </t>
<t> As specified in Section 4.2 of <xref target="RFC8926"/>, Geneve MUST be us <t> As specified in <xref target="RFC8926" sectionFormat="of"
ed with congestion-controlled traffic or section="4.2"/>, Geneve <bcp14>MUST</bcp14> be used with
within a traffic-managed controlled environment (TMCE) to avoid congestion, th congestion controlled traffic or within a Traffic-Managed Controlled
at requirement applies to BFD traffic too. Environment (TMCE) to avoid congestion; that requirement also applies to B
Specifically, considering the complexity and immaturity of BFD congestion cont FD
rol mechanism, BFD for Geneve MUST be used traffic. Specifically, considering the complexity and immaturity of
within a TMCE unless BFD is really congestion controlled. As an alternative to the BFD congestion control mechanism, BFD for Geneve <bcp14>MUST</bcp14>
a real congestion control, an operator of be used within a TMCE unless BFD is really congestion controlled. As an
a TMCE deploying BFD for Geneve is required to provision the rates at which BF alternative to a real congestion control, an operator of a TMCE
D is transmitted to avoid congestion and deploying BFD for Geneve is required to provision the rates at which BFD
false failure detection. </t> is transmitted to avoid congestion and false failure detection. </t>
</section>
<section title="Conventions Used in This Document">
<section title="Abbreviations">
<t> BFD: Bidirectional Forwarding Detection</t>
<t> FCS: Frame Check Sequence</t>
<t> Geneve: Generic Network Virtualization Encapsulation</t>
<t> NVE: Network Virtualization Edge</t>
<t> TMCE: Traffic-Managed Controlled Environment</t>
<t> TS: Tenant System</t>
<t> VAP: Virtual Access Point</t>
<t> VNI: Virtual Network Identifier</t>
<t> VXLAN: Virtual eXtensible Local Area Network</t>
</section> </section>
<section>
<section title="Requirements Language"> <name>Conventions Used in This Document</name>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <section>
"SHOULD", "SHOULD NOT", "RECOMMENDED", <name>Abbreviations</name>
"NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be int <dl newline="false" spacing="normal">
erpreted as described in BCP 14 <dt>BFD:</dt><dd>Bidirectional Forwarding Detection</dd>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, th <dt>FCS:</dt><dd>Frame Check Sequence</dd>
ey appear in all capitals, as shown here.</t> <dt>Geneve:</dt><dd>Generic Network Virtualization Encapsulation</dd>
<dt>NVE:</dt><dd>Network Virtualization Edge</dd>
<dt>TMCE:</dt><dd>Traffic-Managed Controlled Environment</dd>
<dt>TS:</dt><dd>Tenant System</dd>
<dt>VAP:</dt><dd>Virtual Access Point</dd>
<dt>VNI:</dt><dd>Virtual Network Identifier</dd>
<dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network</dd>
</dl>
</section>
<section>
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
</section> </section>
<section>
<name>BFD Packet Transmission over a Geneve Tunnel</name>
</section> <t> Since the Geneve data packet payload may be either an Ethernet frame
or an IP packet, this document defines two formats of BFD packet
<section title="BFD Packet Transmission over Geneve Tunnel"> encapsulation in Geneve. The BFD session is originated and terminated at
the VAP of an NVE. The selection of the BFD packet encapsulation is
<t> Since the Geneve data packet payload may be either an Ethernet frame or an based on how the VAP encapsulates the data packets. If the payload is
IP packet, this document defines two IP, then BFD over IP is carried in the payload. If the payload is
formats of BFD packet encapsulation in Geneve. The BFD session is originated a Ethernet, then BFD over IP over Ethernet is carried in the payload. This o
nd terminated at the VAP of an NVE. The selection ccurs in
of the BFD packet encapsulation is based on how the VAP encapsulates the data the same manner as BFD over IP in the IP payload case, regardless of
packets. If the payload is what the Ethernet payload might normally carry.</t>
IP, then BFD over IP is carried in the payload. If the payload is Ethernet, th </section>
en BFD over IP over Ethernet is carried in <section anchor="ethernet-ip-encaps-section">
the payload, in the same manner as BFD over IP in the IP payload case, regardl <name>BFD Encapsulation with the Inner Ethernet/IP/UDP Header</name>
ess of what the Ethernet payload might normally carry.</t> <t> If the VAP that originates the BFD packets is used to encapsulate
Ethernet data frames, then the BFD packets are encapsulated in Geneve as
</section> described below. The Geneve packet formats over IPv4 and IPv6 are
defined in Sections <xref target="RFC8926" sectionFormat="bare" section="3
<section anchor="ethernet-ip-encaps-section" title="BFD Encapsulation With Inn .1"/>
er Ethernet/IP/UDP Header"> and <xref target="RFC8926" sectionFormat="bare" section="3.2"/> of <xref
target="RFC8926"/>, respectively. The outer IP/UDP and Geneve headers are
<t> If the VAP that originates the BFD packets is used to encapsulate Ethernet encoded by the sender as defined in <xref target="RFC8926"/>. Note that
data frames, then the BFD packets are the outer IP header and the inner IP header may not be of the same
encapsulated in Geneve as described below. The Geneve packet formats over IPv4 address family. In other words, an outer IPv6 header accompanied by an
and IPv6 are defined in Section 3.1 and inner IPv4 header and an outer IPv4 header accompanied by an inner IPv6
3.2 of <xref target="RFC8926"/> respectively. The Outer IP/UDP and Geneve head header are both possible. </t>
ers are encoded by the sender <figure anchor="Figure_1">
as defined in <xref target="RFC8926"/>. Note that the outer IP header and the <name>Geneve Encapsulation of a BFD Control Packet with the Inner Ethern
inner IP header may not be of the same et/IP/UDP Header</name>
address family. In other words, an outer IPv6 header accompanied by an inner I <artwork align="left"><![CDATA[
Pv4 header and an outer IPv4 header accompanied
by an inner IPv6 header are both possible. </t>
<figure anchor="Figure_1" title="Geneve Encapsulation of BFD Control Packet
With the Inner Ethernet/IP/UDP Header">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Outer Ethernet Header ~ ~ Outer Ethernet Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Outer IPvX Header ~ ~ Outer IPvX Header ~
| | | |
skipping to change at line 266 skipping to change at line 236
| | | |
~ Inner UDP Header ~ ~ Inner UDP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet FCS | | Outer Ethernet FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> The BFD packet <bcp14>MUST</bcp14> be carried inside the inner Etherne
<t> The BFD packet MUST be carried inside the inner Ethernet frame of the G t frame of the Geneve packet.
eneve packet.
The inner Ethernet frame carrying the BFD Control packet has the fo llowing format: The inner Ethernet frame carrying the BFD Control packet has the fo llowing format:
<list> </t>
<t>Inner Ethernet Header:
<list>
<t>Destination MAC: MAC address of a V
AP of the terminating NVE.</t>
<t>Source MAC: MAC address of a VAP of
the originating NVE.</t>
</list>
</t>
<t>IP Header:
<list>
<t>Source IP: IP address of a VAP of t
he originating NVE. If the VAP of the originating NVE
has no IP address, then the IP address
0.0.0.0 for IPv4 or ::/128 for IPv6 MUST be used.</t>
<t>Destination IP: IP address of a VAP
of the terminating NVE. If the VAP of the terminating
NVE has no IP address, then the IP add
ress 127.0.0.1 for IPv4 or ::1/128 for IPv6 MUST be used.</t>
<t>TTL or Hop Limit: MUST be set to 25
5 in accordance with <xref target="RFC5881"/> that specifies the IPv4/IPv6 singl
e-hop BFD.</t>
</list>
</t>
<t> The fields of the UDP header and the BFD Control packet ar
e encoded as specified in <xref target="RFC5881"/>.</t>
</list>
</t>
<t> When the BFD packets are encapsulated in Geneve in this way, the Geneve
header defined in <xref target="RFC8926"/>
follows the value set below.</t>
<t>
<list>
<t> Opt Len field MUST be set consistent with the Geneve specification <xre
f target="RFC8926"/> depending on whether
or not Geneve options are present in the frame. The use of Geneve option
s with BFD is beyond the scope of this document.</t>
<t> O bit MUST be set to 1, which indicates this packet contains a contr
ol message.</t>
<t> C bit MUST be set to 0, which indicates there isn't any critical option <dl newline="true" spacing="normal">
.</t> <dt>Inner Ethernet Header:</dt>
<dd>
<dl newline="false" spacing="normal">
<dt>Destination MAC:</dt>
<dd>Media Access Control (MAC) address of a VAP of the terminating NV
E.</dd>
<t> Protocol Type field MUST be set to 0x6558 (Ethernet frame).</t> <dt>Source MAC:</dt>
<dd>MAC address of a VAP of the originating NVE.</dd>
</dl>
</dd>
</dl>
<t> Virtual Network Identifier (VNI) field MUST be set to the VNI number th <dl newline="true" spacing="normal">
at the originating VAP is mapped to.</t> <dt>IP Header:</dt>
</list> <dd>
</t> <dl newline="false" spacing="normal">
<dt>Source IP:</dt>
<dd>IP address of a VAP of the originating
NVE. If the VAP of the originating NVE has no IP address, then the
IP address 0.0.0.0 for IPv4 or ::/128 for IPv6 <bcp14>MUST</bcp14>
be used.</dd>
<section title="Demultiplexing BFD packet when payload is Ethernet"> <dt>Destination IP:</dt>
<dd>IP address of a VAP of the terminating
NVE. If the VAP of the terminating NVE has no IP address, then the
IP address 127.0.0.1 for IPv4 or ::1/128 for IPv6
<bcp14>MUST</bcp14> be used.</dd>
<t> Once a packet is received, the NVE validates the packet as described in <dt>TTL or Hop Limit:</dt>
<xref target="RFC8926"/>. When the <dd>The TTL for IPv4 or Hop Limit for IPv6 <bcp14>MUST</bcp14> be set
payload is Ethernet, the Protocol Type field equals 0x6558. The Destinati to 255 in
on MAC address of the inner Ethernet frame accordance with <xref target="RFC5881"/>, which specifies the
matches the MAC address of a VAP which is mapped to the same VNI as the r IPv4/IPv6 single-hop BFD.</dd>
eceived VNI. Then the Destination IP, the UDP </dl>
destination port and the TTL or Hop Limit of the inner IP packet MUST be <t>The fields of the UDP header and the BFD Control packet are
validated to determine whether the received encoded as specified in <xref target="RFC5881"/>.</t>
packet can be processed by BFD, i.e., the three field values of the inner </dd>
IP packet MUST be in compliance with what's </dl>
defined in Section 4 of this document, as well as Section 4 of <xref targ <t> When the BFD packets are encapsulated in Geneve in this way, the
et="RFC5881"/>. If the validation fails, the Geneve header defined in <xref target="RFC8926"/> follows the value
received packet MUST NOT be processed by BFD.</t> set below.</t>
<t> In BFD over Geneve, a BFD session is originated and terminated at a VAP. <ul spacing="normal">
Usually one NVE owns <li>The Opt Len field <bcp14>MUST</bcp14> be set as consistent with the
multiple VAPs. Since multiple BFD sessions may be running between two NVEs, Geneve specification (<xref target="RFC8926"/>) depending on whether
there needs to be a mechanism or not Geneve options are present in the frame. The use of Geneve option
for demultiplexing received BFD packets to the proper session. Furthermore, s with BFD is beyond the scope of this document.</li>
due to the fact that <li>The O bit <bcp14>MUST</bcp14> be set to 1, which indicates this pack
<xref target="RFC8014"/> allows for N-to-1 mapping between VAP and VNI at on et contains a control message.</li>
e NVE, multiple BFD sessions <li>The C bit <bcp14>MUST</bcp14> be set to 0, which indicates there isn
between two NVEs for the same VNI are allowed. Also note that a BFD session 't any critical option.</li>
can only be established between <li>The Protocol Type field <bcp14>MUST</bcp14> be set to 0x6558 (Ethern
two VAPs that are mapped to the same VNI and use the same way to encapsulate et frame).</li>
data packets. </t> <li>The Virtual Network Identifier (VNI) field <bcp14>MUST</bcp14> be se
t to the VNI number that the originating VAP is mapped to.</li>
</ul>
<section>
<name>Demultiplexing a BFD Packet When the Payload Is Ethernet</name>
<t> Once a packet is received, the NVE validates the packet as
described in <xref target="RFC8926"/>. When the payload is Ethernet,
the Protocol Type field equals 0x6558. The destination MAC address of
the inner Ethernet frame matches the MAC address of a VAP, which is
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 <bcp14>MUST</bcp14> be validated to determine whether
the received packet can be processed by BFD (i.e., the three field
values of the inner IP packet <bcp14>MUST</bcp14> be in compliance
with what's defined in <xref target="ethernet-ip-encaps-section"/> of
this document, as well as <xref target="RFC5881" sectionFormat="of"
section="4"/>). If the validation fails, the received packet
<bcp14>MUST NOT</bcp14> be processed by BFD.</t>
<t> If the BFD packet is received with Your Discriminator equals to 0, then <t> In BFD over Geneve, a BFD session is originated and terminated at
the BFD session SHOULD be identified using a VAP. Usually one NVE owns multiple VAPs. Since multiple BFD sessions
may be running between two NVEs, there needs to be a mechanism for
demultiplexing received BFD packets to the proper
session. Furthermore, due to the fact that <xref target="RFC8014"/>
allows for N-to-1 mapping between VAPs and VNIs at one NVE, multiple BFD
sessions between two NVEs for the same VNI are allowed. Also, 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. <
/t>
<t> If the BFD packet is received with the value of the Your Discriminat
or field set to 0, then the BFD session <bcp14>SHOULD</bcp14> be identified usin
g
the VNI number and the inner Ethernet/IP header. The inner Ethernet/IP he ader stands for the source MAC, the source IP, the VNI number and the inner Ethernet/IP header. The inner Ethernet/IP he ader stands for the source MAC, the source IP,
the destination MAC, and the destination IP. An implementation MAY use th e inner UDP port source number to aid in the destination MAC, and the destination IP. An implementation <bcp14>MAY </bcp14> use the inner UDP port source number to aid in
demultiplexing incoming BFD Control packets. If it fails to identify the BFD session, the incoming BFD Control packets 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 <bcp14>MUST</bcp14> be dropped, and an exception event indicating the fai
reported to the management.</t> lure should be reported to the management.</t>
<t> If the BFD packet is received with a non-zero Your Discriminator,
<t> If the BFD packet is received with non-zero Your Discriminator, then the then the BFD session <bcp14>MUST</bcp14> be demultiplexed only with
BFD session MUST be demultiplexed the Your Discriminator as the key. </t>
only with Your Discriminator as the key. </t> </section>
</section> </section>
<section anchor="ip-encaps-section">
</section> <name>BFD Encapsulation with the Inner IP/UDP Header</name>
<t> If the VAP that originates the BFD packets is used to encapsulate IP
<section anchor="ip-encaps-section" title="BFD Encapsulation With Inner IP/UDP data packets, then the BFD packets are encapsulated in Geneve as
Header"> described below. The Geneve packet formats over IPv4 and IPv6 are
defined in Sections <xref target="RFC8926"
<t> If the VAP that originates the BFD packets is used to encapsulate IP data sectionFormat="bare" section="3.1"/> and <xref target="RFC8926"
packets, then the BFD packets are sectionFormat="bare" section="3.2"/> of <xref target="RFC8926"/>,
encapsulated in Geneve as described below. The Geneve packet formats over IPv4 respectively. The outer IP/UDP and Geneve headers are encoded by the
and IPv6 are defined in Section 3.1 and sender as defined in <xref target="RFC8926"/>. Note that the outer IP
3.2 of <xref target="RFC8926"/> respectively. The Outer IP/UDP and Geneve head header and the inner IP header may not be of the same address family. In
ers are encoded by the sender other words, an outer IPv6 header accompanied by an inner IPv4 header
as defined in <xref target="RFC8926"/>. Note that the outer IP header and the and an outer IPv4 header accompanied by an inner IPv6 header are both
inner IP header may not be of the same possible. </t>
address family. In other words, an outer IPv6 header accompanied by an inner I <figure anchor="Figure_2">
Pv4 header and an outer IPv4 header accompanied <name>Geneve Encapsulation of a BFD Control Packet with the Inner IP/UDP
by an inner IPv6 header are both possible. </t> Header</name>
<artwork align="left"><![CDATA[
<figure anchor="Figure_2" title="Geneve Encapsulation of BFD Control Packet
With the Inner IP/UDP Header">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Ethernet Header ~ ~ Ethernet Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Outer IPvX Header ~ ~ Outer IPvX Header ~
| | | |
skipping to change at line 385 skipping to change at line 377
| | | |
~ Inner UDP Header ~ ~ Inner UDP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS | | FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t> The BFD packet <bcp14>MUST</bcp14> be carried inside the inner IP pack
<t> The BFD packet MUST be carried inside the inner IP packet of the Geneve et of the Geneve packet.
packet.
The inner IP packet carrying the BFD Control packet has the following forma t: The inner IP packet carrying the BFD Control packet has the following forma t:
<list> </t>
<t>Inner IP header: <dl newline="true" spacing="normal">
<list> <dt>Inner IP Header:</dt>
<t>Source IP: IP address of a VAP of t <dd>
he originating NVE.</t> <dl spacing="normal" newline="false">
<t>Destination IP: IP address of a VAP <dt>Source IP:</dt>
of the terminating NVE.</t> <dd>IP address of a VAP of the originating NVE.</dd>
<t>TTL or Hop Limit: MUST be set to 25
5 in accordance with <xref target="RFC5881"/> that specifies the IPv4/IPv6 singl
e-hop BFD.</t>
</list>
</t>
<t> The fields of the UDP header and the BFD Control packet ar <dt>Destination IP:</dt>
e encoded as specified in <xref target="RFC5881"/>.</t> <dd>IP address of a VAP of the terminating NVE.</dd>
</list> <dt>TTL or Hop Limit:</dt>
</t> <dd>The TTL for IPv4 or Hop Limit for IPv6 <bcp14>MUST</bcp14> be set
to 255 in accordance with <xref target="RFC5881"/>, which specifies the IPv4/IP
v6 single-hop BFD.</dd>
</dl>
<t> The fields of the UDP header and the BFD Control packet are enco
ded as specified in <xref target="RFC5881"/>.</t>
</dd>
</dl>
<t> When the BFD packets are encapsulated in Geneve in this way, the Geneve header defined in <xref target="RFC8926"/> <t> When the BFD packets are encapsulated in Geneve in this way, the Genev e header defined in <xref target="RFC8926"/>
follows the value set below.</t> follows the value set below.</t>
<t> <ul spacing="normal">
<list> <li>The Opt Len field <bcp14>MUST</bcp14> be set as consistent with the
<t> Opt Len field MUST be set consistent with the Geneve specification <xre Geneve specification (<xref target="RFC8926"/>) depending on whether
f target="RFC8926"/> depending on whether or not Geneve options are present in the frame. The use of Geneve option
or not Geneve options are present in the frame. The use of Geneve option s with BFD is beyond the scope of this document.</li>
s with BFD is beyond the scope of this document.</t> <li>The O bit <bcp14>MUST</bcp14> be set to 1, which indicates this pack
et contains a control message.</li>
<t> O bit MUST be set to 1, which indicates this packet contains a contr <li>The C bit <bcp14>MUST</bcp14> be set to 0, which indicates there isn
ol message.</t> 't any critical option.</li>
<li>The Protocol Type field <bcp14>MUST</bcp14> be set to 0x0800 (IPv4)
<t> C bit MUST be set to 0, which indicates there isn't any critical option or 0x86DD (IPv6), depending on the address family
.</t> of the inner IP packet.</li>
<li>The Virtual Network Identifier (VNI) field <bcp14>MUST</bcp14> be se
<t> Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6), depe t to the VNI number that the originating VAP is mapped to.</li>
nding on the address family </ul>
of the inner IP packet.</t> <section>
<name>Demultiplexing a BFD Packet When the Payload Is IP</name>
<t> Virtual Network Identifier (VNI) field MUST be set to the VNI number th <t> Once a packet is received, the NVE validates the packet as
at the originating VAP is mapped to.</t> described in <xref target="RFC8926"/>. When the payload is IP, the
</list> Protocol Type field equals 0x0800 or 0x86DD. The destination IP
</t> address of the inner IP packet matches the IP address of a VAP, which
is mapped to the same VNI as the received VNI. Then, the UDP
<section title="Demultiplexing BFD packet when payload is IP"> destination port and the TTL or Hop Limit of the inner IP packet
<bcp14>MUST</bcp14> be validated to determine whether or not the receive
<t> Once a packet is received, the NVE validates the packet as described in d
<xref target="RFC8926"/>. When the packet can be processed by BFD (i.e., the two field values of the
payload is IP, the Protocol Type field equals 0x0800 or 0x86DD. The Desti inner IP packet <bcp14>MUST</bcp14> be in compliance with what's
nation IP address of the inner IP packet matches defined in <xref sectionFormat="of" target="ip-encaps-section"/> of
the IP address of a VAP which is mapped to the same VNI as the received V this document as well as <xref target="RFC5881" sectionFormat="of"
NI. Then the UDP destination port and the TTL or Hop section="4"/>). If the validation fails, the received packet
Limit of the inner IP packet MUST be validated to determine whether the r <bcp14>MUST NOT</bcp14> be processed by BFD.</t>
eceived packet can be processed by BFD, i.e., <t> If the BFD packet is received with the value of the Your Discriminat
the two field values of the inner IP packet MUST be in compliance with wh or field set to 0, then the BFD session <bcp14>SHOULD</bcp14> be identified usin
at's defined in Section 5 of this document, as well g the VNI
as Section 4 of <xref target="RFC5881"/>. If the validation fails, the re number and the inner IP header. The inner IP header stands for the source
ceived packet MUST NOT be processed by BFD.</t> IP and the destination IP. An implementation <bcp14>MAY</bcp14>
<t> If the BFD packet is received with Your Discriminator equals to 0, then
the BFD session SHOULD be identified using the VNI
number and the inner IP header. The inner IP header stands for the source
IP and the destination IP. An implementation MAY
use the inner UDP port source number to aid in demultiplexing incoming BF D Control packets. If it fails to identify the BFD session, use the inner UDP port source number to aid in demultiplexing incoming BF D Control packets. If it fails to identify the BFD session,
the incoming BFD Control packets MUST be dropped, and an exception event the incoming BFD Control packets <bcp14>MUST</bcp14> be dropped, and an e
indicating the failure should be reported to the management.</t> xception event indicating the failure should be reported to the management.</t>
<t> If the BFD packet is received with a non-zero Your Discriminator, th
<t> If the BFD packet is received with non-zero Your Discriminator, then the en the BFD session <bcp14>MUST</bcp14> be demultiplexed
BFD session MUST be demultiplexed only with the Your Discriminator as the key. </t>
only with Your Discriminator as the key. </t> </section>
</section> </section>
<section>
</section> <name>Security Considerations</name>
<t> Security issues discussed in <xref target="RFC8926"/> and <xref target
<section title="Security Considerations"> ="RFC5880"/> apply to this document. Particularly,
<t> Security issues discussed in <xref target="RFC8926"/> and <xref target="RF
C5880"/> apply to this document. Particularly,
the BFD is an application that is run at the two Geneve tunnel endpoints. The IP underlay network and/or the Geneve option the BFD is an application that is run 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 over load described below. The BFD introduces no can provide security between the peers, which are subject to the issue of over load described below. The BFD introduces no
security vulnerabilities when run in this manner. Considering Geneve does not have any inherent security mechanisms, BFD security vulnerabilities when run in this manner. Considering Geneve does not have any inherent security mechanisms, BFD
authentication as specified in <xref target="RFC5880"/> is RECOMMENDED to be u authentication as specified in <xref target="RFC5880"/> is <bcp14>RECOMMENDED<
tilized.</t> /bcp14> to be utilized.</t>
<t> This document supports establishing multiple BFD sessions between the same
pair of NVEs, 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, assuming an exampl
e that each NVE of the pair of NVEs has N VAPs
using Ethernet as the payload, then there could be N squared BFD sessions runn
ing between the pair of NVEs. Considering N
could be a high number, the 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. Generall
y speaking, the number of BFD sessions is
supposed to be enough as long as all VAPs of the pair of NVEs are covered.</t>
</section> <t>
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 <bcp14>SHOULD</bcp14> be a mechanism to control
the
maximum number of such sessions that can be active at the same time.
Particularly, assuming an example that each NVE of the pair
of NVEs has N VAPs using Ethernet as the payload, then there could be N
squared BFD sessions running between the pair of NVEs. Considering N
could be a high number, the 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.</t>
</section>
<section>
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section title="IANA Considerations"> </middle>
<t> This document has no IANA action requested.</t> <back>
</section>
<section title="Acknowledgements"> <displayreference target="I-D.ietf-nvo3-geneve-oam" to="GENEVE-OAM"/>
<t> The authors would like to acknowledge Reshad Rahman, Jeffrey Haas, and Mat
thew Bocci for their guidance
on this work.</t>
<t> The authors would like to acknowledge David Black for his explanation on t
he mapping relation between VAP
and VNI.</t>
<t> The authors would like to acknowledge Stewart Bryant, Anoop Ghanwani, Jeff
rey Haas, Reshad Rahman, Matthew
Bocci, Andrew Alston, Magnus Westerlund, Paul Kyzivat, Sheng Jiang, Carl Walla
ce, Roman Danyliw, John Scudder,
Donald Eastlake, Eric Vyncke, Zaheduzzaman Sarker, and Lars Eggert for their t
horough review and very helpful
comments.</t>
</section>
</middle> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
881.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
926.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
365.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
014.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
971.xml"/>
<back> <!-- [I-D.ietf-nvo3-geneve-oam] IESG state I-D Exists. Used Long Way
to fix D. Black's initials. -->
<references title="Normative References"> <reference anchor="I-D.ietf-nvo3-geneve-oam" target="https://datatracker.ietf.or
<?rfc include="reference.RFC.5880"?> g/doc/html/draft-ietf-nvo3-geneve-oam-09">
<?rfc include="reference.RFC.5881"?> <front>
<?rfc include="reference.RFC.2119"?> <title>OAM for use in GENEVE</title>
<?rfc include="reference.RFC.8174"?> <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<?rfc include="reference.RFC.8926"?> <organization>Ericsson</organization>
</author>
<author initials="S." surname="Boutros" fullname="Sami Boutros">
<organization>Ciena</organization>
</author>
<author initials="D." surname="Black" fullname="David L. Black">
<organization>Dell EMC</organization>
</author>
<author initials="S." surname="Pallagatti" fullname="Santosh Pallagatti">
<organization>VMware</organization>
</author>
<date month="December" day="6" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-geneve-oam-09"/>
</reference>
</references>
</references> </references>
<references title="Informative References"> <section numbered="false">
<?rfc include="reference.RFC.7365"?> <name>Acknowledgements</name>
<?rfc include="reference.RFC.8014"?> <t> The authors would like to acknowledge <contact fullname="Reshad
<?rfc include="reference.RFC.8971"?> Rahman"/>, <contact fullname="Jeffrey Haas"/>, and <contact fullname="Matt
<?rfc include="reference.I-D.ietf-nvo3-geneve-oam"?> hew
</references> Bocci"/> for their guidance on this work.</t>
<t> The authors would like to acknowledge <contact fullname="David Black"/
>
for his explanation on the mapping relation between VAPs and VNIs.</t>
<t> The authors would like to acknowledge <contact fullname="Stewart
Bryant"/>, <contact fullname="Anoop Ghanwani"/>, <contact fullname="Jeffre
y
Haas"/>, <contact fullname="Reshad Rahman"/>, <contact fullname="Matthew
Bocci"/>, <contact fullname="Andrew Alston"/>, <contact fullname="Magnus
Westerlund"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Shen
g
Jiang"/>, <contact fullname="Carl Wallace"/>, <contact fullname="Roman
Danyliw"/>, <contact fullname="John Scudder"/>, <contact fullname="Donald
Eastlake 3rd"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Zaheduzzaman Sarker"/>, and <contact fullname="Lars Egg
ert"/> for
their thorough review and very helpful comments.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 60 change blocks. 
462 lines changed or deleted 452 lines changed or added

This html diff was produced by rfcdiff 1.48.