On 7/16/14 4:49 PM, "Dino Farinacci" <[email protected]> wrote:
>> VXLAN-gpe is as aligned to existing VXLAN as much as the existing RFC
>>provides guidance for. I.e. given the anticipated interpretations, with
>>proper scrutiny of what is allowed , VXLAN-gpe is attempting to allow
>>for best backwards interoperability on the existing UDP 4789 and offer
>>best prospects for carrying the additional headers/metadata. This leads
>>to the need for new UDP port for new formats
>
>But for what features?
>
>If chips can change to support L3 overlays with VXLAN, which they will
>have to do L3 header parsing as well as doing L3 lookups during
>recirculation, then they could just end of doing LISP. Note, the LISP
>header is exactly the same as the VXLAN header so the effort is the same.
>Therefore there is no point in having a P-bit and a next-header field.
>
>As for NSH, it SHOULD have its own UDP header because you may want to use
>it natively and NOT encapsulate.
SK> Native use over UDP is part of NSH design.
Surendra.
>
>Again, people will find that all the parameters in NSH are really not
>necessary and just creates more things the network adminstrator has to
>manage and track. A service will be defined by a 5-tuple and in many
>cases, all packets may have to travel across a service chain.
>
>Dino
>
>>
>> Thx
>>
>> Uri ("Oo-Ree")
>> C: (949)-378-7568
>>
>>
>> -----Original Message-----
>> From: nvo3 [mailto:[email protected]] On Behalf Of Lucy yong
>> Sent: Wednesday, July 16, 2014 4:00 PM
>> To: Fabio Maino; Dino Farinacci
>> Cc: [email protected]
>> Subject: Re: [nvo3] Comments on
>>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
>>
>> If GPE is the VXLAN evolution, why it request a new UDP port? If GPE is
>>a new protocol, why it has to align with VXLAN format?
>>
>> Lucy
>>
>> -----Original Message-----
>> From: nvo3 [mailto:[email protected]] On Behalf Of Fabio Maino
>> Sent: Wednesday, July 16, 2014 5:47 PM
>> To: Dino Farinacci
>> Cc: [email protected]
>> Subject: Re: [nvo3] Comments on
>>http://tools.ietf.org/html/draft-quinn-vxlan-gpe-03
>>
>> Dino,
>> GPE is not changing VXLAN nor LISP, as today's implementations cannot
>>be changed. GPE is proposing a converged extension of both protocols
>>that add some new features that, I believe, are needed.
>>
>> All of VXLAN features are supported in GPE.
>>
>> In the case of LISP, unfortunately, two features (nonce and
>> map-versioning) could not be accommodated in GPE. This is not very
>>different than any of today's LISP implementations that may decide to
>>not support those two features (for whatever reason: cost, complexity,
>>use cases addressed by the implementation... independently from GPE).
>>
>> What GPE is trying to do is to simplify next generation implementations
>>by keeping GPE as close as possible to the existing encapsulations,
>>adding on top of those. I maintain that an implementation supporting
>>GPE, LISP and VXLAN will be more cost effective than one that supports
>>VXLAN, LISP and a clean slate protocol, and may have better chances of
>>being deployed.
>>
>> Fabio
>>
>>
>> On 7/16/14, 1:05 PM, Dino Farinacci wrote:
>>> Well, if you want to really care about customers, creating all these
>>>variations is not doing justice to them. If you want less combinations,
>>>you keep VXLAN the way it is right now, with no changes. You keep LISP
>>>the way it is right now with no changes. You get L2 and L3 overlays
>>>with a unified pull control-plane in draft-maino-nv03-lisp-cp
>>>(preaching to the author ;-) or use BGP as an alternative push
>>>control-plane.
>>>
>>> As for NSH, you create a new header because it is completely new
>>>requirement and has not be deployed anywhere. Since it is brand new,
>>>you need new hardware and code to be developed to support it. So
>>>changing VXLAN and LISP to support NSH doesn't make sense because you
>>>inject change in 3 places rather than in 1 new place, creating more
>>>protocol machinery, complexity, and combinations that will frustrate
>>>customers (not to mention vendor call centers).
>>>
>>> Less entropy please,
>>> Dino
>>>
>>> On Jul 15, 2014, at 10:51 PM, Fabio Maino <[email protected]> wrote:
>>>
>>>> Dino,
>>>> I believe that using a format that can share as much as possible with
>>>>the two protocols deployed today will give a better chance to GPE to
>>>>be implemented, as vendors may want a cost effective way to migrate to
>>>>the new protocol while preserving compatibility with legacy
>>>>implementations.
>>>>
>>>> The fact that GPE provides a way to be extended, either with a shim
>>>>a-la NSH or making availabe more bits in the header for future
>>>>features, I think opens up to the addition of new features (explicit
>>>>service tagging, as an example) in a more organic way than trying to
>>>>use the few bits left in VXLAN or LISP.
>>>>
>>>> Unfortunately, in the LISP case, this comes to the expense of some
>>>>features that are in the current specification, but I believe those
>>>>same features can be mapped on a GPE+shim header, so a new
>>>>implementation would be able to provide the equivalent of those
>>>>features (e.g. nonce).
>>>>
>>>> It's hard to find the right balance between backward compatibility
>>>>and evolution of the encapsulation, but I believe GPE gets to a decent
>>>>compromise.
>>>>
>>>> Thanks,
>>>> Fabio
>>>>
>>>>
>>>>
>>>> On 7/15/14, 4:47 PM, Dino Farinacci wrote:
>>>>>>> Hi VXLAN-gpe authors,
>>>>>>>
>>>>>>> Abstract: technically this is not extending a VXLAN but defines a
>>>>>>> new protocol that looks similar to VXLAN (demonstrated by need for
>>>>>>> new UDP port assignment).
>>>>>> We are trying to balance re-use of the VXLAN format and the need to
>>>>>>support existing non-GPE hardware that might already be deployed.
>>>>>>We looked at using the same port, and the new one, and decided, at
>>>>>>this point that a new port is easier for migration but since the
>>>>>>packet format is essentially VXLAN to keep the VXLAN name.
>>>>> Paul, this design seems to be going in circles. If a new port is
>>>>>used, why not make the new port for VXLAN mean layer-3 protocols
>>>>>follow? Or better yet, have a demux field after the VXLAN header so
>>>>>you don't have to use VXLAN header bits. Because the P-bit is using a
>>>>>precious bit in the VXLAN/LISP header and the nonce field that can be
>>>>>used for other things (we have history that shows a nonce in the
>>>>>header is a cheap form of obscure security).
>>>>>
>>>>> If you do this then you have no compatibility problems with initial
>>>>>VXLAN and LISP implementations.
>>>>>
>>>>> And, most importantly, there will be less confusion in the
>>>>>marketplace.
>>>>>
>>>>> Dino
>>>>> _______________________________________________
>>>>> nvo3 mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>>> _______________________________________________
>>>> nvo3 mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>
>_______________________________________________
>nvo3 mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
