Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 21 Sep 2015 23:36:35 +0000

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-masked]<mailto:[email-masked]>> on behalf of "Sandeep Kumar (Sandeep) Relan" <[email-masked]<mailto:[email-masked]>>
Date: Monday, September 21, 2015 at 4:24 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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

---

From: Shahram Davari <[email-masked]>
Date: Mon, 21 Sep 2015 23:40:11 +0000

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-masked]<mailto:[email-masked]>> 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.

 - Larry

Hello,

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.

Thanks & regards
Sandeep Relan

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Mon, 21 Sep 2015 23:52:13 +0000

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-masked]<mailto:[email-masked]>>
Date: Monday, September 21, 2015 at 4:40 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "Sandeep Kumar (Sandeep) Relan" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi Larry

Regards,
Shahram

Hi Sandeep,

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Sandeep Kumar (Sandeep) Relan" <[email-masked]>
Date: Tue, 22 Sep 2015 00:28:51 +0000

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-masked]]
Sent: Monday, September 21, 2015 4:52 PM
To: Shahram Davari
Cc: Sandeep Kumar (Sandeep) Relan; [email-masked]
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 22 Sep 2015 01:23:09 +0000

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-masked]<mailto:[email-masked]>>
Date: Monday, September 21, 2015 at 5:28 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Shahram Davari <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>
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)

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-masked]]
Sent: Monday, September 21, 2015 4:52 PM
To: Shahram Davari
Cc: Sandeep Kumar (Sandeep) Relan; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Sandeep Kumar (Sandeep) Relan" <[email-masked]>
Date: Tue, 22 Sep 2015 02:28:53 +0000

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-masked]<mailto:[email-masked]>> wrote:

Hi Sandeep,

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: Shahram Davari <[email-masked]>
Date: Tue, 22 Sep 2015 02:53:19 +0000

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-masked]<mailto:[email-masked]>> wrote:

Hello Larry,

Thanks
Sandeep Relan

Hi Sandeep,

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Tue, 22 Sep 2015 17:56:06 +0000

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

Date: Monday, September 21, 2015 at 7:28 PM

Hello Larry,

Thanks
Sandeep Relan

