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

[Behcet Sarikaya <[e-mail]>]

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.

> 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