nanog mailing list archives

Re: in defense of lisp (was: Anybody can participate in the IETF)


From: steve ulrich <sulrich () botwerks org>
Date: Wed, 13 Jul 2011 10:20:59 -0500

On Wed, Jul 13, 2011 at 10:07 AM, Cameron Byrne <cb.list6 () gmail com> wrote:
On Jul 13, 2011 7:39 AM, "Scott Brim" <scott.brim () gmail com> wrote:

On Wed, Jul 13, 2011 at 10:09, Randy Bush <randy () psg com> wrote:
btw, a litte birdie told me to take another look at

6296 IPv6-to-IPv6 Network Prefix Translation. M. Wasserman, F. Baker.
    June 2011. (Format: TXT=73700 bytes) (Status: EXPERIMENTAL)

which also could be considered to be in the loc/id space

randy

No, that's a misuse of "loc/id" since no identification is involved,
even at the network layer -- but it is in the "reduce issues in global
routing and local renumbering" space (that's part of what LISP does).

Cameron: As for ILNP, it's going to be difficult to get from where
things are now to a world where ILNP is not just useless overhead.
When you finally do, considering what it gives you, will the journey
have been worth it?  LISP apparently has more benefits, and NPT6 is so
much easier -- particularly if you have rapid adaptation to apparent
address changes, which many apps have and all mobile devices need
already -- sorry but I don't think ILNP is going to make it.  You
can't just say "the IETF should pay more attention".  I've invited
people to promote it and nobody stepped up.


"Difficult" depends on your time horizon. Ipv6 is/was difficult. Sctp is
difficult, but I remain bullish on its value. ILNP may be more difficult,
but i believe it is strategically correct.

We can disagree on merits of competing RESEARCH  topics. I am just providing
"ops feedback ", to bring this thread full circle.

Lastly, we must make sure that LISP does not become the next 6to4 where good
intentions for RESEARCH  become a quantifiable network nightmare.

i would agree that LISP hasn't necessarily improved the root problem
posed.  however, on this front nor it hasn't done any harm. the
intriguing elements with LISP for me personally, are in all of the
adjunct capabilities that a L/I split enables.  there are some very
valid and interesting applications that this enables and some novel
technology capabilities that are exercised. (useful endpoint mobility,
novel load balancing, encap data plane liveness, etc.) researching and
getting our hands dirty as an industry with these technologies has
considerable value.  without actually poking at running code and
pushing bits over these interfaces we run the risk of letting the
perfect be the enemy of the good.  i like the fact that this research
let's us gauge how far from perfect the current state of the art is.

fwiw - while there are folks that see LISP as an impending ops
nightmare (if you don't like it, don't use it.) there are a number of
folks for whom it provides compelling solutions to real problems that
they have and they're keen on using it to solve those problems or
explore the solution space. to that end i don't know that we need to
make sure that LISP doesn't become anything.  we need to find
solutions to problems and rationally explore those solutions and
incrementally enhance them.

yes. i participate in the LISP research test bed in my (very) small way.

-- 
steve ulrich (sulrich@botwerks.*)


Current thread: