Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Thursday, April 30, 2015 1:09 PM > To: Templin, Fred L > Cc: Lucy yong; [email protected]; [email protected] > Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > > On Wed, Apr 29, 2015 at 10:20 AM, Templin, Fred L > <[email protected]> wrote: > > Hi Tom, > > > >> -----Original Message----- > >> From: Tom Herbert [mailto:[email protected]] > >> Sent: Wednesday, April 29, 2015 10:13 AM > >> To: Templin, Fred L > >> Cc: Lucy yong; [email protected]; [email protected] > >> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > >> > >> On Wed, Apr 29, 2015 at 9:28 AM, Templin, Fred L > >> <[email protected]> wrote: > >> > Hi Tom, > >> > > >> >> -----Original Message----- > >> >> From: Tom Herbert [mailto:[email protected]] > >> >> Sent: Wednesday, April 29, 2015 9:00 AM > >> >> To: Templin, Fred L > >> >> Cc: Lucy yong; [email protected]; [email protected] > >> >> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > >> >> > >> >> On Wed, Apr 29, 2015 at 7:50 AM, Templin, Fred L > >> >> <[email protected]> wrote: > >> >> > Hi Lucy, > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: Lucy yong [mailto:[email protected]] > >> >> >> Sent: Wednesday, April 29, 2015 7:48 AM > >> >> >> To: Templin, Fred L; [email protected]; [email protected] > >> >> >> 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.
If you can do this, please sign up AERO as a committed GUE user. Thanks - Fred [email protected] > > Thanks - Fred > > [email protected] > > > >> Tom > >> > >> > Thanks - Fred > >> > [email protected] > >> > > >> >> Tom > >> >> > >> >> > Thanks - Fred > >> >> > [email protected] > >> >> > > >> >> >> Lucy > >> >> >> > >> >> >> Thanks - Fred > >> >> >> [email protected] > >> >> >> > >> >> >> > 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 > >> >> >> > [email protected] > >> >> >> > https://www.ietf.org/mailman/listinfo/int-area > >> >> >> > > >> >> >> > _______________________________________________ > >> >> >> > Int-area mailing list > >> >> >> > [email protected] > >> >> >> > https://www.ietf.org/mailman/listinfo/int-area > >> >> > > >> >> > _______________________________________________ > >> >> > Int-area mailing list > >> >> > [email protected] > >> >> > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
