Larry, Have you thought about adding maybe VXLAN-GPE capable bit that an endpoint could use to indicate it's capable of receiving VXLAN-GPE on a VXLAN port?
Tom On Wed, Sep 23, 2015 at 4:21 PM, Larry Kreeger (kreeger) <kree...@cisco.com> wrote: > Hi Shahram, > > Yes, most VXLAN implementations allow the destination UDP port to be > configurable because we took too long to get a UDP port assigned by IANA. I > also believe that some implementations will want to run both VXLAN and > VXLAN-GPE on the same UDP port. This is another reason why I would favor > removing the clause “including destination UDP port” from the end of the > P-bit=0 sentence in section 3.2. > > I think checking the P-bit=0 is good enough, with no need to check the Next > Protocol field at all since the contents of the field should be undefined > when P-bit=0 and should be ignored. Likewise, I do not see any reason to > define Next Protocol = 0 to indicate an Ethernet payload (the current draft > has NP=0 as reserved, and NP=3 as Ethernet), since a RFC 7348 implementation > should be ignoring that field regardless. I’m referring to section 5 of RFC > 7348 which states "Reserved fields (24 bits and 8 bits): MUST be set to zero > on transmission and ignored on receipt." > > Thanks, Larry > > > From: Shahram Davari <dav...@broadcom.com> > Date: Wednesday, September 23, 2015 at 4:02 PM > To: Anoop Ghanwani <an...@alumni.duke.edu>, Larry Kreeger > <kree...@cisco.com> > Cc: "Sandeep Kumar (Sandeep) Relan" <sre...@broadcom.com>, "nvo3@ietf.org" > <nvo3@ietf.org> > 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: ghanw...@gmail.com [mailto:ghanw...@gmail.com] On Behalf Of Anoop > Ghanwani > Sent: Wednesday, September 23, 2015 3:16 PM > To: Larry Kreeger (kreeger) > Cc: Sandeep Kumar (Sandeep) Relan; nvo3@ietf.org; 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) > <kree...@cisco.com> 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" <sre...@broadcom.com> > Date: Monday, September 21, 2015 at 7:28 PM > To: "nvo3@ietf.org" <nvo3@ietf.org> > Cc: Shahram Davari <dav...@broadcom.com>, Larry Kreeger <kree...@cisco.com> > 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) <kree...@cisco.com> > 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" <sre...@broadcom.com> > Date: Monday, September 21, 2015 at 5:28 PM > To: "nvo3@ietf.org" <nvo3@ietf.org> > Cc: Shahram Davari <dav...@broadcom.com>, Larry Kreeger <kree...@cisco.com> > 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:kree...@cisco.com] > Sent: Monday, September 21, 2015 4:52 PM > To: Shahram Davari > Cc: Sandeep Kumar (Sandeep) Relan; nvo3@ietf.org > 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 <dav...@broadcom.com> > Date: Monday, September 21, 2015 at 4:40 PM > To: Larry Kreeger <kree...@cisco.com> > Cc: "Sandeep Kumar (Sandeep) Relan" <sre...@broadcom.com>, "nvo3@ietf.org" > <nvo3@ietf.org> > 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) <kree...@cisco.com> > 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 <nvo3-boun...@ietf.org> on behalf of "Sandeep Kumar (Sandeep) > Relan" <sre...@broadcom.com> > Date: Monday, September 21, 2015 at 4:24 PM > To: "nvo3@ietf.org" <nvo3@ietf.org> > 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], 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 > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
