RE: PI/metro/geo [Re: The state of IPv6 multihoming development]

["Tony Li" <Tony.Li@procket.com>]

|   Tony Li wrote:
|   > ...
|   > Exactly.  What we want to build is a routing architecture that is 
|   > never going to have to be replaced.  It's too difficult to 
|   > reach in and change it, so you'd like it to be done right the 
|   > first time.  
|   
|   Unfortunately 'never' is a very long time, and we will 
|   continue to do
|   nothing while we wait for the answer. 


Tony,

No one is proposing that we wait for the perfect answer.  The only
question is how long it will be before we can reach consensus.  

We need to decide which is more important: the scalability and durability
of the routing subsystem or the convenience of non-connection based 
addressing.  When we have consensus on this point, then all else will
follow.

|   > Since scalability is key and the way to scale is 
|   > to keep the overhead low, a solution that has higher overhead 
|   > is sub-optimal and to be avoided.
|   > 
|   > Geographic aggregation is fine if the topology does indeed 
|   > provide a convenient aggregation boundary.  But in many 
|   > cases, there will be no 
|   > such convenient boundary.  What do you do?  You cannot make 
|   > an exception and flat route any enterprise that has such 
|   > links, because then their overhead dominates the cost of all 
|   > routing and you're not sufficiently scalable.
|   
|   This point is arguable, because it is making a blanket 
|   statement about a
|   process with multiple causes. For the truly global enterprise with
|   multiple exposure points and global internal network that 
|   could handle a
|   route shift, why not? There are fewer than 11,000 toady as 
|   evidenced by
|   the number of AS's injecting prefixes into BGP. (I suspect the real
|   number is less than 2,000 that could deal with taking a full traffic
|   load at multiple points) The real problem is that there is 
|   no clear way
|   to say one organization can while another can't. For the 
|   case where an
|   enterprise is simply looking for better/cheaper service in a remote
|   region, we are into economic rather than technical arguments. These
|   organizations aren't concerned about their impact on routing, so the
|   only way to deal with them is to give them the level of service they
|   need while making it cheaper to constrain the topology than it is to
|   blow out the tables. 


The fact that there are already 11,000 today should concern us greatly.
If the rate of such sites continues to grow proportionally to the size
of the network, we'd be looking at unsustainable exponential growth in
the DFZ.  If it helps, you might recall that the DFZ about 10 years ago
was only about 5K routes.  Multiplying by 20X has been painful.

For organizations that are looking for better/cheaper or (more likely)
diverse service, I think that you'll agree that we do want to find
a way to provide them service.  If we simply try to constrain the 
topology, then we will simply be ignored.  People will use the technology
in the way that is to their benefit, not necessarily to the benefit of
the whole.  Game theory 101.

What we must do is to give them a technological mechanism that provides
their needs, meets their cost goals and simultaneously allows us to have
a lasting routing architecture.  I believe that we have that option
staring us in the face in the form of GSE (possibly with some tweaks), but
we need to get past our ideological differences and move forward to a true
engineering solution.

Will you help?

Tony