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

Leo Bicknell bicknell at ufp.org
Thu Aug 30 00:38:31 UTC 2001


On Wed, Aug 29, 2001 at 04:41:17PM -0700, Sean M. Doran wrote:
> There's lots of irony in that too.   Other than the hand-wave,
> how do you propose to get (and stay) ahead of it?

Take your pick, having people working on all of them would be a
good plus.

1) More power in routers.

   A) Faster CPU's.
   B) More memory.
   C) More bandwidth in and out of the route processor.
   D) Multiprocessor designs.

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.)

3) Enhancements to current routing protocols (short term bandaids).

   A) State caching (so many changes are oscillations, why do a full
      recompute each time).
   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.
   C) Prioritizing updates.

4) New routing protocols, possibly using one or more of the following
   ideas / observations:

   A) The topology of the network is relatively static.  That is
      links go up and down, but in general don't move.
   B) Many routing updates can happen much more slowly, particularly
      if it makes some updates happen more quickly.  For instance,
      when two big providers bring up a new peering link, if that
      takes 45 seconds to propagate rather than 10, that's ok.
      When a link fails and there is a reroute, it should happen
      as quick as possible.
   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.
   D) Routes will always need to be carried for traffic engineering
      purposes.  Provide mechanisms to control them.
   E) Inside of a single domain of control a protocol could 'share
      processing' across the network.
   F) Routing protocols that can take advantage of multiple CPU's
      are a good thing.  Allowing them to be distributed across the
      network (in a more equitable fashion) may be useful.
   G) Offloading some route calculations may be useful.  (Thinking
      about moble users going through a 'slow' (1-10 second) secondary
      routing fabric on their first connection in a new location).
   H) Cache redundant calculations.  When there are 10 deaggregated
      routes in a row, do the O(complex) calculation first, and an
      O(1) lookup for the next 9.
   I) Potentially introduce hierarchy into the routing system.
   J) Sometimes keeping more state means doing less computation
      (and sometimes the opposite).
   K) Routing out of band can sometimes be more efficient.

5) New offloading protocols, systems, and service offerings:

   A) Do more fail over via DNS, web redirects, and other systems.
      Reduce the dependency on the routing system for those tasks.
   B) Have service providers bilaterally share IP space, and only
      deaggreate to each other to provide for redundant customers.
   C) Provide better support for 'floating IP' services (where the
      same IP 'exists' in multiple places at the same time.
   D) Make customers care less about their IP addresses.  (Eg, move
      web servers closer to the core, leaving only access at the edge,
      allowing everything to outgoing NAT.)
   E) Sometimes 'burning into ROM' (or semi-permanent routing)
      is a good thing, many things are not dynamic, don't treat
      them as such.
   F) Authenticating routing information is a good thing, even if
      it doesn't happen in real time.
   G) Being able to get route attributes that allow you to tune
      priority and the like is a good thing, even if it doesn't 
      happen in real time.
   H) QOS controls might be better applied to routing updates than
      to traffic.

I'll work on some more ideas, that should keep people busy (and
the debate hopping) for some time.

-- 
Leo Bicknell - bicknell at ufp.org
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org



More information about the NANOG mailing list