Re: [nvo3] NVO3 WG Adoption of draft-quinn-vxlan-gpe-04

[Benson Schliesser <[e-mail]>]

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 <[e-mail]>
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)
> <[e-mail] <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" <[e-mail]
> <javascript:;>> wrote:
> >
> >>On Wed, Apr 29, 2015 at 1:13 PM, Paul Quinn (paulq) <[e-mail]
> <javascript:;>>
> >>wrote:
> >>>
> >>>> On Apr 29, 2015, at 12:01 PM, Behcet Sarikaya <[e-mail]
> <javascript:;>>
> >>>>wrote:
> >>>>
> >>>> On Tue, Apr 28, 2015 at 5:03 PM, Behcet Sarikaya
> >>>><[e-mail] <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
> >>>
> >
>