RE: Architectural approaches to multi6

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Thu, 27 Mar 2003, Dmitri Krioukov wrote:

> After browsing through this thread I'd like
> to ask the following question: how many people
> on this list would agree that a scalable
> *engineering* solution to the multihoming
> problem can be based neither on routing as we
> know it today nor on any future improved and
> superior routing architecture (if such an
> architecture is based on the graph-theoretical
> network representation)? (I assume that any
> address binding mechanisms (similar to DNS)
> are not considered as a part of routing.)

I do, based on the premise that multihoming information to end points cannot be
transmitted via a broadcast or via a routing protocol without the transmission
being unscalable.  The goal of transmitting the information conflicts with the
goal of maintaining stability of the core.  We see the results of this in BGP
by the instability caused by route flapping and other similar events.

In my opinion, BGP represents an unstable feedback loop or system. 

Mathematically, I believe it can probably be modelled by differential equations
which ultimately have perioidic functions as solutions.  I am not even sure
that BGP can cope fully with unstable links between nodes even in a fully
aggregated network.  However an aggregated network eliminates two areas of
instability. 

The first is that in an unaggregated BGP network, when a link becomes degraded
the traffic being redirected via another path is likely to add components to
the differential equation that result in positive feedback loops. 

The second is that in an unaggregated BGP network, minor changes to the
topology need to be propagated (i.e. broadcast) to the entire network.  Aside
from the problem of all nodes requiring enough resources to process the
quantity of information, it is this widespread broadcasting which further adds
to excessive data passing from node to node and adding further complications to
the differential equation representing the whole network. 

That's my opinion.  The analysis may be flawed, so feel free to criticize.

> 
> Also, a somewhat related question: is handling
> failures beyond the links between the multihomer
> and its transit provider (such as failures of links
> between providers and the rest of the world) a
> requirement? That it is not is an implicit assumption
> of my first question. If it is (like it seemingly
> follows from the requirement ID but not from Christian's
> experiment), then a solution can only be routing-based,
> and, hence (how many would agree?), it cannot be
> scalable.
> 
> thanks,
> --
> dima.
> 
> 
> 
> 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210