I suspect some implementations may check the version even today. Btw, wouldn't this lead to allocating yet another code-point in IP protocol name space for tunnels while code points already exist for v4 and v6 ? Would that be ok ?
Surendra. -----Original Message----- From: Joe Touch [mailto:[email protected]] Sent: Monday, November 09, 2015 9:46 AM To: Surendra Kumar (smkumar) <[email protected]>; Sandeep Kumar (Sandeep) Relan <[email protected]>; [email protected] Cc: [email protected]; Shahram Davari <[email protected]>; Anoop Ghanwani <[email protected]>; Larry Kreeger (kreeger) <[email protected]> Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ] That would be a lot better, though it still suffers from the use of different codepoints for IPv4 and IPv6. The concept of version numbers shouldn't be this difficult. Joe On 11/7/2015 11:49 AM, Surendra Kumar (smkumar) wrote: > On a related note, seems like the VXLAN-GPE next protocol field can do > away with the new registry and re-use the IP protocol numbers: > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm > l > > The only one not covered in that name space is NSH, which can be signaled > over UDP - which also limits the overhead. > > Regards, > Surendra. > > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Joe Touch > Sent: Thursday, November 05, 2015 3:31 PM > To: Sandeep Kumar (Sandeep) Relan <[email protected]>; [email protected] > Cc: Shahram Davari <[email protected]>; Anoop Ghanwani > <[email protected]>; Larry Kreeger (kreeger) <[email protected]>; > [email protected] > Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ > draft-ietf-nvo3-vxlan-gpe-01.txt ] > > Question - why are there two next-protocols for IP? That's what the IP > version number is for. > > (yes, Ethernet messed this up with two different next-proto values, > but it was only because "it's faster in hardware", which ceased to be > true vs looking at the IP version number directly) > > I.e., this mechanism should not require revision to support future versions > of IP. That's why IP has its own version number field. > > Joe > > On 11/5/2015 2:13 PM, Sandeep Kumar (Sandeep) Relan wrote: >> With Reference to : draft-ietf-nvo3-vxlan-gpe-01.txt >> >> >> >> Dear Authors, >> >> >> >> I noticed that below request from Shahram (almost 6 weeks ago) has >> not been evaluated and considered in this draft discussion: >> >> >> >> Current draft defines the following Next Protocol values: >> >> >> >> 0x1 : IPv4 >> >> 0x2 : IPv6 >> >> 0x3 : Ethernet >> >> ... >> >> ... >> >> >> >> Appreciate kind consideration of assigning following value for >> Ethernet, in the Next Protocol field: >> >> >> >> 0x0 : Ethernet >> >> >> >> >> >> Thanks >> >> Sandeep Relan >> >> >> >> *From:*Shahram Davari >> *Sent:* Wednesday, September 23, 2015 4:03 PM >> *To:* Anoop Ghanwani; Larry Kreeger (kreeger) >> *Cc:* Sandeep Kumar (Sandeep) Relan; [email protected] >> *Subject:* RE: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hi, >> >> >> >> There are existing VXLAN implementations that are deployed. The >> current VXLAN-GPE makes those hardware obsolete. If the new VXLAN-GPE >> would accept received packets with P=0 and Protocol-Type =0 as >> Ethernet and if it transmits P=1 and Protocol-Type=0 as Ethernet then >> existing Hardware can be used to support VXLAN-GPE Ethernet >> encapsulation, else new HW is required. >> >> >> >> Note that most implementations have configurable UDP Dest port #. >> >> >> >> Thx >> Shahram >> >> >> >> *From:*[email protected] <mailto:[email protected]> >> [mailto:[email protected]] *On Behalf Of *Anoop Ghanwani >> *Sent:* Wednesday, September 23, 2015 3:16 PM >> *To:* Larry Kreeger (kreeger) >> *Cc:* Sandeep Kumar (Sandeep) Relan; [email protected] >> <mailto:[email protected]>; Shahram Davari >> *Subject:* Re: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hi Larry, >> >> >> >> Perhaps Sandeep's question can be framed another way: >> >> >> >> Is it legal for a VXLAN-GPE implementation to accept/terminate >> tunneled packets with a P bit of 0 and a protocol of 0 or should it >> be discarding those? >> >> >> >> Anoop >> >> >> >> On Tue, Sep 22, 2015 at 10:56 AM, Larry Kreeger (kreeger) >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Sandeep, >> >> >> >> According to RFC 7348, a VTEP must ignore the contents of the >> reserved flags and reserved fields. Therefore, they will ignore both >> the P-bit and the Next Protocol type field in the VXLAN GPE packet. >> As long as only Ethernet is encapsulated and OAM is not used, then >> version 0 of VXLAN GPE can be received properly by a RFC 7348 VTEP. >> VXLAN GPE implementations must parse the P-bit and Next Protocol >> field anyway, so parsing it consistently for both Ethernet and all >> other protocols makes sense to me. >> >> >> >> - Larry >> >> >> >> *From: *"Sandeep Kumar (Sandeep) Relan" <[email protected] >> <mailto:[email protected]>> >> *Date: *Monday, September 21, 2015 at 7:28 PM >> *To: *"[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> *Cc: *Shahram Davari <[email protected] >> <mailto:[email protected]>>, Larry Kreeger <[email protected] >> <mailto:[email protected]>> >> *Subject: *Re: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hello Larry, >> >> >> >> I did see Section 5 on backward compatibility guidelines. >> >> >> >> Still. I am not sure - why disrupt the VXLAN header format >> compatibility with RFC 7348, for the Ethernet payload. >> >> >> >> GPE draft could additionally accept a special case of P=0 mode with >> protocol =0x0 as valid for Ethernet Payload., along with newly >> defined P >> =1 & Protocol = Ethernet (0x03). >> >> >> >> This will make at least VXLAN header with Ethernet payload >> compatible with the RFC 7348, even if UDP destination port numbers differ. >> >> >> >> Thanks >> >> Sandeep Relan >> >> >> On Sep 21, 2015, at 6:23 PM, Larry Kreeger (kreeger) >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Sandeep, >> >> >> >> If a VXLAN GPE implementation wants to interoperate with a legacy >> VXLAN VTEP, then it needs to not only accept them, but also be sure >> to send VXLAN compatible packets to the remote VTEP. This includes >> bits in addition to the P-bit, such as the O-bit and the version >> field. Rather than specifying just one case (the P-bit=0 for >> Ethernet) for a VXLAN GPE VTEP to encapsulate to a VXLAN VTEP, we >> wrote section 5 covering the interoperability case explicitly, and >> kept it unambiguously consistent for VXLAN GPE to VXLAN GPE VTEPs to >> always use the Next Protocol field. >> >> >> >> Thanks, Larry >> >> >> >> *From: *"Sandeep Kumar (Sandeep) Relan" <[email protected] >> <mailto:[email protected]>> >> *Date: *Monday, September 21, 2015 at 5:28 PM >> *To: *"[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> *Cc: *Shahram Davari <[email protected] >> <mailto:[email protected]>>, Larry Kreeger <[email protected] >> <mailto:[email protected]>> >> *Subject: *RE: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hello Larry ! >> >> >> >> Thanks for the detailed explanation. >> >> Now, I see a duplication (or maybe a conflict) between VXLAN - GPE >> draft and VXLAN RFC (7348), when sending Ethernet payload >> encapsulation: >> >> >> >> VXLAN - GPE mandates : P =1 & Protocol = Ethernet (0x03) >> >> VXLAN (RFC) mandates: P = 0 (reserved) & Protocol = 0x00 (reserved) >> >> >> >> Now, an Ethernet payload could be encapsulated by either of the >> above two incompatible VXLAN headers. >> >> Is there any other specific reason to make even the headers >> incompatible ? >> >> >> >> The VXLAN - GPE draft could maintain: P = 0 & Protocol = 0x00 for >> Ethernet encapsulated packets, and thereby maintain backward >> compatibility (at least) with the 8 octet header specified in VXLAN >> RFC (7348) . >> >> >> >> Thanks >> >> Sandeep Relan >> >> >> >> *From:*Larry Kreeger (kreeger) [mailto:[email protected]] >> *Sent:* Monday, September 21, 2015 4:52 PM >> *To:* Shahram Davari >> *Cc:* Sandeep Kumar (Sandeep) Relan; [email protected] >> <mailto:[email protected]> >> *Subject:* Re: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> VXLAN as define in RFC 7348 does not have a version field! It was >> added in VXLAN GPE. This is another reason to use a new UDP port, >> since VXLAN VTEPs will be ignoring this new version field! >> >> >> >> - Larry >> >> >> >> *From: *Shahram Davari <[email protected] >> <mailto:[email protected]>> >> *Date: *Monday, September 21, 2015 at 4:40 PM >> *To: *Larry Kreeger <[email protected] <mailto:[email protected]>> >> *Cc: *"Sandeep Kumar (Sandeep) Relan" <[email protected] >> <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>> >> *Subject: *Re: [nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hi Larry >> >> >> >> why not use a different version number instead of burning a scarce >> UDP port number? >> >> Regards, >> >> Shahram >> >> >> >> >> On Sep 21, 2015, at 4:36 PM, Larry Kreeger (kreeger) >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Sandeep, >> >> >> >> You are correct, that a VXLAN GPE implementation can be backward >> compatible to VXLAN by looking at the P-bit. Which is why we >> originally were sharing the same UDP port as VXLAN. The problem >> comes up when a VXLAN (only) VTEP gets a VXLAN GPE packet with >> the P-bit set, it has no idea what the P-bit means and >> subsequently ignores the bit (as the VXLAN RFC says it should). >> This means it expects an Ethernet frame to be directly following >> the VXLAN header...but since this the VXLAN GPE, the protocol >> field can be specifying some other protocol besides Ethernet. >> The VXLAN implementation would misinterpret the data and >> potentially misdeliver the data. >> >> >> >> If the tunnels between VTEPs are always point to point using a >> control plane, this scenario can be avoided, but if multicast is >> used, then you cannot mix VXLAN-only VTEPs (which are not >> forward compatible) with VLAN GPE VTEPs. So, the new UDP port >> was assigned to prevent a VXLAN GPE packet accidentally being >> sent to a VXLAN-only VTEP. Note that using the new UDP port is >> optional if this issue is not a problem in your environment >> based on not having a mix of VTEPs, or relying on a control >> plane to prevent this. >> >> >> >> - Larry >> >> >> >> *From: *nvo3 <[email protected] >> <mailto:[email protected]>> on behalf of "Sandeep Kumar >> (Sandeep) Relan" <[email protected] <mailto:[email protected]>> >> *Date: *Monday, September 21, 2015 at 4:24 PM >> *To: *"[email protected] <mailto:[email protected]>" <[email protected] >> <mailto:[email protected]>> >> *Subject: *[nvo3] destination UDP port : >> draft-ietf-nvo3-vxlan-gpe-00 >> >> >> >> Hello, >> >> >> >> Concern/Query : What is the need to have another Destination >> UDP port number ? >> >> >> >> Reference : draft-ietf-nvo3-vxlan-gpe-00 (VXLAN - GPE) >> >> >> >> This draft mentions that : >> >> IANA has assigned the value 4790 for the VXLAN-GPE UDP port. >> >> >> >> Further, this draft specifies: >> >> >> >> P Bit: Flag bit 5 is defined as the Next Protocol bit. The >> P bit >> >> MUST be set to 1 to indicate the presence of the 8 bit >> next >> >> protocol field. When P=1, the destination UDP port MUST be >> 4790. >> >> >> >> P = 0 indicates that the payload MUST conform to VXLAN as >> defined >> >> in [RFC7348 <https://tools.ietf.org/html/rfc7348>], >> including destination UDP port - 4789 >> >> >> >> >> >> What is the need for having another IANA assigned UDP >> destination port number ? >> >> >> >> I don't see any strong reasons on the need of another IANA >> assigned UDP destination port number ? >> >> I believe, the P Bit can take care of distinguishing between >> RFC 7348 VXLAN packet from VXLAN-GPE packets. >> >> >> >> Appreciate, any insight/ background on the requirement to define >> another new UDP destination port number for future VXLAN packets ? >> >> >> >> Thanks & regards >> >> Sandeep Relan >> >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> >> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
