Subject: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ]

From: "Sandeep Kumar (Sandeep) Relan" <[email-masked]>
Date: Thu, 5 Nov 2015 22:13:06 +0000

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-masked]
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-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,

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]<mailto:[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]<mailto:[email-masked]>>
Date: Monday, September 21, 2015 at 7: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,

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,

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)

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

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.

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

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 5 Nov 2015 15:30:44 -0800

Question - why are there two next-protocols for IP? That's what the IP
version number is for.

(yes, Ethernet messed this up with two different next-proto values, but
it was only because "it's faster in hardware", which ceased to be true
vs looking at the IP version number directly)

I.e., this mechanism should not require revision to support future
versions of IP. That's why IP has its own version number field.

Joe

On 11/5/2015 2:13 PM, Sandeep Kumar (Sandeep) Relan wrote:
> I noticed that below request from Shahram (almost 6 weeks ago) has not
> been evaluated and considered in this draft discussion:
> 
>  
> 
> *From:*Shahram Davari
> *Sent:* Wednesday, September 23, 2015 4:03 PM
> *To:* Anoop Ghanwani; Larry Kreeger (kreeger)
> *Cc:* Sandeep Kumar (Sandeep) Relan; [email-masked]
> *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.
> 
>  
> 
> *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,
> 
>  
> 
> 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,
> 
>  
> 
> 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]
> <mailto:[email-masked]>>
> *Date: *Monday, September 21, 2015 at 7: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,
> 
>  
> 
> 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
> 
> 
>     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 !
> 
>      
> 
>     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]]
>     *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
> 
>      
> 
>     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
> 
>      
> 
>     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.
> 
>          
> 
>         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,
> 
>          
> 
>               in [RFC7348 <https://tools.ietf.org/html/rfc7348>],
>         including destination UDP port - 4789
> 
>          
> 
>          
> 
>         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
> 
>          
> 
>         [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sat, 7 Nov 2015 19:49:30 +0000

On a related note, seems like the VXLAN-GPE next protocol field can do away with the new registry and re-use the IP protocol numbers: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

The only one not covered in that name space is NSH, which can be signaled over UDP - which also limits the overhead.

Regards,
Surendra.

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Thursday, November 05, 2015 3:31 PM
To: Sandeep Kumar (Sandeep) Relan <[email-masked]>; [email-masked]
Cc: Shahram Davari <[email-masked]>; Anoop Ghanwani <[email-masked]>; Larry Kreeger (kreeger) <[email-masked]>; [email-masked]
Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ]

Question - why are there two next-protocols for IP? That's what the IP version number is for.

(yes, Ethernet messed this up with two different next-proto values, but it was only because "it's faster in hardware", which ceased to be true vs looking at the IP version number directly)

I.e., this mechanism should not require revision to support future versions of IP. That's why IP has its own version number field.

Joe

On 11/5/2015 2:13 PM, Sandeep Kumar (Sandeep) Relan wrote:
>               ...
>               ...
> 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
> 
>  
> 
> 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.
> 
>  
> 
> On Sep 21, 2015, at 6:23 PM, Larry Kreeger (kreeger) 
>     Now, I see a duplication (or maybe a conflict) between VXLAN - GPE
>     VXLAN - GPE mandates :  P =1 & Protocol = Ethernet (0x03)
> 
>     The VXLAN - GPE draft could maintain:  P = 0 & Protocol = 0x00 for
>         the VXLAN header...but since this the VXLAN GPE, the protocol
>         I don't see any strong reasons on the need of another IANA
>         assigned UDP destination port number ?
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Nov 2015 09:45:49 -0800

That would be a lot better, though it still suffers from the use of
different codepoints for IPv4 and IPv6.

The concept of version numbers shouldn't be this difficult.

Joe

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Sun, 15 Nov 2015 20:47:03 +0000

I suspect some implementations may check the version even today.

Btw, wouldn't this lead to allocating yet another code-point in IP protocol name space for tunnels while code points already exist for v4 and v6 ? Would that be ok ?

Surendra.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, November 09, 2015 9:46 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Sandeep Kumar (Sandeep) Relan <[email-masked]>; [email-masked]
Cc: [email-masked]; Shahram Davari <[email-masked]>; Anoop Ghanwani <[email-masked]>; Larry Kreeger (kreeger) <[email-masked]>
Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ]

That would be a lot better, though it still suffers from the use of different codepoints for IPv4 and IPv6.

Joe

