> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Friday, June 17, 2016 11:07 PM > To: Xuxiaohu > Cc: Joe Touch; [email protected]; [email protected] > 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 <[email protected]> wrote: > > > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Friday, June 17, 2016 2:57 PM > >> To: Xuxiaohu; Tom Herbert > >> Cc: [email protected]; [email protected] > >> 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 > >> > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