Hi Sandeep,

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 23 Sep 2015 15:16:13 -0700

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-masked]
> 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-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Shahram Davari <[email-masked]>, Larry Kreeger <[email-masked]
> >
> 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-masked]>
> 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-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: Shahram Davari <[email-masked]>, Larry Kreeger <[email-masked]
> >
> Now, I see a duplication (or maybe a conflict) between VXLAN – GPE draft
>  and VXLAN RFC (7348), when sending Ethernet payload encapsulation:
>
>
>
> 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-masked]
> <[email-masked]>]
> *Sent:* Monday, September 21, 2015 4:52 PM
> *To:* Shahram Davari
> *Cc:* Sandeep Kumar (Sandeep) Relan; [email-masked]
> *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-masked]>
> *Date: *Monday, September 21, 2015 at 4:40 PM
> *To: *Larry Kreeger <[email-masked]>
> *Cc: *"Sandeep Kumar (Sandeep) Relan" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00
>
>
>
> Hi Larry
>
>
>
> On Sep 21, 2015, at 4:36 PM, Larry Kreeger (kreeger) <[email-masked]>
> 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-masked]> on behalf of "Sandeep Kumar
> (Sandeep) Relan" <[email-masked]>
> *Date: *Monday, September 21, 2015 at 4:24 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00
>
>
>
> Hello,
>
>
>
>       in [RFC7348 <https://tools.ietf.org/html/rfc7348>], including destination UDP port - 4789
>
>
>
>
>
> Appreciate, any insight/ background on the requirement to define another
> new UDP destination port number for future VXLAN packets ?
>
>
>
> Thanks & regards
>
> Sandeep Relan
>
>
>
> [email-masked]
> [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Wed, 23 Sep 2015 23:02:49 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 23, 2015 3:16 PM
To: Larry Kreeger (kreeger)
Cc: Sandeep Kumar (Sandeep) Relan; [email-masked]; Shahram Davari
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi Larry,

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-masked]<mailto:[email-masked]>> wrote:
Hi Sandeep,

 - Larry

Hello Larry,

Thanks
Sandeep Relan

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 23 Sep 2015 23:06:31 +0000

Hi Anoop,

I’m not sure who the “police” would be to enforce such legality…but if I were to act as a “lawyer”, to answer your question, my interpretation is:  Yes, a VXLAN-GPE implementation can in fact accept packets with P-bit=0 by assuming it carries an Ethernet payload – as long as it is on the original VXLAN UDP port (4789).  I’m basing this on the text describing the P-bit in section 3.2 which states:

“P = 0 indicates that the payload MUST conform to VXLAN as defined in [RFC7348<https://tools.ietf.org/html/rfc7348>], including destination UDP port.”

Now it doesn’t say this, but my personal opinion is that it should be fine to interpret P-bit=0 to always carry Ethernet, regardless of the UDP port.  If no one sees any problems with this opinion, perhaps we can loosen the text to remove the “including destination UDP port” clause at the end of the quoted sentence above.

 - Larry

From: <[email-masked]<mailto:[email-masked]>> on behalf of Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 23, 2015 at 3:16 PM
To: Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "Sandeep Kumar (Sandeep) Relan" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shahram Davari <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi Larry,

Anoop

 - Larry

Hello Larry,

Thanks
Sandeep Relan

Hi Sandeep,

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 23 Sep 2015 23:21:53 +0000

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-masked]<mailto:[email-masked]>>
Date: Wednesday, September 23, 2015 at 4:02 PM
To: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, Larry Kreeger <[email-masked]<mailto:[email-masked]>>
Cc: "Sandeep Kumar (Sandeep) Relan" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi,

Thx
Shahram

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Wednesday, September 23, 2015 3:16 PM
To: Larry Kreeger (kreeger)
Cc: Sandeep Kumar (Sandeep) Relan; [email-masked]<mailto:[email-masked]>; Shahram Davari
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi Larry,

Anoop

 - Larry

Hello Larry,

Thanks
Sandeep Relan

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: Tom Herbert <[email-masked]>
Date: Wed, 23 Sep 2015 16:42:07 -0700

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-masked]> 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-masked]>
> To: Anoop Ghanwani <[email-masked]>, Larry Kreeger
> <[email-masked]>
> Cc: "Sandeep Kumar (Sandeep) Relan" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> 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.
>
>
>
> On Tue, Sep 22, 2015 at 10:56 AM, Larry Kreeger (kreeger)
> <[email-masked]> 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
>
>
>
> Cc: Shahram Davari <[email-masked]>, Larry Kreeger <[email-masked]>
> 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
>
>
> 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
>
>
>
> Cc: Shahram Davari <[email-masked]>, Larry Kreeger <[email-masked]>
> 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
>
>
>
> 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-masked]>
> To: Larry Kreeger <[email-masked]>
> Cc: "Sandeep Kumar (Sandeep) Relan" <[email-masked]>, "[email-masked]"
> <[email-masked]>
> 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.
>
>
>
> 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
> 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-masked]> on behalf of "Sandeep Kumar (Sandeep)
> Relan" <[email-masked]>
>       in [RFC7348], including destination UDP port - 4789
>
>
>
>
>
> Appreciate, any insight/ background on the requirement to define another new
> UDP destination port number for future VXLAN packets ?
>
>
>
> Thanks & regards
>
> Sandeep Relan
>
>
>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 23 Sep 2015 23:59:29 +0000

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-masked]> wrote:

