Re: [Int-area] Why combine IP-in-UDP with GUE?

[Tom Herbert <[e-mail]>]

On Wed, Apr 29, 2015 at 11:30 AM, Behcet Sarikaya
<[e-mail]> wrote:
> On Wed, Apr 29, 2015 at 12:06 PM, Tom Herbert <[e-mail]> wrote:
>> On Wed, Apr 29, 2015 at 9:09 AM, Behcet Sarikaya <[e-mail]> wrote:
>>> Hi Tom,
>>>
>>> On Wed, Apr 29, 2015 at 11:00 AM, Tom Herbert <[e-mail]> wrote:
>>>> On Wed, Apr 29, 2015 at 7:50 AM, Templin, Fred L
>>>> <[e-mail]> wrote:
>>>>> Hi Lucy,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lucy yong [mailto:[e-mail]]
>>>>>> Sent: Wednesday, April 29, 2015 7:48 AM
>>>>>> To: Templin, Fred L; [e-mail]; [e-mail]
>>>>>> Subject: RE: [Int-area] Why combine IP-in-UDP with GUE?
>>>>>>
>>>>>>
>>>>>> Getting back to our earlier discussion, IP-in-UDP and GUE are currently two half-solutions. Put them together and you get a whole
>>>>>> solution.
>>>>>> Keep them apart, and someone else is going to have to write a whole solution sometime down the line from now.
>>>>>> [Lucy] GUE can support IP payload. Don't know why you state that they are two half-solutions. Is the compression a mandatory
>>>>>> requirement here? I think that IP-in-UDP proposal as a compression version is better that use of first nibble. However we need clarify
>>>>>> what limitation and constraint the compression solution has.
>>>>>
>>>>> GUE is missing header compression, and IP-in-UDP is missing tunnel
>>>>> fragmentation. That is what I mean when I say that if combined you
>>>>> get a whole solution.
>>>>>
>>>> Adding this header compression just adds a whole bunch of complexity
>>>> to the protocol to save a grand total of four bytes for what is likely
>>>> a very narrow use case.
>>>
>>>>This is not applicable when GUE is used for
>>>> network virtualization,
>>>
>>>
>>> I don't think GUE is a replacement or even an improvement for VXLAN
>>> encapsulation.
>>>
>> All the arguments as to why VXLAN is insufficient in multi-tenant
>> deployments was made in nvo3. Please read those and the GUE drafts
>> (draft-hy-nvo3-gue-4-nvo-01,
>> draft-ietf-nvo3-gue-00,
>
> I read this draft, I could not see any such arguments. It just
> mentions VXLAN as a reference like other things.
>
> If true, it should explicitly address this issue.
> I am not sure if it can say more than what it is that is a generic
> encapsulation techniques that can be used in the data center to tunnel
> things.
>
> But VXLAN is designed to provide VM-to-VM communication.
> So the design criteria is completely different in these two techniques.
>
GUE has been adopted by nvo3 network virtualization data plane, along
with Geneve and VXLAN-GPE-- VXLAN has not. Again if you have comments
on that use of GUE please take them to nvo3. This thread is about a
generic modification to GUE without respect to the network
virtualization use case.

>> and
>> draft-hy-gue-4-secure-transport-01). If you have any comments or
>> questions take them to the nvo3 list.
>>
>>> While VXLAN is 1-N type of tunneling, GUE is 1-1.
>>>
>> I don't understand what this means.
>
> The key is in VM-to-VM communication. The other VM could be under any
> VTEP or NVE.
>
> Regards,
>
> Behcet
>>
>>> Regards,
>>>
>>> Behcet
>>>> we are encapsulating something other than IP,
>>>> we need OAM, or using any other feature of GUE. In my deployment, I
>>>> don't have any use case for that since minimally I will be using
>>>> remote checksum offload option because that does give a material
>>>> performance advantage.
>>>>
>>>> The premise of GUE is simple, it has a simple header that encapsulates
>>>> any IP protocol expressed by IP protocol number and allows optional
>>>> extensions and control packets-- let's keep it simple! If saving those
>>>> four bytes is really important in some deployment and GUE is still
>>>> needed in certain case, then just use GUE and IP-in-UDP in tandem.
>>>>
>>>> Tom
>>>>
>>>>> Thanks - Fred
>>>>> [e-mail]
>>>>>
>>>>>> Lucy
>>>>>>
>>>>>> Thanks - Fred
>>>>>> [e-mail]
>>>>>>
>>>>>> > However, if GUE payload is
>>>>>> > IP, it is OK to inspect the first nibble of the payload to determine IPv4 or IPv6 because this aligns with IP protocol.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Lucy
>>>>>> >
>>>>>> > - Stewart
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Int-area mailing list
>>>>>> > [e-mail]
>>>>>> > https://www.ietf.org/mailman/listinfo/int-area
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Int-area mailing list
>>>>>> > [e-mail]
>>>>>> > https://www.ietf.org/mailman/listinfo/int-area
>>>>>
>>>>> _______________________________________________
>>>>> Int-area mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/int-area
>>>>
>>>> _______________________________________________
>>>> Int-area mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/int-area