< draft-xiao-nvo3-bfd-geneve-02.txt   draft-xiao-nvo3-bfd-geneve-03.txt >
NVO3 Working Group X. Min NVO3 Working Group X. Min
Internet-Draft G. Mirsky Internet-Draft G. Mirsky
Intended status: Standards Track ZTE Corp. Intended status: Standards Track ZTE Corp.
Expires: August 20, 2020 S. Pallagatti Expires: January 10, 2021 S. Pallagatti
VMware VMware
February 17, 2020 J. Tantsura
Apstra
July 9, 2020
BFD for Geneve BFD for Geneve
draft-xiao-nvo3-bfd-geneve-02 draft-xiao-nvo3-bfd-geneve-03
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 Generic Network Detection (BFD) protocol in point-to-point Generic Network
Virtualization Encapsulation (Geneve) tunnels used to make up an Virtualization Encapsulation (Geneve) tunnels used to make up an
overlay network. overlay network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 37
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 August 20, 2020. This Internet-Draft will expire on January 10, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3 3. BFD Packet Transmission over Geneve Tunnel . . . . . . . . . 3
3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header . . . 3 3.1. BFD Encapsulation With Inner Ethernet/IP/UDP Header . . . 3
3.2. BFD Encapsulation With Inner IP/UDP Header . . . . . . . 6 3.2. BFD Encapsulation With Inner IP/UDP Header . . . . . . . 6
4. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 8 4. Reception of BFD packet from Geneve Tunnel . . . . . . . . . 8
4.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 8 4.1. Demultiplexing of the BFD packet . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
"Generic Network Virtualization Encapsulation" (Geneve) "Generic Network Virtualization Encapsulation" (Geneve)
[I-D.ietf-nvo3-geneve] provides an encapsulation scheme that allows [I-D.ietf-nvo3-geneve] provides an encapsulation scheme that allows
building an overlay network by decoupling the address space of the building an overlay network by decoupling the address space of the
attached virtual hosts from that of the network. attached virtual hosts from that of the network.
This document describes the use of Bidirectional Forwarding Detection This document describes the use of Bidirectional Forwarding Detection
(BFD) protocol [RFC5880] to enable monitoring continuity of the path (BFD) protocol [RFC5880] to enable monitoring continuity of the path
between two Geneve tunnel endpoints, which may be NVE (Network between two Geneve tunnel endpoints, which may be NVE (Network
Virtualization Edge) or other device acting as a Geneve tunnel Virtualization Edge) or other device acting as a Geneve tunnel
endpoint. Specifically, the asynchronous mode of BFD, as defined in endpoint. Specifically, the asynchronous mode of BFD, as defined in
[RFC5880], is used to monitor a p2p Geneve tunnel, and support for [RFC5880], is used to monitor a p2p Geneve tunnel, and support for
echo BFD is outside the scope of this document. For simplicity, in BFD Echo function is outside the scope of this document. For
this document, NVE is used to represent Geneve tunnel endpoint, TS simplicity, in this document, NVE is used to represent Geneve tunnel
(Tenant System) is used to represent the physical or virtual device endpoint, TS (Tenant System) is used to represent the physical or
attached to a Geneve tunnel endpoint from the outside. VAP (Virtual virtual device attached to a Geneve tunnel endpoint from the outside.
Access Point) is the NVE side of the interface between the NVE and VAP (Virtual Access Point) is the NVE side of the interface between
the TS, and a VAP is a logical network port (virtual or physical) the NVE and the TS, and a VAP is a logical network port (virtual or
into a specific virtual network. For detailed definitions and physical) into a specific virtual network. For detailed definitions
descriptions of NVE, TS and VAP, please refer to [RFC7365] and and descriptions of NVE, TS and VAP, please refer to [RFC7365] and
[RFC8014]. [RFC8014].
The use cases and the deployment of BFD for Geneve are consistent The use cases and the deployment of BFD for Geneve are consistent
with what's described in Section 1 and 3 of [I-D.ietf-bfd-vxlan]. with what's described in Section 1 and 3 of [I-D.ietf-bfd-vxlan].
The major difference between Geneve and "Virtual eXtensible Local The major difference between Geneve and "Virtual eXtensible Local
Area Network" (VXLAN) [RFC7348] encapsulation is that Geneve supports Area Network" (VXLAN) [RFC7348] encapsulation is that Geneve supports
multi-protocol payload and variable length options. multi-protocol payload and variable length options.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Terminology 2.1. Abbreviations
BFD: Bidirectional Forwarding Detection BFD: Bidirectional Forwarding Detection
Geneve: Generic Network Virtualization Encapsulation Geneve: Generic Network Virtualization Encapsulation
NVE: Network Virtualization Edge NVE: Network Virtualization Edge
TS: Tenant System TS: Tenant System
VAP: Virtual Access Point VAP: Virtual Access Point
skipping to change at page 5, line 26 skipping to change at page 5, line 26
Source IP: IP address of a VAP of the originating NVE. If the Source IP: IP address of a VAP of the originating NVE. If the
VAP of the originating NVE has no IP address, then the IP VAP of the originating NVE has no IP address, then the IP
address of the originating NVE is used. address of the originating NVE is used.
Destination IP: IP address of a VAP of the terminating NVE. If 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 the VAP of the terminating NVE has no IP address, then the IP
address MUST be chosen from the 127/8 range for IPv4, and from address MUST be chosen from the 127/8 range for IPv4, and from
the ::ffff:127.0.0.0/104 range for IPv6. the ::ffff:127.0.0.0/104 range for IPv6.
TTL or Hop Limit: MUST be set to 255. TTL or Hop Limit: MUST be set to 255 in accordance with
[RFC5881].
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].
When the BFD packets are encapsulated in Geneve in this way, the When the BFD packets are encapsulated in Geneve in this way, the
Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set
below. below.
Opt Len field SHOULD be set to 0, which indicates there isn't any Opt Len field SHOULD be set to 0, which indicates there isn't any
variable length option. variable length option.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
The BFD packet MUST be carried inside the inner IP packet of the The BFD packet MUST be carried inside the inner IP packet of the
Geneve packet. The inner IP packet carrying the BFD Control packet Geneve packet. The inner IP packet carrying the BFD Control packet
has the following format: has the following format:
IP header: IP header:
Source IP: IP address of a VAP of the originating NVE. Source IP: IP address of a VAP of the originating NVE.
Destination IP: IP address of a VAP of the terminating NVE. Destination IP: IP address of a VAP of the terminating NVE.
TTL or Hop Limit: MUST be set to 255. TTL or Hop Limit: MUST be set to 255 in accordance with
[RFC5881].
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].
When the BFD packets are encapsulated in Geneve in this way, the When the BFD packets are encapsulated in Geneve in this way, the
Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set Geneve header defined in [I-D.ietf-nvo3-geneve] follows the value set
below. below.
Opt Len field SHOULD be set to 0, which indicates there isn't any Opt Len field SHOULD be set to 0, which indicates there isn't any
variable length option. variable length option.
skipping to change at page 10, line 4 skipping to change at page 10, line 6
7. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and The authors would like to acknowledge Reshad Rahman, Jeffrey Haas and
Matthew Bocci for their guidance on this work. Matthew Bocci for their guidance on this work.
The authors would like to acknowledge David Black for his explanation The authors would like to acknowledge David Black for his explanation
on the mapping relation between VAP and VNI. on the mapping relation between VAP and VNI.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-nvo3-geneve] [I-D.ietf-nvo3-geneve]
Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
Network Virtualization Encapsulation", draft-ietf- Network Virtualization Encapsulation", draft-ietf-
nvo3-geneve-14 (work in progress), September 2019. nvo3-geneve-16 (work in progress), March 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
skipping to change at page 10, line 44 skipping to change at page 10, line 47
<https://www.rfc-editor.org/info/rfc8014>. <https://www.rfc-editor.org/info/rfc8014>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-bfd-vxlan] [I-D.ietf-bfd-vxlan]
Networks, J., Paragiri, S., Govindan, V., Mudigonda, M., Networks, J., Paragiri, S., Govindan, V., Mudigonda, M.,
and G. Mirsky, "BFD for VXLAN", draft-ietf-bfd-vxlan-10 and G. Mirsky, "BFD for VXLAN", draft-ietf-bfd-vxlan-13
(work in progress), January 2020. (work in progress), July 2020.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<https://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
Authors' Addresses Authors' Addresses
skipping to change at line 453 skipping to change at page 11, line 32
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
USA USA
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Santosh Pallagatti Santosh Pallagatti
VMware VMware
Email: santosh.pallagatti@gmail.com Email: santosh.pallagatti@gmail.com
Jeff Tantsura
Apstra
Email: jefftant.ietf@gmail.com
 End of changes. 16 change blocks. 
21 lines changed or deleted 27 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/