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
