Subject: [nvo3] Fwd: New Version Notification for draft-quinn-vxlan-gpe-00.txt

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Fri, 6 Sep 2013 22:04:28 +0000

FYI for the group.  

Paul

Begin forwarded message:
> 
> A new version of I-D, draft-quinn-vxlan-gpe-00.txt
> has been successfully submitted by Paul Quinn and posted to the
> IETF repository.
> 
> Filename:	 draft-quinn-vxlan-gpe
> Revision:	 00
> Title:		 Generic Protocol Extension for VXLAN
> Creation date:	 2013-08-27
> Group:		 Individual Submission
> Number of pages: 13
> URL:             http://www.ietf.org/internet-drafts/draft-quinn-vxlan-gpe-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-quinn-vxlan-gpe
> Htmlized:        http://tools.ietf.org/html/draft-quinn-vxlan-gpe-00
> 
> 
> Abstract:
>   This draft describes a mechanism for adding multi-protocol support to
>   Virtual eXtensible Local Area Network (VXLAN).  Protocol
>   identification is carried in the VXLAN header and is used to describe
>   the encapsulated payload.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Lucy yong <[email-masked]>
Date: Fri, 6 Sep 2013 22:20:44 +0000

Hi Paul,

I read this draft. Both this draft and our draft http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/ propose adding prototype type field in VXLAN header in supporting L3 overlays (or other) beside L2 overlays. The only difference between two is that this draft requests using P bit to indicate the presence of protocol type field in VXLAN header. We don't think this is necessary. For the backward compatibility, we propose treating protocol type value 0 as Ethernet payload. 

This draft gives two ways to do L2 overlay. If P bit is set and protocol type value 0x6558, L2 payload is follow, or P bit is unset, L2 payload is follow. IMHO, this is bad.

Regards,
Lucy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Friday, September 06, 2013 5:04 PM
To: [email-masked]
Subject: [nvo3] Fwd: New Version Notification for draft-quinn-vxlan-gpe-00.txt

FYI for the group.  

Paul

Begin forwarded message:
> 
> A new version of I-D, draft-quinn-vxlan-gpe-00.txt has been 
> successfully submitted by Paul Quinn and posted to the IETF 
> repository.
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 

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

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 10 Sep 2013 02:03:29 +0000

Lucy,

Thank you for your comments.

The P bit provides much needed flexibility for the protocol.  First and foremost, it enables the creation of a single on the wire protocol that encompasses both VXLAN and LISP (please see http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 for the associated LISP draft).  The P bit also enables the evolution of the protocol, allowing the format to change as needed with a simple bit change.

Thank you,
Paul

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 10 Sep 2013 03:06:34 +0000

Hi all,

First, I'm glad to see that more and more people have realized the need for a protocol type field in the VXLAN header since I mentioned that need one year ago (http://list-archives.org/2012/09/21/nvo3-ietf-org/unified-encapsulation-headers-for-both-layer2-and-layer3-vpn-overlays/f/6013985816).

Second, I guess most people who have realized the above need would agree that the protocol type field would be a necessary field (like the Protocol Type field in the GRE header), rather than an optional field (like the Checksum field in the GRE header) in the long run. Both the usage of P bit as described in your draft and the interpretation of 0x0000 in the Protocol Type field as Ethernet payload as described in our draft are just intended for backward compatibility to the early implementation of the pre-standard VXLAN. In order to reduce the potential risk of compatibility in the future, I feel it'd better for the NVo3 WG to make an early decision upon such extension to VXLAN before the WG adoption of the existing VXLAN data format. 

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Paul
> Quinn (paulq)
> 发送时间: 2013年9月10日 10:03
> 收件人: Lucy yong
> 抄送: [email-masked]
> 主题: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt
> 
> Lucy,
> 
> The P bit provides much needed flexibility for the protocol.  First and foremost,
> it enables the creation of a single on the wire protocol that encompasses both
> VXLAN and LISP (please see http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 for
> the associated LISP draft).  The P bit also enables the evolution of the protocol,
> allowing the format to change as needed with a simple bit change.
> 
> Thank you,
> Paul
> 
> 
> > I read this draft. Both this draft and our draft
> http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/ propose
> adding prototype type field in VXLAN header in supporting L3 overlays (or other)
> beside L2 overlays. The only difference between two is that this draft requests
> using P bit to indicate the presence of protocol type field in VXLAN header. We
> don't think this is necessary. For the backward compatibility, we propose
> treating protocol type value 0 as Ethernet payload.
> >
> > This draft gives two ways to do L2 overlay. If P bit is set and protocol type
> value 0x6558, L2 payload is follow, or P bit is unset, L2 payload is follow. IMHO,
> this is bad.
> >
> > Regards,
> > Lucy
> >
> >
> >
> >> URL:
> http://www.ietf.org/internet-drafts/draft-quinn-vxlan-gpe-00.txt

---

From: Lucy yong <[email-masked]>
Date: Tue, 10 Sep 2013 15:46:18 +0000

Paul,

I am not sure applying P bit in LISP header will address the backward compatibility in LISP. The lisp-gpe draft does not address how LISP-gpe router handles the packet when receiving it from LISP router with N,E, or V bit set.  Furthermore, the statement of "The receiving (legacy) LISP router will ignore N, E and V bits, when the P bit is set." in the draft indicates the request of change on legacy LISP router.

