Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Friday, June 17, 2016 11:07 PM
> To: Xuxiaohu
> Cc: Joe Touch; [e-mail]; [e-mail]
> Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for
> draft-ietf-nvo3-gue-03.txt
> 
> On Fri, Jun 17, 2016 at 12:48 AM, Xuxiaohu <[e-mail]> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Friday, June 17, 2016 2:57 PM
> >> To: Xuxiaohu; Tom Herbert
> >> Cc: [e-mail]; [e-mail]
> >> Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for
> >> draft-ietf-nvo3-gue-03.txt
> >>
> >>
> >>
> >> On 6/16/2016 11:41 PM, Xuxiaohu wrote:
> >> >> More than that, GUE was accepted as a WG doc *and* has already
> >> >> been assigned a port number.
> >> > Oh, a WG doc? a doc which has nothing to do with multi-tenancy but
> >> > happens
> >> to be adopted by a WG working on multi-tenancy?
> >> I'm not advocating where this doc *should be* - or should have been -
> adopted.
> >> I'm simply noting that it already has been adopted. Which does carry
> >> weight in the IANA assignment of ports (as noted in RFC 6335).
> >>
> >> >
> >> >>> To save a port number, the header format is made ugly. Is it
> >> >>> worthwhile? If
> >> >> UDP port resource was so sparse as you had imagined, I think the
> >> >> UDP port resource keeper would not allocate two different port
> >> >> numbers for VXLAN and VXLAN-GPE since the P-bit in VXLAN-GPE
> >> >> header is enough to distinguish VXLAN-GPE from VXLAN. For more
> >> >> details, please look at section 3.2 of
> >> (https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-02#page-6).
> >> >> VXLAN was assigned in 2011.
> >> >>
> >> >> VXLAN-GPE was assigned this year (2016).
> >> >>
> >> >> If what you say is correct*, then you might be correct in assuming
> >> >> that a VXLAN-GPE assignment might inhibit a later VXLAN
> >> >> assignment, but that's not the order things happened.
> >> > Your logic seems confused to me. My point is VXLAN-GPE should share
> >> > the
> >> same port number (i.e., 4789) with VXLAN if the port number resource
> >> was so sparse. Unless that assumption is fake.
> >>
> >> Your logic fails to consider that these two requests were not made at
> >> the same time. Also, VXLAN was not made *after* VXLAN-GPE. If either
> >> of these were true, then the argument for a single port number would be
> important.
> >
> > More confused to me:) Let me make it simpler, VXLAN was allocated a
> > port number in 2011 which is 4789. VXLAN-GPE asked for a port in 2016,
> > why allocate a new number rather than reusing the port number 4789
> > provided the port number resource was so sparse?  Your answers to the
> > above question seems to be: 1)these two requests were not made at the
> > same time, 2) VXLAN was not made *after* VXLAN-GPE. For the first
> > answer, did you mean, for two proposals which could have shared the
> > same port number, as long as they requests at different time no matter
> > intended or not, they would be assigned two different port numbers.
> > For the second answer, have you seen protocol X be made after an
> > extension protocol to X?:)
> >
> VXLAN-GPE requires a different protocol number, the P-bit was not sufficient.
> The problem was that VXLAN defined unknown flag bits to be ignored upon
> receive. So if a legacy VLXAN device ever received a VXLAN-GPE packet (P-bit set)
> it would be misinterpreted as a VLXAN packet. Effectively this makes VXLAN-GPE
> a new protocol not a different version of VXLAN. All of this was discussed on the
> nvo3 list.

In which situation will a legacy VXLAN device receive a VXLAN-GPE packet?

Xiaohu

> Tom
> 
> > Xiaohu
> >
> >> So, in brief, IMO (with my ports hat off) if you had a stronger
> >> argument for UDP-in-IP (i.e., you convinced a WG to adopt it) *and*
> >> you proposed it before GUE made its request, then things might have turned
> out differently.
> >
> >
> >
> >> Joe
> >>
> >