Re: Regionally aggregatable address space for multihoming

[Geoff Huston <gih@telstra.net>]

At 6/19/01 07:35 AM, Joe Abley wrote:
> > 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:
>
>Is it just multi-homing that is at the source of the issue? What
>about the prefix-based inter-AS traffic engineering that Geoff
>alluded to in Minneapolis?

Obviously the two are associated in some way.

Once you have multiple connections the next motivation is to increase your 
efficiency - having one circuit packed to the brim with data and the other 
idle is not very efficient - if there is minimal incremental additional 
cost involved, the next step is to attempt to balance your normal inflow 
and outflow across the multiple circuits. Because there is no direct cost 
associated with advertising prefixes into the global routing table, and 
because advertising fine-grained prefixes selectively down particular paths 
achieves the objective of incoming traffic engineering, folk do it.


>What I mean is: suppose the multi-homing problem could be solved
>such that the the pervasiveness of multi-homing had no impact on
>the amount of state held in the DFZ. Would there still be a state
>problem to solve?


The problem of traffic engineering is quite a challenging one: what you are 
attempting to do is to force remote systems to make a particular choice as 
to what paths are used to reach _you_  - its the reverse of the normal TE 
process. Now how do you communication that information to the remote system 
in a way that manages to constrain the choices available to the remote 
system to match your desired policy? Somehow theres an information transfer 
that has to happen. If its not the routing system then another information 
passing architecture is needed in addition to routing. i.e. you cannot 
'solve' this problem by attempting to finesse thelast mile in a regional 
space - there remains a larger issue that must also be addressed.

>To what extent can we deduce the problems that edge sites are
>trying to solve?
>
>The analysis I have seen to date tries to make deductions from
>snapshots of the state in the DFZ, as viewed from various
>different angles. It occurs to me that there is a limited toolbox
>available for edge sites to accomplish a number of things. Being
>able to hear someone hammering in the distance doesn't tell you
>what they are trying to build :)


The bgp architecture draft I wrote and the March IETF plenary presentation 
attempted to highlight this. There is the constant sound of hammering and 
the BGP tables reflect this. If you want the routing system to deal in only 
AS-based connectivity then you can limit the stress in the routing tables 
BUT you also have to work out how to overlay policy / TE onto of this 
connectivity fabric, and thats the bit which I believe is the tricky one.

   Geoff