Regarding to the protocol evolution, does this mean that nonce/map-version features in LISP will be deprecated?  IMO: Having the same field overloaded for many difference purposes is not good way for the protocol evolution, it becomes messy.

Regards,
Lucy

-----Original Message-----
From: Paul Quinn (paulq) [mailto:[email-masked]] 
Sent: Monday, September 09, 2013 9:03 PM
To: Lucy yong
Cc: [email-masked]
Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Lucy,

Thank you,
Paul

On Sep 6, 2013, at 3:20 PM, Lucy yong <[email-masked]> wrote:

>>  This draft describes a mechanism for adding multi-protocol support 
>> to  Virtual eXtensible Local Area Network (VXLAN).  Protocol

---

From: Lucy yong <[email-masked]>
Date: Tue, 10 Sep 2013 15:50:38 +0000

+1

Lucy

-----Original Message-----
From: Xuxiaohu 
Sent: Monday, September 09, 2013 10:07 PM
To: Paul Quinn (paulq); Lucy yong
Cc: [email-masked]
Subject: re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Hi all,

Best regards,
Xiaohu

> The P bit provides much needed flexibility for the protocol.  First 
> and foremost, it enables the creation of a single on the wire protocol 
> that encompasses both VXLAN and LISP (please see 
> http://tools.ietf.org/html/draft-lewis-lisp-gpe-00 for the associated 
> LISP draft).  The P bit also enables the evolution of the protocol, allowing the format to change as needed with a simple bit change.
> 
> Thank you,
> Paul
> 
> 
> http://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/ 
> propose adding prototype type field in VXLAN header in supporting L3 
> overlays (or other) beside L2 overlays. The only difference between 
> two is that this draft requests using P bit to indicate the presence 
> of protocol type field in VXLAN header. We don't think this is 
> necessary. For the backward compatibility, we propose treating protocol type value 0 as Ethernet payload.
> >
> value 0x6558, L2 payload is follow, or P bit is unset, L2 payload is 
> follow. IMHO, this is bad.
> >
> > Regards,
> > Lucy
> >
> >
> >
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of
> Paul Quinn (paulq)
> >> identification is carried in the VXLAN header and is used to 
> >> describe  the encapsulated payload.
> >>
> >>
> >>
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 08:55:30 -0700

> Regarding to the protocol evolution, does this mean that nonce/map-version features in LISP will be deprecated? IMO: Having the same field overloaded for many difference purposes is not good way fo…

No it does not mean that. It means that the features need to be traded off. So the market/user-base will decide what it wants to use that field for.

Dino

---

From: Lucy yong <[email-masked]>
Date: Tue, 10 Sep 2013 16:09:10 +0000

This implies that both gpe LISP and legacy LISP may be used in the market. Is that true only IP-in-IP application need nonce feature? Mobility is important requirement for cloud applications, so gpe LISP needs to develop other solution for this feature? Sorry, this is a hard sale.

Regards,
Lucy

-----Original Message-----
From: Dino Farinacci [mailto:[email-masked]] 
Sent: Tuesday, September 10, 2013 10:56 AM
To: Lucy yong
Cc: Paul Quinn (paulq); [email-masked]
Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 09:11:37 -0700

> This implies that both gpe LISP and legacy LISP may be used in the market. Is that true only IP-in-IP application need nonce feature? Mobility is important requirement for cloud applications, so gp…

If you use IP-in-IP you don't need to set the P-bit, making the nonce available for use. Yes, there are applications where the nonce is useful.

Dino

---

From: Lucy yong <[email-masked]>
Date: Tue, 10 Sep 2013 16:16:24 +0000

If you use IP-in-IP you don't need to set the P-bit, making the nonce available for use. Yes, there are applications where the nonce is useful.
[Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will not support that. Why do we want to remove this in the protocol evolution? 

Lucy

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 10 Sep 2013 10:19:23 -0700

Copying the LISP working group mailing list.

> [Lucy] Yes, I agree that the nonce is useful. But gpe LISP router will not support that. Why do we want to remove this in the protocol evolution? 

Lucy, we are not removing anything. Like I said (and I don't want to continually repeat myself) that the features are tradeoffs.

The motivation for the change was to get VXLAN to have protocol demuxing. And in the spirit of keeping the packet formats for VXLAN and LISP as identical as VXLAN will have it, the P-bit is being proposed for LISP.

This is a proposal. The LISP working group must decide if the draft becomes a working group document.

Dino

---

From: Lucy yong <[email-masked]>
Date: Tue, 10 Sep 2013 18:18:25 +0000

The motivation for the change was to get VXLAN to have protocol demuxing. 
[Lucy] For VXLAN to support protocol demuxing, no need to use P bit. We have the proposal (https://datatracker.ietf.org/doc/draft-yong-l3vpn-nvgre-vxlan-encap/).

And in the spirit of keeping the packet formats for VXLAN and LISP as identical as VXLAN will have it, the P-bit is being proposed for LISP.
[Lucy] This logic means that if VXLAN does not need P bit, LISP does not have to have it either, right? It also indicates that you do not see the applications for gpe LISP router, is that right? IMO: LISP and VXLAN have different UDP port numbers, which is sufficient to differentiate the two.

This is a proposal. The LISP working group must decide if the draft becomes a working group document.
[Lucy] People need carefully evaluation this proposal impact on LISP. 

Regards,
Lucy

Dino