rfc8971xml2.original.xml   rfc8971.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-bfd-vxlan-16" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <!-- updated by Chris 10/29/20 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-bfd-vxlan-16" number="8971" ipr="trust200902"
obsoletes="" updates="" submissionType="IETF" category="info"
consensus="true" xml:lang="en" tocInclude="true" tocDepth="4"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.3.0 -->
<front> <front>
<title abbrev="BFD for VXLAN"> <title abbrev="BFD for VXLAN">
BFD for VXLAN Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area
Network (VXLAN)
</title> </title>
<seriesInfo name="RFC" value="8971"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Santosh Pallagatti" role="editor" initials="S." surname=" Pallagatti"> <author fullname="Santosh Pallagatti" role="editor" initials="S." surname=" Pallagatti">
<organization>VMware</organization> <organization>VMware</organization>
<address> <address>
<email>santosh.pallagatti@gmail.com</email> <email>santosh.pallagatti@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" role="editor" initials="G." surname="Mirsky">
<author fullname="Greg Mirsky" role="editor" initials="G." surname="Mirsk
y">
<organization>ZTE Corp.</organization> <organization>ZTE Corp.</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<!--
<author fullname="Basil Saji" initials="B."
surname="Saji">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>Embassy Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560093</code>
<country>India</country>
</postal>
<email>sbasil@juniper.net</email>
</address>
</author>
<author fullname="Sudarsan Paragiri " initials="S." surname="Paragiri"> <author fullname="Sudarsan Paragiri " initials="S." surname="Paragiri">
<organization>Individual Contributor</organization> <organization>Individual Contributor</organization>
<address> <address>
<email>sudarsan.225@gmail.com</email> <email>sudarsan.225@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Vengada Prasad Govindan" initials="V." surname="Govindan">
<author fullname="Vengada Prasad Govindan" initials="V." surname="Govinda
n">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>venggovi@cisco.com</email> <email>venggovi@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Mallik Mudigonda" initials="M." surname="Mudigonda">
<author fullname="Mallik Mudigonda" initials="M." surname="Mudigonda">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>mmudigon@cisco.com</email> <email>mmudigon@cisco.com</email>
</address> </address>
</author> </author>
<date year="2020" month="December" />
<date year="2020"/>
<area>Routing</area> <area>Routing</area>
<workgroup>BFD</workgroup> <workgroup>BFD</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>BFD</keyword> <keyword>BFD</keyword>
<keyword>BFD for VXLAN</keyword> <keyword>BFD for VXLAN</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t>This document describes the use of the Bidirectional Forwarding Detec tion (BFD) protocol <t>This document describes the use of the Bidirectional Forwarding Detecti on (BFD) protocol
in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels in point-to-point Virtual eXtensible Local Area Network (VXLAN) tunnels
used to form an overlay network.</t> used to form an overlay network.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" anchor="Intro"> <section anchor="Intro" numbered="true" toc="default">
<name>Introduction</name>
<t> <t>
"Virtual eXtensible Local Area Network" (VXLAN) <xref target="RFC7348"/> pro "Virtual eXtensible Local Area Network (VXLAN)" <xref target="RFC7348" forma
vides t="default"/> provides
an encapsulation scheme that allows building an overlay network by an encapsulation scheme that allows the building of an overlay network by
decoupling the address space of the attached virtual hosts from that of the ne twork. decoupling the address space of the attached virtual hosts from that of the ne twork.
</t> </t>
<t>
<t>
One use of VXLAN is in data centers interconnecting virtual machines (VMs) One use of VXLAN is in data centers interconnecting virtual machines (VMs)
of a tenant. VXLAN addresses requirements of the Layer 2 and of a tenant. VXLAN addresses the requirements of the Layer 2 and
Layer 3 data center network infrastructure in the presence of VMs in a multi-ten Layer 3 data-center network infrastructure in the presence of VMs in a multi-ten
ant environment by ant environment by
providing a Layer 2 overlay scheme on a Layer 3 network <xref target="RFC7348"/ providing a Layer 2 overlay scheme on a Layer 3 network <xref target="RFC7348"
>. format="default"/>.
Another use is as an encapsulation for Ethernet VPN <xref target="RFC8365"/>. Another use is as an encapsulation for Ethernet VPN <xref target="RFC8365" form
</t> at="default"/>.
<t> </t>
<t>
This document is written assuming the use of VXLAN for virtualized This document is written assuming the use of VXLAN for virtualized
hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in hypervisors. How ever, the hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in hypervisors. How ever, the
concepts are equally applicable to non-virtualized hosts attached to concepts are equally applicable to non-virtualized hosts attached to
VTEPs in switches. VTEPs in switches.
</t> </t>
<t>In the absence of a router in the overlay, a VM can communicate with an
<t>In the absence of a router in the overlay, a VM can communicate with ano other VM only if they are on the same VXLAN segment.
ther VM only if they are on the same VXLAN segment. VMs are unaware of VXLAN tunnels, because a VXLAN tunnel is terminated o
VMs are unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VT n a VTEP.
EP.
VTEPs are responsible for encapsulating and decapsulating frames exchang ed among VTEPs are responsible for encapsulating and decapsulating frames exchang ed among
VMs. </t> VMs. </t>
<t>
<t> The ability to monitor path continuity -- i.e., perform proactive
The ability to monitor path continuity, i.e., perform proactive continuity c continuity check (CC) for point-to-point (p2p) VXLAN tunnels -- is
heck (CC) for point-to-point (p2p) VXLAN tunnels, is important. important.
The asynchronous mode of BFD, as defined in <xref target="RFC5880"/>, is The asynchronous mode of BFD, as defined in <xref target="RFC5880" format
used to monitor a p2p VXLAN tunnel. ="default"/>, is used to monitor a p2p VXLAN tunnel.
</t> </t>
<t>
<t> In the case where a Multicast Service Node (MSN) (as described in
In the case where a Multicast Service Node (MSN) (as described in Section 3.3 <xref target="RFC8293" sectionFormat="of" section="3.3"/>) participates i
of <xref target="RFC8293"/>) participates in VXLAN, the mechanisms described in n VXLAN, the
this mechanisms described in this
document apply and can, therefore, be used to test the continuity of the path be document apply and can, therefore, be used to test the continuity of the
tween path between
the source NVE and the MSN. the source Network Virtualization Endpoint (NVE) and the MSN.
</t> </t>
<t>
<t> This document describes the use of the Bidirectional Forwarding Detection (B
This document describes the use of Bidirectional Forwarding Detection (BFD) FD) protocol
protocol
to enable monitoring continuity of the path between VXLAN VTEPs that are to enable monitoring continuity of the path between VXLAN VTEPs that are
performing as Network Virtualization Endpoints, performing as VNEs,
and/or between the source NVE and a replicator MSN using a Management VN and/or between the source NVE and a replicator MSN using a Management
I (<xref target="management-vni-sec"/>). VXLAN Network Identifier (VNI) (<xref target="management-vni-sec" format=
All other uses of the specification to test toward other VXLAN endpoints "default"/>).
are out of the scope. All other uses of the specification to test toward other VXLAN endpoints
</t> are out of scope.
</t>
</section> </section>
<section numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<section numbered="true" toc="default">
<name>Abbreviations</name>
<dl indent="9">
<dt>BFD:</dt><dd>Bidirectional Forwarding Detection</dd>
<dt>CC:</dt><dd>Continuity Check</dd>
<dt>FCS:</dt><dd>Frame Check Sequence</dd>
<dt>MSN:</dt><dd>Multicast Service Node</dd>
<dt>NVE:</dt><dd>Network Virtualization Endpoint</dd>
<dt>p2p:</dt><dd>Point-to-point</dd>
<dt>VFI:</dt><dd>Virtual Forwarding Instance</dd>
<dt>VM:</dt><dd>Virtual Machine</dd>
<dt>VNI:</dt><dd>VXLAN Network Identifier (or VXLAN Segment ID)</dd>
<dt>VTEP:</dt><dd>VXLAN Tunnel End Point</dd>
<dt>VXLAN:</dt><dd>Virtual eXtensible Local Area Network</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 title="Conventions Used in this Document"> </section>
<section title="Acronyms">
<t>BFD Bidirectional Forwarding Detection </t>
<t>CC Continuity Check</t>
<!--<t>GTSM Generalized TTL Security Mechanism</t>-->
<t>p2p Point-to-point</t>
<t>MSN Multicast Service Node</t>
<t>NVE Network Virtualization Endpoint</t>
<t>VFI Virtual Forwarding Instance</t>
<t>VM Virtual Machine</t>
<t>VNI VXLAN Network Identifier (or VXLAN Segment ID)</t>
<t>VTEP VXLAN Tunnel End Point</t>
<t>VXLAN Virtual eXtensible Local Area Network</t>
</section>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Deployment"> <name>Deployment</name>
<t> <t>
<xref target="ref-vxlan-fig"/> illustrates the scenario with two servers, ea <xref target="ref-vxlan-fig" format="default"/> illustrates a scenario with
ch of them hosting two VMs. two servers: each hosting two VMs.
The servers host VTEPs that terminate two VXLAN tunnels with VXLAN Networ The servers host VTEPs that terminate two VXLAN tunnels with VNI number 1
k Identifier (VNI) number 100 00
and 200 respectively. Separate BFD sessions can be and 200, respectively. Separate BFD sessions can be
established between the VTEPs (IP1 and IP2) for monitoring established between the VTEPs (IP1 and IP2) for monitoring
each of the VXLAN tunnels (VNI 100 and 200). Using a BFD session to monit or a set of VXLAN VNIs each of the VXLAN tunnels (VNI 100 and 200). Using a BFD session to monit or a set of VXLAN VNIs
between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration. between the same pair of VTEPs might help to detect and localize problems caused by misconfiguration.
An implementation that supports this specification MUST An implementation that supports this specification <bcp14>MUST</bcp14>
be able to control the number of BFD sessions be able to control the number of BFD sessions
that can be created between the same pair of VTEPs. that can be created between the same pair of VTEPs.
This method is applicable whether the VTEP is a virtual or physical devi ce. This method is applicable whether the VTEP is a virtual or physical devi ce.
</t> </t>
<t keepWithNext="true"/>
<figure anchor="ref-vxlan-fig">
<name>Reference VXLAN Domain</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
<figure anchor="ref-vxlan-fig" align="left" title="Reference VXLAN Domain"
>
<preamble/>
<artwork align="left">
<![CDATA[
+------------+-------------+ +------------+-------------+
| Server 1 | | Server 1 |
| +----+----+ +----+----+ | | +----+----+ +----+----+ |
| |VM1-1 | |VM1-2 | | | |VM1-1 | |VM1-2 | |
| |VNI 100 | |VNI 200 | | | |VNI 100 | |VNI 200 | |
| | | | | | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| VTEP (IP1) | | VTEP (IP1) |
+--------------------------+ +--------------------------+
| |
skipping to change at line 245 skipping to change at line 187
| |
+------------+-------------+ +------------+-------------+
| VTEP (IP2) | | VTEP (IP2) |
| +----+----+ +----+----+ | | +----+----+ +----+----+ |
| |VM2-1 | |VM2-2 | | | |VM2-1 | |VM2-2 | |
| |VNI 100 | |VNI 200 | | | |VNI 100 | |VNI 200 | |
| | | | | | | | | | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| Server 2 | | Server 2 |
+--------------------------+ +--------------------------+
]]>
</artwork>
</figure>
<t> ]]></artwork>
At the same time, a service layer BFD session may be used between the ten </figure>
ants of VTEPs IP1 and IP2 <t>
to provide end-to-end fault management (this use case is outside the scop At the same time, a service-layer BFD session may be used between the
e of this document). In tenants of VTEPs IP1 and IP2
such a case, for VTEPs, the BFD Control packets of that session are indis to provide end-to-end fault management; this use case is outside the
tinguishable from data packets. scope of this document. In
</t> such a case, for VTEPs, the BFD Control packets of that session are
<t> indistinguishable from data packets.
For BFD Control packets encapsulated in VXLAN (<xref target="vxlan-bfd-en </t>
cap-fig"/>), <t>
For BFD Control packets encapsulated in VXLAN (<xref target="vxlan-bfd-en
cap-fig" format="default"/>),
the inner destination IP address the inner destination IP address
SHOULD be set to one of the loopback addresses from <bcp14>SHOULD</bcp14> be set to one of the loopback addresses from
127/8 range for IPv4 or to one of IPv4-mapped IPv6 loopback addresses fro m ::ffff:127.0.0.0/104 range for IPv6. 127/8 range for IPv4 or to one of IPv4-mapped IPv6 loopback addresses fro m ::ffff:127.0.0.0/104 range for IPv6.
</t> </t>
</section> </section>
<section anchor="management-vni-sec" numbered="true" toc="default">
<section anchor="management-vni-sec" title="Use of the Management VNI"> <name>Use of the Management VNI</name>
<t> <t>
In most cases, a single BFD session is sufficient for the given VTEP to monitor In most cases, a single BFD session is sufficient for the given VTEP to monitor
the reachability of a remote VTEP, regardless of the number of VNIs. the reachability of a remote VTEP, regardless of the number of VNIs.
BFD control messages MUST be sent using the Management VNI which acts BFD control messages <bcp14>MUST</bcp14> be sent using the Management VNI, w
as the as control and management channel between VTEPs. hich acts
An implementation MAY support operating BFD on another as the control and management channel between VTEPs.
(non-Management) VNI although the implications of this are outside An implementation <bcp14>MAY</bcp14> support operating BFD on another
(non-Management) VNI, although the implications of this are outside
the scope of this document. The selection of the VNI number the scope of this document. The selection of the VNI number
of the Management VNI MUST be controlled through a management plane. An implemen of the Management VNI <bcp14>MUST</bcp14> be controlled through a management pla
tation MAY use VNI number 1 as ne. An implementation <bcp14>MAY</bcp14> use VNI number 1 as
the default value for the Management VNI. All VXLAN packets received on the Mana the default value for the Management VNI. All VXLAN packets received on the Mana
gement VNI MUST be processed locally gement VNI <bcp14>MUST</bcp14> be processed locally
and MUST NOT be forwarded to a tenant. and <bcp14>MUST NOT</bcp14> be forwarded to a tenant.
</t> </t>
</section> </section>
<section anchor="bfd-transmit-vxlan-sec" numbered="true" toc="default">
<section anchor="bfd-transmit-vxlan-sec" title="BFD Packet Transmission o <name>BFD Packet Transmission over VXLAN Tunnel</name>
ver VXLAN Tunnel"> <t>
<t> BFD packets <bcp14>MUST</bcp14> be encapsulated and sent to a remote VTEP
BFD packets MUST be encapsulated and sent to a remote VTEP as explained i as explained in this section.
n this section. Implementations <bcp14>SHOULD</bcp14> ensure that the BFD packets follow
Implementations SHOULD ensure that the BFD packets follow the same the same
forwarding path as VXLAN data packets within the sender system. forwarding path as VXLAN data packets within the sender system.
</t> </t>
<t>
<!-- BFD packets are encapsulated in VXLAN as described below.
<section title="BFD Packet Encapsulation in VXLAN" anchor="encap" The VXLAN packet format is defined in
> <xref target="RFC7348" sectionFormat="of" section="5"/>.
--> The value in the VNI field of the VXLAN header <bcp14>MUST</bcp14>
<t> be set to the value selected as the Management VNI.
BFD packets are encapsulated in VXLAN as described below. The outer IP/UDP and VXLAN headers <bcp14>MUST</bcp14>
The VXLAN packet format is defined in Section 5 of <xref be encoded by the sender, as defined in <xref target="RFC7348" format="def
target="RFC7348"/>. ault"/>.</t>
The value in the VNI field of the VXLAN header MUST
be set to the value selected as the Management VNI.
The Outer IP/UDP and VXLAN headers MUST
be encoded by the sender as defined in <xref targ
et="RFC7348"/>.</t>
<t> <figure anchor="vxlan-bfd-encap-fig">
<figure align="left" anchor="vxlan-bfd-encap-fig" title="VXLAN Encapsu <name>VXLAN Encapsulation of BFD Control Packet</name>
lation of BFD Control Packet"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![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 336 skipping to change at line 277
~ Inner UDP Header ~ ~ Inner UDP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ BFD Control Packet ~ ~ BFD Control Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Ethernet FCS | | Outer Ethernet FCS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>
The BFD packet <bcp14>MUST</bcp14> be carried inside the inner Ethernet f
<t> rame of the VXLAN packet.
The BFD packet MUST be carried inside the inner Ethernet frame The choice of destination Media Access Control (MAC) and destination
of the VXLAN packet. IP addresses for the inner Ethernet frame <bcp14>MUST</bcp14>
The choice of Destination MAC and Destination IP addresses for ensure that the BFD Control packet is not forwarded to a tenant but is pr
the inner Ethernet frame MUST ocessed locally at the remote VTEP.
ensure that the BFD Control packet is not forwarded to a tenan The inner Ethernet frame carrying the BFD Control packet has the followin
t but is processed locally at the remote VTEP. g format:
The inner Ethernet frame carrying the BFD Control packet- has </t>
the following format: <dl newline="true">
<list>
<t> Ethernet Header:
<list style="hanging">
<t>Destination MAC: A Management VNI,
which does not have any tenants, will
have no dedicated MAC address for decapsulated traffic.&#160; The value (TBD1)
SHOULD be used in this field.</t>
<t>Source MAC: MAC address associated
with the originating VTEP.</t>
<t>Ethertype: is set to 0x0800 if the
inner IP header is IPv4, and is set to 0x86DD if the inner IP header is IPv6.</t
>
</list>
</t>
<t>IP header:
<list style="hanging">
<t>Destination IP: IP address MUST NOT
be of one of tenant's IP addresses.
The IP address SHOULD be selected
from the range 127/8 for IPv4, for IPv
6 - from the range ::ffff:127.0.0.0/104.
Alternatively, the destination IP addr
ess MAY be set to VTEP's IP address.</t>
<t>Source IP: IP address of the origin
ating VTEP.</t>
<t>TTL or Hop Limit: MUST be set to 25
5 in accordance with <xref target="RFC5881"/>.
</t>
<!--
<t>[Ed.Note]:Use of inner source and d
estination IP
addresses needs more discussion by the
WG.</t>
-->
</list>
</t>
<t> <dt>Ethernet Header:</dt>
The fields of the UDP header and the BFD Control packet are en <dd>
coded as specified <dl newline="false" spacing="normal">
in <xref target="RFC5881"/>. <dt>Destination MAC:</dt><dd>A Management VNI, which does not have
</t> any tenants, will have no dedicated MAC address for decapsulated
traffic.&nbsp; The value 00-52-02 <bcp14>SHOULD</bcp14> be used in
this field.</dd>
<dt>Source MAC:</dt><dd>MAC address associated with the originating
VTEP.</dd>
<dt>Ethertype:</dt><dd>This is set to 0x0800 if the inner IP header
is
IPv4 and set to 0x86DD if the inner IP header is IPv6.</dd>
</dl>
</dd>
</list></t> <dt>IP header:</dt>
<!-- <dd>
</section> <dl newline="false" spacing="normal">
--> <dt>Destination IP:</dt><dd>This IP address <bcp14>MUST
<!-- NOT</bcp14> be of one of tenant's IP addresses.
<section title="BFD Packet Encapsulation in VXLAN-GPE" anchor="en The IP address <bcp14>SHOULD</bcp14> be selected
cap-gpe"> from the range 127/8 for IPv4 and from the range
<t> If VTEP suppors Generic Protocol Extension (GPE) head ::ffff:127.0.0.0/104 for IPv6.
er capabilities then VXLAN-GPE MAY be used. Alternatively, the destination IP address <bcp14>MAY</bcp14> be set t
The VXLAN-GPE header MUST be encoded as per Section 3.3 o o VTEP's IP address.</dd>
f <xref target="I-D.ietf-nvo3-vxlan-gpe"/>. Next Protocol Field in <dt>Source IP:</dt><dd>IP address of the originating VTEP.</dd>
VXLAN-GPE header MAY be set to indicate IPv4or IPv6 paylo <dt>TTL or Hop Limit:</dt><dd><bcp14>MUST</bcp14> be set to 255, in
ad. Then BFD control packet MUST be encapsulated accordance with <xref target="RFC5881" format="default"/>.</dd>
using IP/UDP format per <xref target="RFC5881"/>. Next Pr </dl>
otocol Field in VXLAN-GPE header MAY be set to indicate </dd>
that payload is OAM packet. Then OOAM Common Header </dl>
<xref target="I-D.ooamdt-rtgwg-ooam-header"/> immediately
follows the VXLAN-GPE header and
defines encapsulation of the BFD control packet. Theencap
sulation MAY use IP/UDP form or
PW-ACH encapsulation <xref target="RFC5885"/>.</t>
<t>Details of how the VTEP is instructed to choose VXLAN <t>
or GPE header are outside the scope of this document.</t> The destination UDP port is set to 3784 and the fields of the
BFD Control packet are encoded as specified in <xref target="RFC5881" format="de
fault"/>.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Reception of BFD Packet from VXLAN Tunnel"> <name>Reception of BFD Packet from VXLAN Tunnel</name>
<t> <t>
Once a packet is received, the VTEP MUST validate the packet. Once a packet is received, the VTEP <bcp14>MUST</bcp14> validate the pac
If the packet is received on the management VNI and is identified as BFD ket.
control packet addressed to the VTEP, If the packet is received on the Management VNI and is identified as a
and then the packet can be processed further. Processing of BFD control BFD Control packet addressed to the VTEP,
packets received on non-management VNI then the packet can be processed further. Processing of BFD Control
packets received on a non-Management VNI
is outside the scope of this specification. is outside the scope of this specification.
</t> </t>
<t>
<t>
The received packet's inner IP payload is then validated according to The received packet's inner IP payload is then validated according to
Sections 4 and 5 in <xref target="RFC5881"/>. Sections <xref target="RFC5881" sectionFormat="bare" section="4" />
</t> and <xref target="RFC5881" sectionFormat="bare" section="5"/> in <xref ta
rget="RFC5881" format="default"/>.
<!-- </t>
<t> To ensure that the BFD session monitors the intended VXLAN Ne
twork Identifier (VNI)
in a remote VTEP, a lookup SHOULD be performed with the MAC-DA an
d VNI as key in the
Virtual Forwarding Instance (VFI) table of the originating/termin
ating VTEP to exercise the VFI associated with the VNI.</t>
-->
<!--
<section title="Demultiplexing of the BFD Packet">
<t>Demultiplexing of IP BFD packet has been defined in Section 3 of <xre
f target="RFC5881"/>.
Since multiple BFD sessions may be running between two VTEPs, there
needs to be a mechanism for demultiplexing received BFD packets to
the proper session. For demultiplexing packets with
Your Discriminator equal to 0, a BFD session MUST be identified using
the logical link over which the BFD Control packet is received.
In the case of VXLAN, the VNI number
identifies that logical link.
If BFD packet is received with non-zero Your Discriminator, then the BFD s
ession MUST
be demultiplexed only with Your Discriminator as the key.</t>
</section>
-->
</section> </section>
<!-- <section numbered="true" toc="default">
<section title="Reception of BFD packet from VXLAN-GPE Tunnel"> <name>Echo BFD</name>
<t>TBD</t> <t>Support for echo BFD is outside the scope of this document.</t>
<section title="Demultiplexing of the BFD packet">
<t>TBD</t>
</section>
</section>
<section title="Echo BFD">
<t>Support for echo BFD is outside the scope of this document.</t>
</section> </section>
<section anchor="iana-consideration" numbered="true" toc="default">
<section anchor="iana-consideration" title="IANA Considerations"> <name>IANA Considerations</name>
<t> <t>
IANA is requested to assign a single MAC address to the value TBD1 from the IANA has assigned a single MAC address of the value 00-52-02 from the "Unassigne
"IANA Unicast 48-bit MAC Address" registry from the "Unassigned (small allocatio d (small allocations)" block of the "IANA Unicast 48-bit MAC Addresses" registry
ns)" block. as follows:
The Usage field will be "BFD for VXLAN" with a Reference field of this document. the "Usage" field is "BFD for VXLAN". The "Reference" is this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security Considerations"> <name>Security Considerations</name>
<!--
<t>
The document requires setting the inner IP TTL or Hop Limit to 1, which
could be used as a DDoS attack vector.
Thus the implementation MUST have throttling in place to control the rat
e of BFD Control packets sent to the control plane.
On the other hand, over-aggressive throttling of BFD Control packets may
become the cause of the inability to form and maintain
BFD session at scale. Hence, throttling of BFD Control packets SHOULD be
adjusted to permit BFD to work according to its
procedures.
</t>
-->
<t> <t>
Security issues discussed in <xref target="RFC5880"/>, <xref target="RFC Security issues discussed in <xref target="RFC5880"
5881"/>, and <xref target="RFC7348"/> format="default"/>, <xref target="RFC5881" format="default"/>, and
<xref target="RFC7348" format="default"/>
apply to this document. apply to this document.
</t> </t>
<t> <t>
This document recommends using an address from the internal host loopbac
This document recommends using an address from the Internal host loopbac k addresses
k addresses 127/8 range for IPv4, or an IP4-mapped IPv6 loopback address from the
127/8 range for IPv4 or an IP4-mapped IPv6 loopback address from ::ffff:1 ::ffff:127.0.0.0/104 range for IPv6,
27.0.0.0/104 range for IPv6
as the destination IP address in the inner IP header. Using such an addr ess prevents as the destination IP address in the inner IP header. Using such an addr ess prevents
the forwarding of the encapsulated BFD control message by a transient no the forwarding of the encapsulated BFD control message by a transient
de in case the VXLAN tunnel is broken as node, in case the VXLAN tunnel is broken, in
according to <xref target="RFC1812"/>. accordance with <xref target="RFC1812" format="default"/>.
<list> </t>
<t> <aside>
A router SHOULD NOT forward, except over a loopback interface, any <t>
A router <bcp14>SHOULD NOT</bcp14> forward, except over a loopback interfa
ce, any
packet that has a destination address on network 127. A router packet that has a destination address on network 127. A router
MAY have a switch that allows the network manager to disable these <bcp14>MAY</bcp14> have a switch that allows the network manager to disabl
checks. If such a switch is provided, it MUST default to e these
performing the checks. checks. If such a switch is provided, it <bcp14>MUST</bcp14> default to
</t> performing the checks.</t>
</list> </aside>
<t>
The use of IPv4-mapped IPv6 addresses The use of IPv4-mapped IPv6 addresses
has the same property as using the IPv4 network 127/8, moreover, the IPv has the same property as using the IPv4 network 127/8. Moreover, the IPv
4-mapped 4-mapped
IPv6 addresses prefix is not advertised in any routing protocol.</t> IPv6 addresses' prefix is not advertised in any routing protocol.</t>
<t>
<t>
If the implementation supports establishing multiple BFD sessions If the implementation supports establishing multiple BFD sessions
between the same pair of VTEPs, there SHOULD be a mechanism between the same pair of VTEPs, there <bcp14>SHOULD</bcp14> be a mechani sm
to control the maximum number of such sessions that can be active to control the maximum number of such sessions that can be active
at the same time. at the same time.
</t> </t>
</section>
<section title="Contributors">
<t>
<figure>
<artwork>
<![CDATA[
Reshad Rahman
rrahman@cisco.com
Cisco
]]>
</artwork>
</figure>
</t>
</section>
<section title="Acknowledgments">
<t>Authors would like to thank Jeff Haas of Juniper Networks for his review
s and feedback on this material.</t>
<t>Authors would also like to thank Nobo Akiya, Marc Binderberger, Shahr
am Davari,
Donald E. Eastlake 3rd, Anoop Ghanwani, Dinesh Dutt, Joel Halpern, and C
arlos Pignataro for the extensive reviews
and the most detailed and constructive comments.</t>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split into informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.5880"?>
<?rfc include="reference.RFC.5881"?>
<?rfc include="reference.RFC.7348"?> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<?rfc include="reference.RFC.8174"?> <references>
<?rfc include="reference.RFC.1812"?> <name>Normative References</name>
<!-- <?rfc include="reference.RFC.5082"?> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- FC.5880.xml"/>
<?rfc include="reference.I-D.ietf-bfd-seamless-base"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
--> FC.5881.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.I-D.ashwood-nvo3-operational-requirement"?> FC.7348.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?> FC.2119.xml"/>
--> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<!-- FC.8174.xml"/>
<?rfc include="reference.I-D.ietf-bfd-multipoint"?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
--> FC.1812.xml"/>
<!-- </references>
<?rfc include="reference.I-D.ooamdt-rtgwg-ooam-header"?> <references>
--> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8293.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8365.xml"/>
</references>
</references> </references>
<references title="Informational References"> <section numbered="false" toc="default">
<name>Acknowledgments</name>
<?rfc include="reference.RFC.8293"?> <t>The authors would like to thank <contact fullname="Jeff Haas"/> of
<?rfc include="reference.RFC.8365"?> Juniper Networks for his reviews and feedback on this material.</t>
<t>The authors would also like to thank <contact fullname="Nobo Akiya"/>,
<contact fullname="Marc Binderberger"/>, <contact fullname="Shahram Davari
"/>,
<contact fullname="Donald E. Eastlake 3rd"/>, <contact
fullname="Anoop Ghanwani"/>, <contact fullname="Dinesh Dutt"/>,
<contact fullname="Joel Halpern"/>, and <contact fullname="Carlos
Pignataro"/> for the extensive reviews
and the most detailed and constructive comments.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Reshad Rahman">
<organization>Cisco</organization>
<address>
<email>rrahman@cisco.com</email>
</address>
</contact>
</section>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 63 change blocks. 
458 lines changed or deleted 309 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/