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

+1. LISP is the LISP.
Lucy

-----Original Message-----
From: nvo3-bounces@ietf.org [mailto:nvo3-bounces@ietf.org] On Behalf Of Dino Farinacci
Sent: Tuesday, September 24, 2013 10:14 AM
To: Noel Chiappa
Cc: nvo3@ietf.org; lisp@ietf.org
Subject: Re: [nvo3] [lisp] New Version Notification for draft-quinn-vxlan-gpe-00.txt

For what's it worth (and for the record), I would not tradeoff the nonce for a protocol-ID. The data-plane features in LISP are far more important IMO then a protocol demux field we may never need to use.

Dino

On Sep 24, 2013, at 8:07 AM, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:

> {This is mostly to the LISP WG; NVO3 - which I candidly admit to 
> knowing almost nothing about, but which I justt joined - may or may 
> not care. Sorry this goes on for a bit, but this is important. I hope 
> people will take the time to read it - it's not _that_ long.}
> 
> 
>> From: Dino Farinacci <farinacci at gmail.com>
> 
>> the P-bit is being proposed for LISP.
> 
> For those who missed what this was all about (I sure did), there is a new ID:
> 
>  http://tools.ietf.org/html/draft-lewis-lisp-gpe-00
>  "LISP Generic Protocol Extension"
> 
> As a personal ID, this ID was not automagically announced to the LISP 
> WG; I only happened to just see it when I was updating the LISP 
> bibliography this weekend.
> 
> May I suggest that in the future, anyone posting a personal draft 
> _send a message to the WG_ - for people who are not subscibed to the 
> full ID announcement feed (I'm not, it's way too much traffic, 97% of 
> which I don't care about); otherwise, many people will have no idea that it's there.
> 
> Even better, run the basic idea through the WG _before_ you write the 
> draft; it may have a major flaw (as this one, I believe, does), or it 
> may be a direction we just don't want to go (in which case there's no 
> use putting in the effort to write an ID).
> 
> 
> To briefly let people know what this is about, it allows carriage of 
> non-IP packets in LISP. This, I think, is basically a very good idea.
> 
> However, the particular proposal in this ID is, IMO, very badly 
> flawed. It proposes to take over the field used to carry i) the nonce 
> (for neighbour xTR reachability detection), and ii) the version of the 
> mapping entry, and use that field to carry the Ethertype.
> 
> Obviously, then, since one _cannot_ carry a non-IP packet without 
> making it _impossible_ to perform either of these functions: if only 
> non-IP traffic is being carried over a particular link, these two 
> (important, IMO) control functions will be _permanently_ disabled.
> 
> I don't believe this is acceptable.
> 
> 
>>> From: Lucy yong <lucy.yong at huawei.com>
> 
>>> 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 differen[t] purposes 
>>> is not good way for the protocol evolution, it becomes messy.
> 
> Yes and no. The engineering analysis on this sort of thing is subtle.
> 
> With a limited length header, if you have several control functions 
> that do not need to be applied _on every packet_, I think it's 
> reasonable to share a field between them. One does have to carefully 
> look at the functions to decide if they really are things that one doesn't have to do on every packet.
> 
> The thing is that putting a separate field in for every possible 
> function will make the header a lot longer, which will have an impact 
> on overhead (somewhat problematic), and also MTU (even more 
> problematic, especially if MTU Discovery is not working properly).
> 
> I am given to understand that a number of organizations have hardware 
> which looks at the first two 32-bit words, so unfortunately making the 
> header longer is not available as a _short-term_ answer.
> 
> (Although I think we're just about reaching the limits of what we can 
> cram into a 2-word header, so it's probably time to start thinking 
> about a longer
> one.)
> 
> 
>> 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.
> 
> I have to tell you that I just about fell off my chair when I realized 
> what you were saying here.
> 
> I don't believe that is professionally acceptable to force users to 
> chose between i) carrying non-IP traffic, and ii) having some 
> important control functions available.
> 
> I understand that in the real world there are constraints, so we can't 
> necessarily 'clean sheet of paper' the answer; but at the same time, 
> surely it is not beyond our wit to find an answer that doesn't force 
> users into making that choice.
> 
> 
> I have some ideas on what to do here (technically), but before I 
> launch into them I would like to hear if the WG agrees with me that 
> this 'tradeoff' is unacceptable.
> 
> Because, clearly, if the WG is happy with this, there's no point in my 
> bringing up alternatives.
> 
> 	Noel
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

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