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? 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
