Agree. Especially since this would have to be signalled in the reverse direction. There is no need to add it in the the datapath.
On BGP-evpn we can use the tunnel-type extended community and add a new type specifically for vxlan-gpe. Given the backwards compatibility of vxlan gpe we can assume that a gpe capable end point should be capable of receiving "classic" vxlan. The only concern for the port numbers is that while the port number is configurable on some implementations it might not be necessarily possible to receive vxlan/gpe on both 4789 and 4790 simultaneously. And at the same time, not all implementations actually allow the port to be configured. I'm wondering if indeed we shouldn't go back to port 4789 for both plain and gpe vxlan. Since a gpe endpoint will know it's talking to a vanilla endpoint and transmit with p=0 and no protocol type. And a vanilla vxlan will send to gpe on 4789 and not have to worry about changing he transmit port in realtime. Finally a gpe talking to gpe can just set the p=1 and if necessary set the payload type of different than Ethernet. In short... The control plane should tell a gpe vtep if the remote vtep it's trying to talk to is gpe or vanilla. And a vanilla endpoint might be upgraded in the control plane to accept gpe as an option but speak vanilla only on the dataplane. I don't recall off the top of my head if we can specify more than one tunnel type in evpn per endpoint so that we could potentially signal vanilla vxlan and gpe. > On Sep 23, 2015, at 16:59, Larry Kreeger (kreeger) <[email protected]> wrote: > > Hi Tom, > > As it says in section 5.2 "A method for determining the capabilities of a > VXLAN VTEP (GPE or non-GPE) is out of the scope of this draft.² We are > assuming this is going to be handled by the control or management plane, > and not burden the data plane with a bit to signal this. > > - Larry > > >> On 9/23/15, 4:42 PM, "Tom Herbert" <[email protected]> wrote: >> >> 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) >> <[email protected]> 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 <[email protected]> >>> Date: Wednesday, September 23, 2015 at 4:02 PM >>> To: Anoop Ghanwani <[email protected]>, 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, >>> >>> >>> >>> 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]] On Behalf Of Anoop >>> Ghanwani >>> Sent: Wednesday, September 23, 2015 3:16 PM >>> To: Larry Kreeger (kreeger) >>> Cc: Sandeep Kumar (Sandeep) Relan; [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]> 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]] >>> 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], 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 > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
