< draft-ietf-bfd-vxlan-07.txt | draft-ietf-bfd-vxlan-08.txt > | |||
---|---|---|---|---|
BFD S. Pallagatti, Ed. | BFD S. Pallagatti, Ed. | |||
Internet-Draft Rtbrick | Internet-Draft VMware | |||
Intended status: Standards Track S. Paragiri | Intended status: Standards Track S. Paragiri | |||
Expires: November 18, 2019 Individual Contributor | Expires: May 2, 2020 Individual Contributor | |||
V. Govindan | V. Govindan | |||
M. Mudigonda | M. Mudigonda | |||
Cisco | Cisco | |||
G. Mirsky | G. Mirsky | |||
ZTE Corp. | ZTE Corp. | |||
May 17, 2019 | October 30, 2019 | |||
BFD for VXLAN | BFD for VXLAN | |||
draft-ietf-bfd-vxlan-07 | draft-ietf-bfd-vxlan-08 | |||
Abstract | Abstract | |||
This document describes the use of the Bidirectional Forwarding | This document describes the use of the Bidirectional Forwarding | |||
Detection (BFD) protocol in point-to-point Virtual eXtensible Local | Detection (BFD) protocol in point-to-point Virtual eXtensible Local | |||
Area Network (VXLAN) tunnels forming up an overlay network. | Area Network (VXLAN) tunnels forming up an overlay network. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 38 ¶ | skipping to change at page 1, line 38 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on November 18, 2019. | This Internet-Draft will expire on May 2, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 17 ¶ | skipping to change at page 2, line 17 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 5 | 4. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 5 | |||
4.1. BFD Packet Encapsulation in VXLAN . . . . . . . . . . . . 6 | ||||
5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 7 | 5. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 7 | |||
5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 7 | 5.1. Demultiplexing of the BFD Packet . . . . . . . . . . . . 8 | |||
6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 8 | 6. Use of the Specific VNI . . . . . . . . . . . . . . . . . . . 8 | |||
7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
12.2. Informational References . . . . . . . . . . . . . . . . 9 | 12.2. Informational References . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
1. Introduction | 1. Introduction | |||
"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an | "Virtual eXtensible Local Area Network" (VXLAN) [RFC7348] provides an | |||
encapsulation scheme that allows building an overlay network by | encapsulation scheme that allows building an overlay network by | |||
decoupling the address space of the attached virtual hosts from that | decoupling the address space of the attached virtual hosts from that | |||
of the network. | of the network. | |||
One use of VXLAN is in data centers interconnecting virtual machines | One use of VXLAN is in data centers interconnecting virtual machines | |||
skipping to change at page 3, line 5 ¶ | skipping to change at page 3, line 4 ¶ | |||
Ethernet VPN [RFC8365]. | Ethernet VPN [RFC8365]. | |||
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 | hosts and refers to VMs and VXLAN Tunnel End Points (VTEPs) in | |||
hypervisors. However, the concepts are equally applicable to non- | hypervisors. However, the concepts are equally applicable to non- | |||
virtualized hosts attached to VTEPs in switches. | virtualized hosts attached to VTEPs in switches. | |||
In the absence of a router in the overlay, a VM can communicate with | In the absence of a router in the overlay, a VM can communicate with | |||
another VM only if they are on the same VXLAN segment. VMs are | another VM only if they are on the same VXLAN segment. VMs are | |||
unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. | unaware of VXLAN tunnels as a VXLAN tunnel is terminated on a VTEP. | |||
VTEPs are responsible for encapsulating and decapsulating frames | VTEPs are responsible for encapsulating and decapsulating frames | |||
exchanged among VMs. | exchanged among VMs. | |||
Ability to monitor path continuity, i.e., perform proactive | Ability to monitor path continuity, i.e., perform proactive | |||
continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is | continuity check (CC) for point-to-point (p2p) VXLAN tunnels, is | |||
important. The asynchronous mode of BFD, as defined in [RFC5880], | important. The asynchronous mode of BFD, as defined in [RFC5880], is | |||
can be used to monitor a p2p VXLAN tunnel. | used to monitor a p2p VXLAN tunnel. | |||
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 of [RFC8293]) resides behind an NVE, the mechanisms | Section 3.3 of [RFC8293]) resides behind a Network Virtualization | |||
described in this document apply and can, therefore, be used to test | Endpoint (NVE), the mechanisms described in this document apply and | |||
the connectivity from the source NVE to the MSN. | can, therefore, be used to test the connectivity from the source NVE | |||
to the MSN. | ||||
This document describes the use of Bidirectional Forwarding Detection | This document describes the use of Bidirectional Forwarding Detection | |||
(BFD) protocol to enable monitoring continuity of the path between | (BFD) protocol to enable monitoring continuity of the path between | |||
VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or | VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or | |||
availability of a replicator multicast service node. | availability of a replicator multicast service node. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
2.1. Terminology | 2.1. Terminology | |||
BFD Bidirectional Forwarding Detection | BFD Bidirectional Forwarding Detection | |||
CC Continuity Check | CC Continuity Check | |||
p2p Point-to-point | p2p Point-to-point | |||
MSN Multicast Service Node | MSN Multicast Service Node | |||
NVE Network Virtualization Endpoint | ||||
VFI Virtual Forwarding Instance | VFI Virtual Forwarding Instance | |||
VM Virtual Machine | VM Virtual Machine | |||
VNI VXLAN Network Identifier (or VXLAN Segment ID) | ||||
VTEP VXLAN Tunnel End Point | VTEP VXLAN Tunnel End Point | |||
VXLAN Virtual eXtensible Local Area Network | VXLAN Virtual eXtensible Local Area Network | |||
2.2. Requirements Language | 2.2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. Deployment | 3. Deployment | |||
Figure 1 illustrates the scenario with two servers, each of them | Figure 1 illustrates the scenario with two servers, each of them | |||
hosting two VMs. The servers host VTEPs that terminate two VXLAN | hosting two VMs. The servers host VTEPs that terminate two VXLAN | |||
tunnels with VNI number 100 and 200 respectively. Separate BFD | tunnels with VXLAN Network Identifier (VNI) number 100 and 200 | |||
sessions can be established between the VTEPs (IP1 and IP2) for | respectively. Separate BFD sessions can be established between the | |||
monitoring each of the VXLAN tunnels (VNI 100 and 200). An | VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100 | |||
implementation that supports this specification MUST be able to | and 200). An implementation that supports this specification MUST be | |||
control the number of BFD sessions that can be created between the | able to control the number of BFD sessions that can be created | |||
same pair of VTEPs. BFD packets intended for a Hypervisor VTEP MUST | between the same pair of VTEPs. BFD packets intended for a VTEP MUST | |||
NOT be forwarded to a VM as a VM may drop BFD packets leading to a | NOT be forwarded to a VM as a VM may drop BFD packets leading to a | |||
false negative. This method is applicable whether the VTEP is a | false negative. This method is applicable whether the VTEP is a | |||
virtual or physical device. | virtual or physical device. | |||
+------------+-------------+ | +------------+-------------+ | |||
| Server 1 | | | Server 1 | | |||
| | | ||||
| +----+----+ +----+----+ | | | +----+----+ +----+----+ | | |||
| |VM1-1 | |VM1-2 | | | | |VM1-1 | |VM1-2 | | | |||
| |VNI 100 | |VNI 200 | | | | |VNI 100 | |VNI 200 | | | |||
| | | | | | | | | | | | | | |||
| +---------+ +---------+ | | | +---------+ +---------+ | | |||
| Hypervisor VTEP (IP1) | | | VTEP (IP1) | | |||
+--------------------------+ | +--------------------------+ | |||
| | | | |||
| | ||||
| | ||||
| +-------------+ | | +-------------+ | |||
| | Layer 3 | | | | Layer 3 | | |||
|---| Network | | +---| Network | | |||
| | | ||||
+-------------+ | +-------------+ | |||
| | | | |||
| | ||||
+-----------+ | +-----------+ | |||
| | | | |||
| | ||||
+------------+-------------+ | +------------+-------------+ | |||
| Hypervisor VTEP (IP2) | | | VTEP (IP2) | | |||
| +----+----+ +----+----+ | | | +----+----+ +----+----+ | | |||
| |VM2-1 | |VM2-2 | | | | |VM2-1 | |VM2-2 | | | |||
| |VNI 100 | |VNI 200 | | | | |VNI 100 | |VNI 200 | | | |||
| | | | | | | | | | | | | | |||
| +---------+ +---------+ | | | +---------+ +---------+ | | |||
| Server 2 | | | Server 2 | | |||
+--------------------------+ | +--------------------------+ | |||
Figure 1: Reference VXLAN Domain | Figure 1: Reference VXLAN Domain | |||
At the same time, a service layer BFD session may be used between the | ||||
tenants of VTEPs IP1 and IP2 to provide end-to-end fault management. | ||||
In such case, for VTEPs BFD Control packets of that session are | ||||
indistinguishable from data packets. If end-to-end defect detection | ||||
is realized as the set of concatenated OAM domains, e.g., VM1-1 - IP1 | ||||
-- IP2 - VM2-1, then the BFD session over VXLAN between VTEPs SHOULD | ||||
follow the procedures described in Section 6.8.17 [RFC5880]. | ||||
As per Section 4, the inner destination IP address SHOULD be set to | ||||
one of the loopback addresses (127/8 range for IPv4 and | ||||
0:0:0:0:0:FFFF:7F00:0/104 range for IPv6). There could be a firewall | ||||
configured on VTEP to block loopback addresses if set as the | ||||
destination IP in the inner IP header. It is RECOMMENDED to allow | ||||
addresses from the loopback range through a firewall only if it is | ||||
used as the destination IP address in the inner IP header, and the | ||||
destination UDP port is set to 3784 [RFC5881]. | ||||
4. BFD Packet Transmission over VXLAN Tunnel | 4. BFD Packet Transmission over VXLAN Tunnel | |||
BFD packet MUST be encapsulated and sent to a remote VTEP as | BFD packet MUST be encapsulated and sent to a remote VTEP as | |||
explained in Section 4.1. Implementations SHOULD ensure that the BFD | explained in this section. Implementations SHOULD ensure that the | |||
packets follow the same lookup path as VXLAN data packets within the | BFD packets follow the same lookup path as VXLAN data packets within | |||
sender system. | the sender system. | |||
4.1. BFD Packet Encapsulation in VXLAN | ||||
BFD packets are encapsulated in VXLAN as described below. The VXLAN | BFD packets are encapsulated in VXLAN as described below. The VXLAN | |||
packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP | packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP | |||
and VXLAN headers MUST be encoded by the sender as defined in | and VXLAN headers MUST be encoded by the sender as defined in | |||
[RFC7348]. | [RFC7348]. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
skipping to change at page 6, line 44 ¶ | skipping to change at page 6, line 37 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ Inner IPvX Header ~ | ~ Inner IPvX Header ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ Inner UDP Header ~ | ~ Inner UDP Header ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
~ BFD Control Message ~ | ~ BFD Control Packet ~ | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| FCS | | | FCS | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: VXLAN Encapsulation of BFD Control Message | Figure 2: VXLAN Encapsulation of BFD Control Packet | |||
The BFD packet MUST be carried inside the inner MAC frame of the | The BFD packet MUST be carried inside the inner Ethernet frame of the | |||
VXLAN packet. The inner MAC frame carrying the BFD payload has the | VXLAN packet. The choice of Destination MAC and Destination IP | |||
following format: | addresses for the inner Ethernet frame MUST ensure that the BFD | |||
Control packet is not forwarded to a tenant but is processed locally | ||||
at the remote VTEP. The inner Ethernet frame carrying the BFD | ||||
Control packet- has the following format: | ||||
Ethernet Header: | Ethernet Header: | |||
Destination MAC: This MUST be the dedicated MAC TBA (Section 8) | Destination MAC: This MUST NOT be of one of tenant's MAC | |||
or the MAC address of the destination VTEP. The details of how | addresses. The destination MAC address MAY be the address | |||
the MAC address of the destination VTEP is obtained are outside | associated with the destination VTEP. The MAC address MAY be | |||
the scope of this document. | configured, or it MAY be learned via a control plane protocol. | |||
The details of how the MAC address is obtained are outside the | ||||
scope of this document. | ||||
Source MAC: MAC address of the originating VTEP | Source MAC: MAC address associated with the originating VTEP | |||
IP header: | IP header: | |||
Source IP: IP address of the originating VTEP. | 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 IPv6 - from the range | ||||
0:0:0:0:0:FFFF:7F00:0/104. Alternatively, the destination IP | ||||
address MAY be set to VTEP's IP address. | ||||
Destination IP: IP address of the terminating VTEP. | Source IP: IP address of the originating VTEP. | |||
TTL: MUST be set to 1 to ensure that the BFD packet is not | TTL or Hop Limit: MUST be set to 1 to ensure that the BFD | |||
routed within the L3 underlay network. | packet is not routed within the Layer 3 underlay network. This | |||
addresses the scenario when the inner IP destination address is | ||||
of VXLAN gateway and there is a router in underlay which | ||||
removes the VXLAN header, then it is possible to route the | ||||
packet as VXLAN gateway address is routable address. | ||||
The fields of the UDP header and the BFD control packet are | The fields of the UDP header and the BFD Control packet are | |||
encoded as specified in [RFC5881]. | encoded as specified in [RFC5881]. | |||
5. Reception of BFD Packet from VXLAN Tunnel | 5. Reception of BFD Packet from VXLAN Tunnel | |||
Once a packet is received, VTEP MUST validate the packet. If the | Once a packet is received, VTEP MUST validate the packet. If the | |||
Destination MAC of the inner MAC frame matches the dedicated MAC or | Destination MAC of the inner Ethernet frame matches one of the MAC | |||
the MAC address of the VTEP the packet MUST be processed further. | addresses associated with the VTEP the packet MUST be processed | |||
further. If the Destination MAC of the inner Ethernet frame doesn't | ||||
match any of VTEP's MAC addresses, then the processing of the | ||||
received VXLAN packet MUST follow the procedures described in | ||||
Section 4.1 [RFC7348]. | ||||
The UDP destination port and the TTL of the inner IP packet MUST be | The UDP destination port and the TTL of the inner IP packet MUST be | |||
validated to determine if the received packet can be processed by | validated to determine if the received packet can be processed by | |||
BFD. BFD packet with inner MAC set to VTEP or dedicated MAC address | BFD. BFD Control packets with unknown MAC address MUST NOT be | |||
MUST NOT be forwarded to VMs. | forwarded to VMs. | |||
5.1. Demultiplexing of the BFD Packet | 5.1. Demultiplexing of the BFD Packet | |||
Demultiplexing of IP BFD packet has been defined in Section 3 of | Demultiplexing of IP BFD packet has been defined in Section 3 of | |||
[RFC5881]. Since multiple BFD sessions may be running between two | [RFC5881]. Since multiple BFD sessions may be running between two | |||
VTEPs, there needs to be a mechanism for demultiplexing received BFD | VTEPs, there needs to be a mechanism for demultiplexing received BFD | |||
packets to the proper session. The procedure for demultiplexing | packets to the proper session. For demultiplexing packets with Your | |||
packets with Your Discriminator equal to 0 is different from | Discriminator equal to 0, a BFD session MUST be identified using the | |||
[RFC5880]. For such packets, the BFD session MUST be identified | logical link over which the BFD Control packet is received. In the | |||
using the inner headers, i.e., the source IP, the destination IP, and | case of VXLAN, the VNI number identifies that logical link. If BFD | |||
the source UDP port number present in the IP header carried by the | packet is received with non-zero Your Discriminator, then BFD session | |||
payload of the VXLAN encapsulated packet. The VNI of the packet | MUST be demultiplexed only with Your Discriminator as the key. | |||
SHOULD be used to derive interface-related information for | ||||
demultiplexing the packet. If BFD packet is received with non-zero | ||||
Your Discriminator, then BFD session MUST be demultiplexed only with | ||||
Your Discriminator as the key. | ||||
6. Use of the Specific VNI | 6. Use of the Specific VNI | |||
In most cases, a single BFD session is sufficient for the given VTEP | In most cases, a single BFD session is sufficient for the given VTEP | |||
to monitor the reachability of a remote VTEP, regardless of the | to monitor the reachability of a remote VTEP, regardless of the | |||
number of VNIs in common. When the single BFD session is used to | number of VNIs. When the single BFD session is used to monitor the | |||
monitor the reachability of the remote VTEP, an implementation SHOULD | reachability of the remote VTEP, an implementation SHOULD choose any | |||
choose any of the VNIs but MAY choose VNI = 0. | of the VNIs. An implementation MAY support the use of the Management | |||
VNI as control and management channel between VTEPs. The selection | ||||
of the VNI number of the Management VNI MUST be controlled through | ||||
management plane. An implementation MAY use VNI number 1 as the | ||||
default value for the Management VNI. All VXLAN packets received on | ||||
the Management VNI MUST be processed locally and MUST NOT be | ||||
forwarded to a tenant. | ||||
7. Echo BFD | 7. Echo BFD | |||
Support for echo BFD is outside the scope of this document. | Support for echo BFD is outside the scope of this document. | |||
8. IANA Considerations | 8. IANA Considerations | |||
IANA has assigned TBA as a dedicated MAC address from the IANA 48-bit | This specification has no IANA action requested. This section may be | |||
unicast MAC address registry to be used as the Destination MAC | deleted before the publication. | |||
address of the inner Ethernet of VXLAN when carrying BFD control | ||||
packets. | ||||
9. Security Considerations | 9. Security Considerations | |||
The document requires setting the inner IP TTL to 1, which could be | The document requires setting the inner IP TTL to 1, which could be | |||
used as a DDoS attack vector. Thus the implementation MUST have | used as a DDoS attack vector. Thus the implementation MUST have | |||
throttling in place to control the rate of BFD control packets sent | throttling in place to control the rate of BFD Control packets sent | |||
to the control plane. Throttling MAY be relaxed for BFD packets | to the control plane. On the other hand, over-aggressive throttling | |||
based on port number. | 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. | ||||
The implementation SHOULD have a reasonable upper bound on the number | If the implementation supports establishing multiple BFD sessions | |||
of BFD sessions that can be created between the same pair of VTEPs. | between the same pair of VTEPs, there SHOULD be a mechanism to | |||
control the maximum number of such sessions that can be active at the | ||||
same time. | ||||
Other than inner IP TTL set to 1 and limit the number of BFD sessions | Other than inner IP TTL set to 1 and limit the number of BFD sessions | |||
between the same pair of VTEPs, this specification does not raise any | between the same pair of VTEPs, this specification does not raise any | |||
additional security issues beyond those of the specifications | additional security issues beyond those of the specifications | |||
referred to in the list of normative references. | referred to in the list of normative references. | |||
10. Contributors | 10. Contributors | |||
Reshad Rahman | Reshad Rahman | |||
rrahman@cisco.com | rrahman@cisco.com | |||
skipping to change at page 10, line 14 ¶ | skipping to change at page 10, line 33 ¶ | |||
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., | [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., | |||
Uttaro, J., and W. Henderickx, "A Network Virtualization | Uttaro, J., and W. Henderickx, "A Network Virtualization | |||
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, | Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, | |||
DOI 10.17487/RFC8365, March 2018, | DOI 10.17487/RFC8365, March 2018, | |||
<https://www.rfc-editor.org/info/rfc8365>. | <https://www.rfc-editor.org/info/rfc8365>. | |||
Authors' Addresses | Authors' Addresses | |||
Santosh Pallagatti (editor) | Santosh Pallagatti (editor) | |||
Rtbrick | VMware | |||
Email: santosh.pallagatti@gmail.com | Email: santosh.pallagatti@gmail.com | |||
Sudarsan Paragiri | Sudarsan Paragiri | |||
Individual Contributor | Individual Contributor | |||
Email: sudarsan.225@gmail.com | Email: sudarsan.225@gmail.com | |||
Vengada Prasad Govindan | Vengada Prasad Govindan | |||
Cisco | Cisco | |||
End of changes. 41 change blocks. | ||||
76 lines changed or deleted | 112 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |