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.xhtml
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
