Authors,
As is customary, I have reviewed the latest version of the draft and it is
clear and well-written. Thank you.
I have inserted a few minor comments in the copy of the draft below (prefixed
by MB>). They are mostly editorial. Please treat these as you would other WG
last call comments.
Best regards
Matthew
=================
Network Working Group J. Gross, Ed.
Internet-Draft
Intended status: Standards Track I. Ganga, Ed.
Expires: August 26, 2019 Intel
T. Sridhar, Ed.
VMware
February 22, 2019
Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-09
Abstract
Network virtualization involves the cooperation of devices with a
wide variety of capabilities such as software and hardware tunnel
endpoints, transit fabrics, and centralized control clusters. As a
result of their role in tying together different elements in the
system, the requirements on tunnels are influenced by all of these
components. Flexibility is therefore the most important aspect of a
tunnel protocol if it is to keep pace with the evolution of the
system. This draft describes Geneve, a protocol designed to
recognize and accommodate these changing capabilities and needs.
MB> Suggest you rephrase the last sentence to "This document describes Geneve,
an
encapsulation protocol designed..."
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
[snip]
1. Introduction
Networking has long featured a variety of tunneling, tagging, and
other encapsulation mechanisms. However, the advent of network
virtualization has caused a surge of renewed interest and a
corresponding increase in the introduction of new protocols. The
large number of protocols in this space, ranging all the way from
VLANs [IEEE.802.1Q_2014] and MPLS [RFC3031] through the more recent
VXLAN [RFC7348], NVGRE [RFC7637], often leads to questions about the
MB> s/NVGRE/ and NVGRE
MB> Also, please expand less commonly used acronyms on first use e.g. NVGRE
MB> and LV2 (below)
need for new encapsulation formats and what it is about network
virtualization in particular that leads to their proliferation.
While many encapsulation protocols seek to simply partition the
underlay network or bridge between two domains, network
virtualization views the transit network as providing connectivity
between multiple components of a distributed system. In many ways
this system is similar to a chassis switch with the IP underlay
network playing the role of the backplane and tunnel endpoints on the
edge as line cards. When viewed in this light, the requirements
placed on the tunnel protocol are significantly different in terms of
the quantity of metadata necessary and the role of transit nodes.
Current work such as VL2 [VL2] and the NVO3 working group
MB> Replace 'NVO3 working group' with 'NVO3 dataplane requirements'
[I-D.ietf-nvo3-dataplane-requirements] have described some of the
properties that the data plane must have to support network
virtualization. However, one additional defining requirement is the
need to carry system state along with the packet data. The use of
some metadata is certainly not a foreign concept - nearly all
protocols used for virtualization have at least 24 bits of identifier
space as a way to partition between tenants. This is often described
as overcoming the limits of 12-bit VLANs, and when seen in that
context, or any context where it is a true tenant identifier, 16
million possible entries is a large number. However, the reality is
that the metadata is not exclusively used to identify tenants and
encoding other information quickly starts to crowd the space. In
fact, when compared to the tags used to exchange metadata between
line cards on a chassis switch, 24-bit identifiers start to look
quite small. There are nearly endless uses for this metadata,
ranging from storing input ports for simple security policies to
service based context for interposing advanced middleboxes.
[snip]
Geneve. Generic Network Virtualization Encapsulation. The tunnel
protocol described in this draft.
MB> Replace 'draft' with 'document' as it should soon be an RFC
LRO. Large Receive Offload. The receive-side equivalent function of
LSO, in which multiple protocol segments (primarily TCP) are
coalesced into larger data units.
[snip]
2. Design Requirements
Geneve is designed to support network virtualization use cases, where
tunnels are typically established to act as a backplane between the
virtual switches residing in hypervisors, physical switches, or
middleboxes or other appliances. An arbitrary IP network can be used
MB> Maybe add a reference to the NVO3 frameowork here (RFC 7365)
as an underlay although Clos networks composed using ECMP links are a
common choice to provide consistent bisectional bandwidth across all
connection points. Figure 1 shows an example of a hypervisor, top of
rack switch for connectivity to physical servers, and a WAN uplink
connected using Geneve tunnels over a simplified Clos network. These
tunnels are used to encapsulate and forward frames from the attached
components such as VMs or physical links.
[snip]
2.1. Control Plane Independence
Although some protocols for network virtualization have included a
control plane as part of the tunnel format specification (most
notably, the original VXLAN spec prescribed a multicast learning-
based control plane), these specifications have largely been treated
MB> Please provide a reference to the original VXLAN spec
as describing only the data format. The VXLAN packet format has
actually seen a wide variety of control planes built on top of it.
There is a clear advantage in settling on a data format: most of the
protocols are only superficially different and there is little
advantage in duplicating effort. However, the same cannot be said of
control planes, which are diverse in very fundamental ways. The case
for standardization is also less clear given the wide variety in
requirements, goals, and deployment scenarios.
Gross, et al. Expires August 26, 2019 [Page 6]
Internet-Draft Geneve Protocol February 2019
As a result of this reality, Geneve aims to be a pure tunnel format
MB> replace 'aims' with 'is'
specification that is capable of fulfilling the needs of many control
planes by explicitly not selecting any one of them. This
simultaneously promotes a shared data format and increases the
chances that it will not be obsoleted by future control plane
enhancements.
MB> 'The last part of this sentence might read better as "...and reduces the
chance of obsolescence by future control plane enhancements."
[snip]
2.2.1. Efficient Implementation
There is often a conflict between software flexibility and hardware
performance that is difficult to resolve. For a given set of
functionality, it is obviously desirable to maximize performance.
However, that does not mean new features that cannot be run at that
speed today should be disallowed. Therefore, for a protocol to be
MB> I am not sure what you mean by 'that speed'. Maybe rephrase this to 'a
desired speed', or do you mean 'line speed'?
efficiently implementable means that a set of common capabilities can
be reasonably handled across platforms along with a graceful
mechanism to handle more advanced features in the appropriate
situations.
[snip]
Options, if present in the packet, MUST be generated and terminated
by tunnel endpoints. Transit devices MAY be able to interpret the
MB> Do you mean that options, if present in the packet, MUST *only* be
generated
and terminated by tunnel endpoints. If so, please rephrase.
options, however, as non-terminating devices, transit devices do not
originate or terminate the Geneve packet, hence MUST NOT modify
Geneve headers and MUST NOT insert or delete options, which is the
responsibility of tunnel endpoints. The participation of transit
devices in interpreting options is OPTIONAL.
[snip]
4. Implementation and Deployment Considerations
4.1. Applicability Statement
Geneve is a network virtualization overlay encapsulation protocol
designed to establish tunnels between NVEs over an existing IP
network. It is intended for use in public or private data center
environments, for deploying multi-tenant overlay networks over an
existing IP underlay network.
Geneve is an UDP based encapsulation protocol transported over
MB> s/ an UDP / a UDP
existing IPv4 and IPv6 networks. Hence, as an UDP based protocol,
MB> s/ an UDP / a UDP
Geneve needs to meet the UDP usage guidelines as specified in
MB> Does 'needs' mean 'does' or MUST? Please clarify if this is a requirement
or a statement
of fact
[RFC8085]. The applicability of these guidelines are dependent on
the underlay IP network and the nature of Geneve payload protocol
(example TCP/IP, IP/Ethernet).
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