On 11/7/2015 11:49 AM, Surendra Kumar (smkumar) wrote:
> On a related note, seems like the VXLAN-GPE next protocol field can do 
> away with the new registry and re-use the IP protocol numbers: 
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtm
> l
> 
> Cc: Shahram Davari <[email-masked]>; Anoop Ghanwani 
> <[email-masked]>; Larry Kreeger (kreeger) <[email-masked]>; 
> [email-masked]
> (yes, Ethernet messed this up with two different next-proto values, 
> but it was only because "it's faster in hardware", which ceased to be 
> true vs looking at the IP version number directly)
> 
>> I noticed that below request from Shahram (almost 6 weeks ago) has 
>> not been evaluated and considered in this draft discussion:
>>
>>  
>>
>> 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
>>
>>  
>>
>> 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
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 16 Nov 2015 11:53:48 -0800

> I suspect some implementations may check the version even today.

It's not about checking the version number. It's that the version number
is what should be used to differentiate different versions of IP, not
the outer (lower) layer next-protocol field. That field should really
only say "IP", i.e., not "IPv4" or "IPv6".

The reason this didn't happen for Ethernet was because of a perception
that hardware would need "deep" packet information, which would be
otherwise too complex to extract. That situation was true for the first
year or so of deployment, but was quickly overtaken by technology
capability.

Yet another reason never to make a protocol design decision for a
short-term optimization.

> Btw, wouldn't this lead to allocating yet another code-point in IP
> protocol name space for tunnels while code points already exist for v4
> and v6 ? Would that be ok ?

No; I was just remarking that we should have one codepoint for IP, not
different ones for IPv4, IPv6, and (eventually) whatever IP versions follow.

Whether we have one or more codepoints for IP in ethernet or other lower
layers, there are already codepoints for IP "next protocol" being IP.
Unfortunately, IP makes the same error - it uses "4" for IPv4 and "41"
for IPv6; it should really have just stuck with one value.

Joe

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Mon, 16 Nov 2015 21:45:37 +0000

Agree. I was just implying that the cost equivalent of discriminating v6/v4 via the IP.ver field may already be paid even today.

Surendra.

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Monday, November 16, 2015 11:54 AM
To: Surendra Kumar (smkumar) <[email-masked]>; Sandeep Kumar (Sandeep) Relan <[email-masked]>; [email-masked]
Cc: [email-masked]; Shahram Davari <[email-masked]>; Anoop Ghanwani <[email-masked]>; Larry Kreeger (kreeger) <[email-masked]>
Subject: Re: [nvo3] Requesting Next Protocol = 0 for Ethernet [ draft-ietf-nvo3-vxlan-gpe-01.txt ]

> I suspect some implementations may check the version even today.

It's not about checking the version number. It's that the version number is what should be used to differentiate different versions of IP, not the outer (lower) layer next-protocol field. That field should really only say "IP", i.e., not "IPv4" or "IPv6".

The reason this didn't happen for Ethernet was because of a perception that hardware would need "deep" packet information, which would be otherwise too complex to extract. That situation was true for the first year or so of deployment, but was quickly overtaken by technology capability.

Yet another reason never to make a protocol design decision for a short-term optimization.

> and v6 ? Would that be ok ?

No; I was just remarking that we should have one codepoint for IP, not different ones for IPv4, IPv6, and (eventually) whatever IP versions follow.

Whether we have one or more codepoints for IP in ethernet or other lower layers, there are already codepoints for IP "next protocol" being IP.
Unfortunately, IP makes the same error - it uses "4" for IPv4 and "41"
for IPv6; it should really have just stuck with one value.

Joe

> To: Surendra Kumar (smkumar) <[email-masked]>; Sandeep Kumar 
> (Sandeep) Relan <[email-masked]>; [email-masked]
> Cc: [email-masked]; Shahram Davari <[email-masked]>; Anoop 
> Ghanwani <[email-masked]>; Larry Kreeger (kreeger) 
> <[email-masked]>
>> On a related note, seems like the VXLAN-GPE next protocol field can 
>> do away with the new registry and re-use the IP protocol numbers:
>>> 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.
>>>
>>>  
>>>
>>> reserved flags and reserved fields.  Therefore, they will ignore 
>>> both the P-bit and the Next Protocol type field in the VXLAN GPE packet.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 16 Nov 2015 14:07:13 -0800

> Agree. I was just implying that the cost equivalent of discriminating v6/v4 via the IP.ver field may already be paid even today.
Yes, a stack must verify that the version number matches the protocol
number.The number of conditionals in the path to check protocol and
version is the same regargless of rather there are two protocol
numbers (for IPv4 and IPv6) and version number must be verified, or
one number for IP and version number is used as a discriminator.

Tom