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
