Re: [nvo3] Document shepherd review of draft-ietf-nvo3-geneve-09.txt

["Ganga, Ilango S" <[e-mail]>]

Hello Matthew and WG,

We have posted a new version of the document draft-ietf-nvo3-geneve-10.txt that addresses the comments from Document Shepherd review and an update to option class table.

https://mailarchive.ietf.org/arch/msg/nvo3/l2GVXhv4F4cVjqjC7-ek2VJJdf0

Thanks,
Ilango Ganga
Editor, Geneve

 
-----Original Message-----
From: nvo3 [mailto:[e-mail]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, February 27, 2019 5:57 AM
To: [e-mail]
Cc: NVO3 <[e-mail]>
Subject: [nvo3] Document shepherd review of draft-ietf-nvo3-geneve-09.txt

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 
MB> 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. 
MB> NVGRE 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 
MB> 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 
MB> '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 
MB> 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 
MB> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/nvo3