Re: Regionally aggregatable address space for multihoming

[Tony Li <tli@Procket.com>]

 | Let's see if we can agree on the problem:
 | 
 | The large number of multihomed network is responsible for growth of the
 | routing table, which we don't want because:
 | 
 | - it takes too much CPU power to process routing updates
 | - it takes too much memory to store the table
 | - it takes too much CPU power to look up routes when forwarding packets
 | 
 | Is stopping the routing table growth the best way to address these
 | problems? 


Some fine points:

- We will never actually 'stop' routing table growth.  It will continue.
  The question is the rate.
- We would very much like to keep that rate below Moore's law.  It will
  become exceedingly painful if and when it exceeds Moore's law.  The
  hardware will simply fail to keep up.


 | If so, the next step is to choose an approach, such as:
 | 
 | - not allowing or restricting multihoming the way it is done now
 |   This means we need alternatives, such as a good way to select the best
 |   address when a host has more than one and ways for higher layers
 |   to survive address changes.
 | 
 | - find a way to aggregate multihomed routes
 |   On what should we aggregate? Topology, geography?
 | 
 | - ???


We already have a unicast routing architecture for V6 that dictates how
aggregation is to be performed.  The goal of this WG is to decide on a
strategy for how do deal with multihomed sites in some way other than what
we do today (global visibility of all multihomed sites without any
aggregation).  

There are two proposals on the table:

      - GSE
      - multiple addresses

The goal of this WG is to decide on one, without bloodshed, in less than an
epoch.  So far, things aren't looking good.


 | I think the discussion so far shows that each approach has serious
 | drawbacks, but just waiting until the perfect solution comes along
 | doesn't seem to work either. So we need a way to select a best approach
 | in lieu of a perfect one.  What do we value more? Effectiveness?
 | Efficient operation? Simplicity?  Compatibility with current practices?
 | How can we evaluate all of this if we don't make assumptions about the
 | future of the Internet?


This is supposed to all be captured in the (alleged) requirements document.

Tony