The fact that LISP does help in IPv6 Transition solutions (due to its
inherent AF agnostic design), is compelling. As you say, real edge 2 edge is
the goal - and LISP helps here, regardless of the AF. (you'll will still
want to do multi-homing in IPv6, and ingress TE, and mobility, etc.).
Sorry, when i said e2e w.r.t IPv6 i was talking about end to end, not
edge to edge. I think there is a big difference.
Oops, i meant end to end too, don't know why I typed edge2edge.
IMHO, ILNP is the more interesting solution and avoids expensive
encapsulation and questionable assumptions about ISP MTU, all my ISP
links are GigE and 10GigE and they are all set to default 1500 bytes
... good or bad, this is just how they roll off the line from every
ISP in every city i buy transit... and LISP tunnels do not work so
well with 1500 byte MTU.
I beg to differ, LISP works excellent with 1500 byte MTU. But you point out
a significant aspect of LISP; hosts behind LISP rely a bit on path MTU
discovery, with all it's benefits and drawbacks. But that's not a show
stopper i've seen on the lisp beta network. We live in a world where PMTUD
is daily practice, ILNP will not make PMTUD go away.
My major concern with ILNP is that eventually all hosts need to be
upgraded/changed to take advantage of ILNP. If we take a hard look at
something like SCTP... it never was really populair in the wild even though
it's in the Linux kernel. I'd rather load new software on hundreds CPE's
then change ten thousands of hosts, with all variations, versions,
servicepacks. Another example: the rate at which IPv6 has been adopted in
operating systems is horrible, we cannot wait another 10 or so years.
So I actually consider it one of the best features of LISP that hosts don't
need to be changed and the scope has been reduced to just the 'edge' or
'CPE'. In this sense one might even consider LISP to be more backwards
compatible then ILNP.
Last, ILNP has no viable plan for IPv4, an address family we cannot easily
discard. The critique in draft-irtf-rrg-recommendation-14 on ILNP's hIPv4 is
heavy, and can be summerized with: "It appears that hIPv4 involves major
practical difficulties which mean that in its current form it is not
suitable for IETF development.."