mailing list archives
Re: Implementations/suggestions for Multihoming IPv6 for DSL sites
From: Owen DeLong <owen () delong com>
Date: Mon, 11 Apr 2011 11:03:11 -0700
On Apr 11, 2011, at 9:19 AM, Jeff Wheeler wrote:
On Mon, Apr 11, 2011 at 11:26 AM, Owen DeLong <owen () delong com> wrote:
I'd agree with you if it weren't for the fact I keep thinking I just about understand LISP and then get told
that my understanding is incorrect (repeatedly).
I agree it is not simple.
At a conceptual level, we can think of existing multi-homing practices
as falling into one of three broad categories:
1) more state in DFZ -- end-site injects a route into BGP
Yep... This is clearly the best currently available mechanism.
2) triangular routing -- tunnel/circuits/etc to one or more upstream
routers while not injecting anything to DFZ
I think what I am currently doing is a form of 1.5 for lack of a better
term. I have multiple tunnels to multiple providers over multiple
3) added work/complexity on end-host -- SCTP and friends
Ah, yes, I think SHIM6 shows up here, too, no?
LISP is a compromise of all these things, except #3 happens on a
router which does tunneling, not the end-host. Whether you think it's
"the best of both [three?] worlds," or the worst of them, is up to
I'm not convinced one way or the other yet since I haven't been able
to wrap my (admittedly perhaps limited) brain around LISP well
enough to become convinced I understand it enough to make said
I do tend to think that any technology sufficiently confusing that I cannot
understand it well after reasonable effort is of questionable value
for wide deployment.
I personally believe LISP is a horrible idea that will have trouble
scaling up, because a large table of LISP mappings is not any easier
to store in FIB than a larger DFZ. The "solution" the LISP folks
think works for this is a side-chain mapping service which the router
can query to setup encapsulation next-hops on-demand, which means if
your FIB isn't big enough to hold every mapping entry, you are
essentially doing flow-based routing, but with "flows" defined as
being toward a remotely-defined end-site rather than toward an
individual IP address (so not quite as bad as "flow-based routing" of
the past, but still bad.)
This is one of the few parts of LISP I do understand and I'm not entirely
convinced that it is all that bad because you don't have to do this on
core routers, you can push it out pretty close to the customer edge,
possibly even on the customer side of said edge.
Maybe I also don't understand LISP and need to RTFM more, but my
current understanding is that it is a dead-end technology without the
ability to dramatically scale up the number of multi-homed end-sites
in a cheaper manner than what is done today with BGP.
I'm not 100% convinced of that.
I think we would be better off with more work on things like SCTP.
I'm not a fan of SCTP, and I think getting enough application level support
for it is going to be a bigger uphill battle between chickens and eggs
than the IPv6 deployment efforts of the last 5 years.