Comments inline Yours Irrespectively,
John > -----Original Message----- > From: nvo3 [mailto:[email protected]] On Behalf Of Diego Garcia del > Rio > Sent: Wednesday, September 23, 2015 10:02 PM > To: Larry Kreeger (kreeger) > Cc: Tom Herbert; Shahram Davari; Anoop Ghanwani; Sandeep Kumar > (Sandeep) Relan; [email protected] > Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00 > > 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. [JD] https://tools.ietf.org/html/draft-ietf-bess-evpn-overlay-01#section-13 > > 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. [JD] You can advertise multiple supported encapsulations > > > > > > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
