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
