On Wed, Apr 29, 2015 at 12:06 PM, Tom Herbert <[email protected]> wrote: > On Wed, Apr 29, 2015 at 9:09 AM, Behcet Sarikaya <[email protected]> > wrote: >> Hi Tom, >> >> On Wed, Apr 29, 2015 at 11:00 AM, Tom Herbert <[email protected]> wrote: >>> 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 >>> 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 >>>> [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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
