Hi Larry, I would interpret the text quoted as recommending a discard if the UDP port was that of VXLAN GPE.
We could loosen the text as you suggest and I think that would be useful. It allows a legacy implementation that is capable of programming the GPE port to participate in network with GPE-capable devices, while using a single UDP port for all of them. What we may want to say, then, is that if a P bit of 0 is used then none of the other flags must be set. This would prevent someone from generating a packet with a P bit of 0 and trying to use new GPE features. Anoop On Wed, Sep 23, 2015 at 4:06 PM, Larry Kreeger (kreeger) <[email protected]> wrote: > Hi Anoop, > > I’m not sure who the “police” would be to enforce such legality…but if I > were to act as a “lawyer”, to answer your question, my interpretation is: > Yes, a VXLAN-GPE implementation can in fact accept packets with P-bit=0 by > assuming it carries an Ethernet payload – as long as it is on the original > VXLAN UDP port (4789). I’m basing this on the text describing the P-bit in > section 3.2 which states: > > “P = 0 indicates that the payload MUST conform to VXLAN as defined in [ > RFC7348 <https://tools.ietf.org/html/rfc7348>], including destination UDP > port.” > > Now it doesn’t say this, but my personal opinion is that it should be fine > to interpret P-bit=0 to always carry Ethernet, regardless of the UDP port. > If no one sees any problems with this opinion, perhaps we can loosen the > text to remove the “including destination UDP port” clause at the end of > the quoted sentence above. > > - Larry > > From: <[email protected]> on behalf of Anoop Ghanwani < > [email protected]> > Date: Wednesday, September 23, 2015 at 3:16 PM > To: Larry Kreeger <[email protected]> > Cc: "Sandeep Kumar (Sandeep) Relan" <[email protected]>, "[email protected]" > <[email protected]>, Shahram Davari <[email protected]> > > 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]> 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]> >> Date: Monday, September 21, 2015 at 7:28 PM >> To: "[email protected]" <[email protected]> >> Cc: Shahram Davari <[email protected]>, Larry Kreeger < >> [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]> >> 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]> >> Date: Monday, September 21, 2015 at 5:28 PM >> To: "[email protected]" <[email protected]> >> Cc: Shahram Davari <[email protected]>, Larry Kreeger < >> [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] >> <[email protected]>] >> *Sent:* Monday, September 21, 2015 4:52 PM >> *To:* Shahram Davari >> *Cc:* Sandeep Kumar (Sandeep) Relan; [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]> >> *Date: *Monday, September 21, 2015 at 4:40 PM >> *To: *Larry Kreeger <[email protected]> >> *Cc: *"Sandeep Kumar (Sandeep) Relan" <[email protected]>, " >> [email protected]" <[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]> >> 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]> on behalf of "Sandeep Kumar >> (Sandeep) Relan" <[email protected]> >> *Date: *Monday, September 21, 2015 at 4:24 PM >> *To: *"[email protected]" <[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] >> 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
