On 1/18/16, 1:01 PM, "nvo3 on behalf of Tom Herbert" 
<[email protected]<mailto:[email protected]> on behalf of 
[email protected]<mailto:[email protected]>> wrote:

On Thu, Jan 14, 2016 at 12:27 PM,  
<[email protected]<mailto:[email protected]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Network Virtualization Overlays Working 
Group of the IETF.

         Title           : Geneve: Generic Network Virtualization Encapsulation
         Authors         : Jesse Gross
                           Ilango Ganga
         Filename        : draft-ietf-nvo3-geneve-01.txt
         Pages           : 26
         Date            : 2016-01-14

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.

A couple of comments...

The discussion of efficient implementation (section 2.2.1) seems vague
to me. For example, from the draft:

"As new functionality becomes sufficiently well defined to add to
endpoints, supporting options can be designed using ordering
restrictions and other techniques to ease parsing."

What are these ordering restrictions? Does this mean TLVs have (or
might eventually have) some defined ordering as to how they can appear
in the packet? Would this contradict section 4.3: "Option ordering is
not significant".

What are "other techniques to ease parsing"?

The draft is purposely trying to be agnostic to different implementations and 
obviously doesn’t want to mandate any specific techniques. There are several 
different types of software/devices and different architectures within those 
classes so it would be difficult to say what the “right” way to do things is 
today, let alone the future. However, given the number of implementations that 
either already exist or are emerging, it seems like this is a solvable problem.

Thanks for pointing out the possible inconsistency in the text – I’ll take a 
look at that.

Jesse
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to