Hi Mehr p-bit is not that important in VXLAN since it is ignored on reception.
I suggest the draft authors make the protocol type =0 for ethernet payload. Doing so will enable existing chips to support GPE with ethernet encapsulation. Regards, Shahram On Sep 21, 2015, at 7:28 PM, Sandeep Kumar (Sandeep) Relan <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[email protected]>> Date: Monday, September 21, 2015 at 5:28 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Shahram Davari <[email protected]<mailto:[email protected]>>, Larry Kreeger <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Date: Monday, September 21, 2015 at 4:40 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: "Sandeep Kumar (Sandeep) Relan" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> on behalf of "Sandeep Kumar (Sandeep) Relan" <[email protected]<mailto:[email protected]>> Date: Monday, September 21, 2015 at 4:24 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