>> removing the clause ³including destination UDP port² from the end of the
>> should be ignoring that field regardless.  I¹m referring to section 5
>>of RFC
>>flags
>>protocol
>>with
>>encapsulate
>> Now, I see a duplication (or maybe a conflict) between VXLAN  GPE draft
>> VXLAN  GPE mandates :  P =1 & Protocol = Ethernet (0x03)
>>
>> Now, an Ethernet payload could be encapsulated by either of the above
>>two
>> incompatible VXLAN headers.
>>
>> The VXLAN  GPE draft could maintain:  P = 0 & Protocol = 0x00 for
>>Ethernet
>> why not use a different version number instead of burning a scarce UDP
>>port
>> number?
>>
>> Regards,
>>
>> Shahram
>>
>>
>>
>>
>>compatible
>> headerŠbut since this the VXLAN GPE, the protocol field can be
>>specifying
>> I don¹t see any strong reasons on the need of another IANA assigned UDP
>> destination port number ?
>>

---

From: Diego Garcia del Rio <[email-masked]>
Date: Wed, 23 Sep 2015 19:01:51 -0700

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.

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.

> On Sep 23, 2015, at 16:59, Larry Kreeger (kreeger) <[email-masked]> wrote:
>
> Hi Tom,
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Wed, 23 Sep 2015 22:21:59 -0700

Hi Larry,

I would interpret the text quoted as recommending a discard if the UDP port
was that of VXLAN GPE.

We could loosen the text as you suggest and I think that would be useful.
It allows a legacy implementation that is capable of programming the GPE
port to participate in network with GPE-capable devices, while using a
single UDP port for all of them.

What we may want to say, then, is that if a P bit of 0 is used then none of
the other flags must be set.  This would prevent someone from generating a
packet with a P bit of 0 and trying to use new GPE features.

Anoop

On Wed, Sep 23, 2015 at 4:06 PM, Larry Kreeger (kreeger) <[email-masked]>
wrote:

> Hi Anoop,
>
> I’m not sure who the “police” would be to enforce such legality…but if I
> were to act as a “lawyer”, to answer your question, my interpretation is:
>  Yes, a VXLAN-GPE implementation can in fact accept packets with P-bit=0 by
> assuming it carries an Ethernet payload – as long as it is on the original
> VXLAN UDP port (4789).  I’m basing this on the text describing the P-bit in
> section 3.2 which states:
>
> “P = 0 indicates that the payload MUST conform to VXLAN as defined in [
> RFC7348 <https://tools.ietf.org/html/rfc7348>], including destination UDP
> port.”
>
> Now it doesn’t say this, but my personal opinion is that it should be fine
> to interpret P-bit=0 to always carry Ethernet, regardless of the UDP port.
> If no one sees any problems with this opinion, perhaps we can loosen the
> text to remove the “including destination UDP port” clause at the end of
> the quoted sentence above.
>
>  - Larry
>
> From: <[email-masked]> on behalf of Anoop Ghanwani <
> [email-masked]>
> <[email-masked]>, Shahram Davari <[email-masked]>
>
> On Tue, Sep 22, 2015 at 10:56 AM, Larry Kreeger (kreeger) <
> [email-masked]> wrote:
>
>> Hi Sandeep,
>>
>> port number?

---

From: <[email-masked]>
Date: Thu, 24 Sep 2015 09:24:50 +0200

Hi Diego,

> capable of receiving "classic" vxlan.
[...]
> tunnel type in evpn per endpoint so that we could potentially signal

Yes, the BGP Encapsulation extended community in RFC5512 section 4.5 
allows to advertize more than one encap.
And distinct codepoints for VXLAN and VXLAN-GPE have been allocated to 
IANA already [1].

Note that draft-ietf-idr-tunnel-encaps-00 which generalizes the use of 
RFC5512 also allows to specify the destination port in a BGP-based 
control plane.

Best,

-Thomas

[1] 
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

>>>> UDP destination port number for future VXLAN packets ?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: John E Drake <[email-masked]>
Date: Thu, 24 Sep 2015 12:32:02 +0000

Comments inline

Yours Irrespectively,

John

> -----Original Message-----
> From: nvo3 [mailto:[email-masked]] On Behalf Of Diego Garcia del
> Rio
> Sent: Wednesday, September 23, 2015 10:02 PM
> Cc: Tom Herbert; Shahram Davari; Anoop Ghanwani; Sandeep Kumar
> (Sandeep) Relan; [email-masked]
> 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

> > 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
> >
> >
> >>> 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
> >>> 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
> >>>
> >>>
> >>> 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.
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> Still. I am not sure - why disrupt the VXLAN header format
> >>> compatibility with RFC 7348, for the Ethernet payload.
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>> 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
> >>>
> >>>
> >>>
> >>> Now, I see a duplication (or maybe a conflict) between VXLAN  GPE
> >>> draft and VXLAN RFC (7348), when sending Ethernet payload
> encapsulation:
> >>>
> >>>
> >>>
> >>> Ethernet encapsulated packets, and thereby maintain backward
> >>> compatibility (at
> >>> least)
> >>> 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
> >>>
> >>>
> >>>
> >>> 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-masked]> on behalf of "Sandeep Kumar
> >>> 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
> >>>
> >>>
> >>>

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Sep 2015 14:34:56 +0000

