Implementations/suggestions for Multihoming IPv6 for DSL sites

Leo Bicknell bicknell at ufp.org
Mon Apr 18 19:50:26 UTC 2011


In a message written on Mon, Apr 18, 2011 at 08:44:03PM +0200, Lukasz Bromirski wrote:
> LISP scales better, because with introduction of *location*
> prefix, you're at the same time (or ideally you would)
> withdraw the original aggregate prefix. And as no matter how
> you count it, the number of *locations* will be somewhat
> limited vs number of *PI* address spaces that everyone wants
> do drag around the world and advertise in a number of places,
> specially with IPv6. And that's exactly what LISP had in
> mind - to prevent massive explosion of FIB for IPv6.

I would agree with this statement if and only if you qualified it
with "for the default free zone (DFZ)".

LISP reduces the number of routes in the DFZ by making each route
represent a "location".  However, like the proverbal balloon, when
squeezed on one end the other side gets larger.

LISP does this by introducing an entirely new infrastructure, the
mapping servers.  These must now scale to meet the demands that
will be placed on them.

LISP also does this by making the edge box responsible for looking
up and caching information on the flows going through it.

In this way LISP, on a worldwide basis, very closely resembles a
Cisco 7500 Chassis circa 1996 with "flow caching".  The mapping
servers are the RP, the DFZ is the backplane, and the edge boxes
are the linecards.

In both designs when the first packet comes in a lookup is made to
the central authority, and a cache entry is placed down at the entry
processor.  The backplane is dumb and fast.  Anyone familar with
then enviornments where a 7500 performed poorly should be able to
immediately detect where a LISP architecture will perform poorly.

Any events which invalidate the cache will result in a period of
extremely high usage on the mapping servers likely with extremely
high packet loss until all entries are resolved.

Any edges which talk to a significant number of other networks will
have to cache a significant portion of the Internet, which will
actually lead to edge boxes having to be larger than they are now.

It is the last point I find most interesting about LISP.  Today
someone who wants to route their own address space at 10G can buy
any number of cheap L3 devices with enough RAM and CPU to hold the
internal routes and a default pointed at their provider.  The
provider's boxes keep the full table and move the packets to where
they need to go.

In a LISP world that edge box would be set up to do map/encap, and
thus would need to keep cache entries for all active addresses,
which for a busy site is potentially the entire table.  The service
provider box now no longer needs to know about all destinations,
and thus can have a smaller table or be upgraded less often.  [Note,
while I describe the edge here as customer owned, it's entirely
possible it may be ISP owned and managed for the customer, a cost
of which I'm sure they would fully pass on.]

To my mind then, LISP moves these tables from a few thousand DFZ
routers managed (generally) by well staffed engineering teams to
tens or hundreds of thousands of edge boxes, in many cases managed
by the clueless.  Many edge proponents will say it's easier to
upgrade the edge than the core, so this is a win.  Vendors may like
the idea of 100,000 boxes needing the resources to hold most of a
table, rather than 1,000.

If the Internet had started out with a LISP design from scratch I'm
not sure it would be any better, or worse than our current
configuration.  Back to the balloon, it trades cost and complexity
in one area for cost and complexity in another area.  In that sense
I am neither against it nor for it, it's just 'different'.

The problem is we don't live in a LISP world.  To go there now would
be a wholesale conversion from what we are doing.  Granted, the
LISP folks have designed something that is relatively easy to convert
to, so they are making an effort.  Still, to justify a conversion
and the engineering time and business risk it would have to be
significantly better.  Like 2x-4x better, and preferably an order
of magnitude.  That's where I'm just not seeing it with LISP, yet.

I hope the LISP guys keep working on this, they are at the moment
the only credible alternative I've seen to our current system in
my lifetime.   It's just not good enough to justify a switch based
on the current world conditions and state of the solution; at least
to me.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20110418/768b5075/attachment.sig>


More information about the NANOG mailing list