North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: What is the limit? (was RE: multi-homing fixes)

  • From: Andrew Partan
  • Date: Wed Aug 29 23:17:11 2001

On Wed, Aug 29, 2001 at 08:38:31PM -0400, Leo Bicknell wrote:
> 1) More power in routers.

This is useful and may give us enough time to get something better
in place.  But note that this only tackles the routing engine (the
part that deals with such things like BGP & ISIS updates).  The
other part - the big fast forwarding engines - is where things are
already getting very tricky.  I suspect we may hit the edge in the
forwarding engines first.

> 2) Modification to registry allocation procedures to allow entities 
>    a greater probability of having a single large block.  (Basic goal,
>    reduce the number of prefixes per AS.)

Ohh!  Renumbering!  If everyone renumbered such that there was one
prefix per AS at (nearly) all times, then we would be in a *much*
better position.

The only known way to really make routing systems scale is to have
the stuff the routing system deals with (the routing goo) match
closely the topology of the system.  If we could split the current
'address' into host identifiers and routing goo, then I suspect we
would be a lot better off.

>    A) State caching (so many changes are oscillations, why do a full
>       recompute each time).

Yup - see the various I'll Be Back work and the like.

>    B) Limiting the propagation of routes.  Many of the "TE" routes 
>       today need to go to a small subset of the AS's that they reach
>       today.

This is hard - its very hard to tell how far a route really needs
to propogate.  The NOPEER work has some potential here.

>    C) Prioritizing updates.

How?  Needs much thought here.

>    B) Many routing updates can happen much more slowly, particularly

Aka route dampening.  Query - how many ISPs use the RIPE dampening

>    C) There is no reason to withdraw a route (from the FIB at least,
>       perhaps from some part of the RIB) if there is no alternative
>       path.  Routing to a black hole is routing to a black hole.

I suspect that this case only covers a small number of routes.  I
suspect that most routes have some covering aggregate; thus there
is nearly always someplace else for the traffic to go.

>    I) Potentially introduce hierarchy into the routing system.

This is going to be needed.

>    K) Routing out of band can sometimes be more efficient.

I can tell you lots of horror stories about this.  Trying to push
traffic one way while the routing goes another can lead to undetected
black holes.  Not pretty.

>    A) Do more fail over via DNS, web redirects, and other systems.
>       Reduce the dependency on the routing system for those tasks.

Howard Berkowitz is writting an informational draft on this sort
of thing; please give him feedback.

>    B) Have service providers bilaterally share IP space, and only
>       deaggreate to each other to provide for redundant customers.

That would seem to require the ISPs deeply cooperate with each
other...  Dunno if that is ever really going to happen.

>    C) Provide better support for 'floating IP' services (where the
>       same IP 'exists' in multiple places at the same time.

That already works pretty well (anycast addresses).  Problems I've
seen with it have been detecting failures (see aroot experiment).
You need really good monitoring systems in place to keep this sort
of stuff working.

	[email protected] (Andrew Partan)