See inline below.

From: nvo3 [mailto:[email-masked]] On Behalf Of Anoop Ghanwani
Sent: Thursday, September 24, 2015 12:22 AM
To: Larry Kreeger (kreeger)
Cc: Sandeep Kumar (Sandeep) Relan; [email-masked]; Shahram Davari
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

Hi Larry,

I would interpret the text quoted as recommending a discard if the UDP port was that of VXLAN GPE.

We could loosen the text as you suggest and I think that would be useful.  It allows a legacy implementation that is capable of programming the GPE port to participate in network with GPE-capable devices, while using a single UDP port for all of them.

What we may want to say, then, is that if a P bit of 0 is used then none of the other flags must be set.  This would prevent someone from generating a packet with a P bit of 0 and trying to use new GPE features.
[Lucy] The P bit is used for version purpose too.  The rule is if the GPE need support new features to Ethernet payload, it has to set P bit and use the protocol field to indicate Ethernet payload.
The rule is: GPE accepts a special case of P=0 mode as valid for Ethernet Payload., and P =1 (mode) & Protocol = Ethernet (0x03). When a P bit of 0 is used, none of the other flags must be set.

This works under condition/rule that VXLAN protocol enhancement MUST be stopped.

Thanks,
Lucy

Anoop

On Wed, Sep 23, 2015 at 4:06 PM, Larry Kreeger (kreeger) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Anoop,

 - Larry

Hi Larry,

Anoop

 - Larry

Hello Larry,

Thanks
Sandeep Relan

Thanks, Larry

Hello Larry !

Thanks
Sandeep Relan

 - Larry

Hi Larry

Regards,
Shahram

 - Larry

Hello,

Thanks & regards
Sandeep Relan

---

From: Tom Herbert <[email-masked]>
Date: Thu, 24 Sep 2015 08:07:44 -0700

> [Lucy] The P bit is used for version purpose too.  The rule is if the GPE
> need support new features to Ethernet payload, it has to set P bit and use
> the protocol field to indicate Ethernet payload.
>
> The rule is: GPE accepts a special case of P=0 mode as valid for Ethernet
> Payload., and P =1 (mode) & Protocol = Ethernet (0x03). When a P bit of 0 is
> used, none of the other flags must be set.
>
>
>
Lucy,

I'm not sure why the constraint needs to be so stringent. The P bit
can be used to discriminate between VXLAN and VXLAN-GPE received on
the same port. i.e if P bit is set, it is a VXLAN-GPE packet. If it is
not set it is VXLAN packet and the rest of the fields are processed
accordingly. New features can be added to either protocol in this way
using the other reserved bits independently. This allows backwards
compatibility to receive VXLAN on a VXLAN-GPE port (doesn't help with
the forward compatibility problem though).

Tom

---

From: Lucy yong <[email-masked]>
Date: Thu, 24 Sep 2015 15:14:59 +0000

See inline below.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Thursday, September 24, 2015 10:08 AM
To: Lucy yong
Cc: Anoop Ghanwani; Larry Kreeger (kreeger); Sandeep Kumar (Sandeep) Relan; [email-masked]; Shahram Davari
Subject: Re: [nvo3] destination UDP port : draft-ietf-nvo3-vxlan-gpe-00

