Re: [nvo3] Comments on Draft Geneve

["Bocci, Matthew (Matthew)" <[e-mail]>]

Dino

What we said was:

³It's fine to discuss solutions, indeed we need to discuss solutions and
how they meet the requirements and fit with the architecture as input to
the gap analysis draft. However, we are not yet in a position to adopt any
particular solution until we are rechartered to allow this."


Matthew


On 28/02/2014 22:42, "Dino Farinacci" <[e-mail]> wrote:

>So Larry, earlier in the month I asked the chairs if nvo3 was ready to
>talk and explore solutions. The answer was no.
>
>Then why is GENEVE on the agenda chairs?
>
>Dino
>
>> On Feb 28, 2014, at 1:57 PM, "Larry Kreeger (kreeger)"
>><[e-mail]> wrote:
>> 
>> I see that a healthy discussion has broken out around
>>draft-gross-geneve-00 which I see has a slot in the agenda for the NVO3
>>WG meeting on Monday.  Here are my thoughts.
>> 
>> I will be comparing Geneve to an encapsulation that is near and dear to
>>my heart, VXLAN.  When I do this, I see an encapsulation that is very
>>similar to VXLAN (e.g. uses UDP, uses a 24-bit segment identifier at the
>>same offset).  I see three things that Geneve adds beyond what is
>>available in draft-mahalingam-dutt-dcops-vxlan:
>> 
>> 1) The ability to encapsulate any protocol with an Ethertype (not just
>>Ethernet frames), by adding a Protocol Type field.  This is certainly
>>useful, and has already been covered in draft-quinn-vxlan-gpe as a
>>backward compatible extension to VXLAN by using a P bit flag to signal
>>its presence.  The field is even at the same offset as
>>draft-quinn-vxlan-gpe, but is missing the P bit for backwards
>>compatibility.
>> 
>> 2) The addition of an OAM bit to signal that the packet should be
>>processed by the tunnel endpoint and not forwarded to a tenant.  This
>>also seems useful, and seems identical in usage to the (IMO, poorly
>>named) "Router Alert" bit extension to VXLAN covered in (the currently
>>expired) draft-singh-nvo3-vxlan-router-alert.
>> 
>> 3) Last, but not least is the addition of a variable length options
>>field, which the draft suggests is used to carry metadata along with the
>>payload.  As mentioned by some others, IMO, the encapsulation transport
>>header is not the right place to define and carry metadata.
>>Architecturally, metadata should be defined independent of transport so
>>it can be carried inside of whatever transport is desired (e.g. VXLAN,
>>NVGRE, MPLSoGRE, L2TPV3 etc).  One example of an effort to do this is in
>>the Network Service Header draft (draft-quinn-sfc-nsh) being discussed
>>in the SFC WG.  I am guessing that since the Geneve options field is
>>optional, that the metadata it contains is not related to basic network
>>connectivity, but more to providing higher level network services (aka
>>Service Functions).  The Network Service Header contains two separate
>>parts, the service path (used to guide the packets through the service
>>chain) and context (metadata).  I can certainly see the context part of
>>N!
> SH being 
> used to carry metadata even if the service chain is null (all services
>are fully distributed to the tunnel endpoints).
>> 
>> In short, I don't see anything in Geneve that cannot be accomplished by
>>using the backward compatible extensions to VXLAN proposed in
>>draft-quinn-vxlan-gpe and draft-singh-nvo3-vxlan-router-alert, combined
>>with the addition of NSH.
>> 
>> When the current NVO3 WG charter was being written, there seemed to be
>>consensus that we have no shortage of encapsulation options, but what
>>was lacking was a standard control plane.  The Geneve draft seems to
>>turn that on its head by saying "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.".  I agree
>>with the first part of this, so why define a completely new,
>>non-backward compatible encapsulation?  I disagree with the second part,
>>since this is clearly the goal of the NVO3 WG.
>> 
>> I see that there is an agenda slot to discuss the Geneve draft, but I'm
>>not clear what the goals are of the authors within the IETF since the
>>draft name does not target it to any particular WG, and it is currently
>>marked as "Informational".  I would suggest that the authors consider
>>extending currently implemented encapsulations rather than starting from
>>scratch, e.g. by moving a few bits around in the first word of the
>>Geneve header, it could be made backward compatible with VXLAN.
>> 
>> Thanks, Larry
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3
>
>_______________________________________________
>nvo3 mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/nvo3