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
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
