Copying the LISP working group mailing list.

>> 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.
> 
> 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, 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. 
[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

> 
> Lucy
> 
> Dino
> 
>> 
>> Regards,
>> Lucy
>> 
>> 
>> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:farina...@gmail.com] 
>> Sent: Tuesday, September 10, 2013 10:56 AM
>> To: Lucy yong
>> Cc: Paul Quinn (paulq); n...@ietf.org
>> Subject: Re: [nvo3] New Version Notification for draft-quinn-vxlan-gpe-00.txt
>> 
>>> 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.
>> 
>> 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
>> 
>> _______________________________________________
>> nvo3 mailing list
>> n...@ietf.org
>> https://www.ietf.org/mailman/listinfo/nvo3
> 
> _______________________________________________
> nvo3 mailing list
> n...@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to