{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
