+1. LISP is the LISP.
Lucy
-----Original Message-----
From: nvo3-boun...@ietf.org [mailto:nvo3-boun...@ietf.org] On Behalf Of Dino
Farinacci
Sent: Tuesday, September 24, 2013 10:14 AM
To: Noel Chiappa
Cc: n...@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, j...@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
n...@ietf.org
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