> What we may want to say, then, is that if a P bit of 0 is used then 
> none of the other flags must be set.  This would prevent someone from 
> generating a packet with a P bit of 0 and trying to use new GPE features.
>
> [Lucy] The P bit is used for version purpose too.  The rule is if the 
> GPE need support new features to Ethernet payload, it has to set P bit 
> and use the protocol field to indicate Ethernet payload.
>
> The rule is: GPE accepts a special case of P=0 mode as valid for 
> Ethernet Payload., and P =1 (mode) & Protocol = Ethernet (0x03). When 
> a P bit of 0 is used, none of the other flags must be set.
>
>
>
Lucy,

I'm not sure why the constraint needs to be so stringent. The P bit can be used to discriminate between VXLAN and VXLAN-GPE received on the same port. i.e if P bit is set, it is a VXLAN-GPE packet. If it is not set it is VXLAN packet and the rest of the fields are processed accordingly. New features can be added to either protocol in this way using the other reserved bits independently. This allows backwards compatibility to receive VXLAN on a VXLAN-GPE port (doesn't help with the forward compatibility problem though).
[Lucy] What you say is the draft intention. My comment is to say, if we add this rule as Anoop suggested "When 
a P bit of 0 is used, none of the other flags must be set.", it will only work if no more VXLAN enhancement in future, e.g. using a new bit for something. If there will be, it will cause an issue for interworking between two. I just want to point out for caution.

Lucy

Tom

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Fri, 25 Sep 2015 01:18:05 +0000

On 9/24/15, 8:14 AM, "Lucy yong" <[email-masked]> wrote:

>I'm not sure why the constraint needs to be so stringent. The P bit can
>be used to discriminate between VXLAN and VXLAN-GPE received on the same
>port. i.e if P bit is set, it is a VXLAN-GPE packet. If it is not set it
>is VXLAN packet and the rest of the fields are processed accordingly. New
>features can be added to either protocol in this way using the other
>reserved bits independently. This allows backwards compatibility to
>receive VXLAN on a VXLAN-GPE port (doesn't help with the forward
>compatibility problem though).
>a P bit of 0 is used, none of the other flags must be set.", it will only
>work if no more VXLAN enhancement in future, e.g. using a new bit for
>something. If there will be, it will cause an issue for interworking
>between two. I just want to point out for caution.

If I can restate what I think you two agree on, it is:  If VXLAN evolves
independently from VXLAN GPE, then a VXLAN GPE endpoint that understands
only how to be backward compatible with RFC7348 VXLAN will not be able to
be compatible with the unknown evolution of RFC748.

For this reason, I would discourage anyone from taking RFC7348 VXLAN on a
separate evolutionary path from VXLAN than what VXLAN GPE is.  I would
encourage any IETF work on evolving VXLAN to instead evolve VXLAN GPE
which has an actual version field to prevent unknown forwarding behavior
from occurring if a VXLAN GPE version 0 endpoint receives an evolved (next
version) of VXLAN GPE.

 - Larry

---

From: Diego Garcia del Rio <[email-masked]>
Date: Thu, 24 Sep 2015 18:21:39 -0700

Thanks for the references thomas! I was replying from my phone and had a
hard time finding these.

On Thu, Sep 24, 2015 at 12:24 AM, <[email-masked]> wrote:

> RFC5512 also allows to specify the destination port in a BGP-based control
> plane.
>
> Best,
>
> -Thomas
>
> [1]
>>>>> IANA.  I
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>>> Anoop
>>>>> Ghanwani
>>>>> draft
>>>>> added in
>>>>> VXLAN
>>>>> another new
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Anoop Ghanwani <[email-masked]>
Date: Thu, 24 Sep 2015 18:24:10 -0700

Larry,

> from occurring if a VXLAN GPE version 0 endpoint receives an evolved (next

It is for that reason that I suggested tightening the text.

Anoop