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

On Wed, Apr 29, 2015 at 10:20 AM, Templin, Fred L
<Fred.L.Templin@boeing.com> wrote:
> Hi Tom,
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:tom@herbertland.com]
>> Sent: Wednesday, April 29, 2015 10:13 AM
>> To: Templin, Fred L
>> Cc: Lucy yong; stbryant@cisco.com; int-area@ietf.org
>> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?
>>
>> On Wed, Apr 29, 2015 at 9:28 AM, Templin, Fred L
>> <Fred.L.Templin@boeing.com> wrote:
>> > Hi Tom,
>> >
>> >> -----Original Message-----
>> >> From: Tom Herbert [mailto:tom@herbertland.com]
>> >> Sent: Wednesday, April 29, 2015 9:00 AM
>> >> To: Templin, Fred L
>> >> Cc: Lucy yong; stbryant@cisco.com; int-area@ietf.org
>> >> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?
>> >>
>> >> On Wed, Apr 29, 2015 at 7:50 AM, Templin, Fred L
>> >> <Fred.L.Templin@boeing.com> wrote:
>> >> > Hi Lucy,
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Lucy yong [mailto:lucy.yong@huawei.com]
>> >> >> Sent: Wednesday, April 29, 2015 7:48 AM
>> >> >> To: Templin, Fred L; stbryant@cisco.com; int-area@ietf.org
>> >> >> 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
>> >
>> > The only additional requirement is to check the first nibble of the
>> > UDP-encapsulated payload.
>> >
>> >> 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, 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.
>> >
>> > What you have just done is spelled out specific use cases that
>> > require special-purpose solutions - that is not "generic".
>> >
>> >> 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.
>> >
>> > That would require two different UDP port numbers as opposed to
>> > checking the first nibble, which there was some earlier discussion
>> > about. If you want to call something "generic", then why not make it
>> > truly generic?
>> >
>>
>> It already is generic. Encapsulation of IPv4 and IPv6 is already
>> implemented and deployed. Including this optimization does not make
>> the protocol more generic.
>
> If it is deployed before the document is published as an RFC, then
> the deployed base would have to be updated to match the eventual
> RFC anyway.
>
>> Anyway, if you want to proceed with this please provide a specific
>> proposal on how do to it.
>
> Change the GUE header to treat the first nibble as a next header
> selector. 4 means IPv4, 6 means IPv6 and X means GUE.
>
Okay, thinking about this some more, I suppose we can actually support
direct IP encapsulation just by defining GUE version 0x1 to be direct
IP encapsulation. eg. 01 indicates IP encapsulation, 0100 0110 are
IPv4 and IPv6. This burns one version number and requires a subtle
change in the GUE draft to make it clear that the GUE version defines
defines everything after it, but it is forward compatible and doesn't
impact real GUE.

> Thanks - Fred
> fred.l.templin@boeing.com
>
>> Tom
>>
>> > Thanks - Fred
>> > fred.l.templin@boeing.com
>> >
>> >> Tom
>> >>
>> >> > Thanks - Fred
>> >> > fred.l.templin@boeing.com
>> >> >
>> >> >> Lucy
>> >> >>
>> >> >> Thanks - Fred
>> >> >> fred.l.templin@boeing.com
>> >> >>
>> >> >> > 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
>> >> >> > Int-area@ietf.org
>> >> >> > https://www.ietf.org/mailman/listinfo/int-area
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > Int-area mailing list
>> >> >> > Int-area@ietf.org
>> >> >> > https://www.ietf.org/mailman/listinfo/int-area
>> >> >
>> >> > _______________________________________________
>> >> > Int-area mailing list
>> >> > Int-area@ietf.org
>> >> > https://www.ietf.org/mailman/listinfo/int-area