With Reference to : draft-ietf-nvo3-vxlan-gpe-01.txt
Dear Authors,
I noticed that below request from Shahram (almost 6 weeks ago) has not been
evaluated and considered in this draft discussion:
Current draft defines the following Next Protocol values:
0x1 : IPv4
0x2 : IPv6
0x3 : Ethernet
…
…
Appreciate kind consideration of assigning following value for Ethernet, in the
Next Protocol field:
0x0 : Ethernet
Thanks
Sandeep Relan
From: Shahram Davari
Sent: Wednesday, September 23, 2015 4:03 PM
To: Anoop Ghanwani; Larry Kreeger (kreeger)
Cc: Sandeep Kumar (Sandeep) Relan; [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]> [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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
Date: Monday, September 21, 2015 at 7: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,
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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
