Hi, Behcet. Just speaking as an individual: I understand the purpose of GPE as being the addition of a protocol field to VXLAN. It is not specifically a IPv4/v6 attribute, but more general. If you don't understand the general case of how or why v4 and v6 are multiplexed with the lower-layer protocol field then I don't think that's specifically germane to the nvo3 mailing list.
As for comparing GUE and VXLAN-GPE, that seems like a fair discussion to have. But I don't currently see any especially constructive way to do that. Cheers, -Benson On Wednesday, April 29, 2015, Behcet Sarikaya <[email protected]> wrote: > Is gpe talking about encapsulation of inner packets, i.e. data plane? > If yes then it is like GUE. Then one would ask why do we need another > GUE? > > Looking at the abstract which says > > changes to the VXLAN header > > I think the answer is no. > > I would understand a few flags like OAM that you defined as extensions to > VXLAN. > > But I have trouble understanding next protocol field. > I think VXLAN encapsulation does not need next protocol field because > what is being encapsulated is completely defined in RFC7348. > > If in the future the need arises that something like NSH also needs to > be defined then the best way to do is to.define RFC7348bis and add it > there. > > Regards, > > Behcet > > > On Wed, Apr 29, 2015 at 2:09 PM, Larry Kreeger (kreeger) > <[email protected] <javascript:;>> wrote: > > Regarding Joe Touch's comment about explicitly NOT indicating IPv4 vs > IPv6 > > in the Next Protocol (only indicating IP), I don't see what the > advantages > > of doing this are. It seems more philosophical. > > > > By indicating IPv4/IPv6 in the next protocol, it allows implementations > to > > only make one decision before parsing the IP header. By doing two steps > > NP->IP->IPv4/v6, it adds one more parsing step to the implementation, for > > no gain that I can think of. > > > > As Diego pointed out earlier, there is already a precedent in Ethernet > for > > indicating the IP version in the next protocol from the layer below it. > > > > - Larry > > > > On 4/29/15 11:36 AM, "Behcet Sarikaya" <[email protected] > <javascript:;>> wrote: > > > >>On Wed, Apr 29, 2015 at 1:13 PM, Paul Quinn (paulq) <[email protected] > <javascript:;>> > >>wrote: > >>> > >>>> On Apr 29, 2015, at 12:01 PM, Behcet Sarikaya <[email protected] > <javascript:;>> > >>>>wrote: > >>>> > >>>> On Tue, Apr 28, 2015 at 5:03 PM, Behcet Sarikaya > >>>><[email protected] <javascript:;>> wrote: > >>>>> Hi Benson, > >>>>> > >>>>> Joe Touch wrote this on intarea list: > >>>>> > >>>>> There is no reason for having the GUE header differentiate between > >>>>> payload=IPv4 and payload=IPv6. The IP version is addressed by the > >>>>> version field of the IP header. If GUE encapsulates both type of IP > >>>>>the > >>>>> same way (and it should), it should NOT differentiate between them in > >>>>> its (GUE) header. > >>>>> > >>>>> > >>>>> I think the same applies to gpe header. > >>>>> > >>>>> Plus the issues on the "NSH" protocol. > >>>> > >>>> Curiously if you look at the nsh draft, Section 3.2, > >>>> > >>>> NSH Base Header > >>>> > >>>> also has a next protocol field with the same encoding. > >>>> > >>>> Anybody understands what is going on? > >>> > >>> Yes, the concept is that you don't know what you want to carry via GPE. > >>> Today it might be v4, v6, ethernet, NSH or something else. Tomorrow, > >>>who knows? But more importantly, we need to enable that stacking to > >>>occur. > >>> > >> > >> > >>Please convince not me but Joe Touch on v4 and v6 thing. > >> > >>> The format of NSH is orthogonal -- as is the format of Ethernet for > >>>that matter. From an outer header (i.e. VXLAN-GPE or other) you need to > >>>be able to identify the inner protocol. > >>> > >> > >>Are we talking about VM-to-VM communication? I think that is what > >>VXLAN was designed for. > >> > >>Regards, > >> > >>Behcet > >>> Paul > >>> > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
