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

From: Lucy yong <[email-masked]>
Date: Tue, 24 Sep 2013 22:33:47 +0000

FYI. This reply [Lucy] did not reach to the LISP mail list before due to not being a subscriber.

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

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:[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
>> 
>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nvo3
> 
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 25 Sep 2013 16:41:08 -0400 (EDT)

> From: Fabio Maino <[email-masked]>

    > We just started from .. the lack of multiprotocol support

I don't really have a 'dog in that hunt' (i.e. a preference, for those who
aren't familiar with that US idiom). I can see how it might be useful, but
it's not like I will die of apoplexy if we don't add it.

    > For lisp-gpe, unfortunately, it comes to the expenses of the nonce and
    > versioning fields, that is certainly a higher cost to pay

But I don't think that it _is_ an un-avoidable tradeoff.

As I alluded to in my prior post, I believe a slightly different change to the
encapsulation is feasible, one which retains almost all the existing
functionality, and adds multi-protocol support.

My suggestion (based on some discussions with people, to find out what the
real-world constraints on changes are), and thinking about the various
functions and fields of the header, is to multiplex the LSB along with the
nonce and version in the field on the right of the first header word, freeing
up the 8-bit LSB field in the second header word (this is assuming the
Instance field is present, which I think it will likely be) to use for a
protocol type - in every packet.

I won't go into the analysis of flag bits and settings, but having looked at
6830 carefully, I believe they can be made to work in an upwardly compatible
way.

My position is that we don't _have_ to have the LSB in _every_ packet, any
more than we _have_ to have the nonce or version in _every_ packet. Exactly
what the 'right' mix is of the various functions (e.g. 'check the mapping
version every 10th data packet', etc), is something we'd probably want to work
out from experience.

Yes, this solution is not optimal - e.g. we have to have a translation between
16-bit Ethertype and an 8-bit protocol type - but it's _much_ better, IMO,
than the existing proposal - where we have to chose _between_ multi-protocol
support, and those important control functions.

    > we should try to see if there's a way to achieve a larger set of goals
    > of what lisp-gpe does today.

To repeat something I said elsewhere, I think we're getting close to the limit
of how many pounds we can fit in the particular 5-pound sack of the
double-word header. (For those who aren't familiar with this expression,
Google '5 pound sack'.)

Given that there are hardware implications for a longer header (which I think
we're likely to need at some point), we might want to go ahead and specify a
longer header, _without using it for anything for the moment_. Once hardware
support has made it into the pipeline, we can start to use it.

But unless we specify it _before_ we need it, we will not be able to use it
when we _do_ need it!

Hence my suggestion that we specify it now, without using it for anything.

      Noel