Re: Regionally aggregatable address space for multihoming

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 8 Jun 2001, Sean Doran wrote:

> > All networks announce their customer's routes everywhere, but peers simply
> > filter out these announcements on exchange points that do not fall within
> > their idea of the region.

> So what happens in the case where a site connects to a
> network which does not actually connect to the local
> exchange point at all?  

> X-Corp acquires geographically-assigned addresses from 
> a local registry, then buys transit from ANet and BNet; 
> ANet is connected to the local IX but BNet is not.  
> How shall BNet advertise reachability to X-Corp?

Just as I said: both ANet and BNet announce the route to X-Corp on every
exchange point anywhere in the world where they are present.

However, other networks will probably only accept these routes at the
regional exchange point and a few others in neighboring regions. So if BNet
isn't present at these exchange points other networks will have to accept
those routes elsewhere, which doesn't help the whole aggregation idea but
guarantees connectivity.

> ANet and CNet, both present at the local IX, have a
> commercial falling-out.  Or a fibre cut.  Or the IX fails.
> Or something.  This leads to a long-term outage in
> _direct_ local connectivity between ANet and CNet; however
> ANet purchases backup connectivity from DNet, one of
> CNet's peers.  Y-Corp, a customer of CNet in another city,
> now wants to send traffic to X-Corp (and vice-versa).
> How can this happen?

Since X-Corp is also a customer of DNet (through ANet) DNet will also carry
the route everywhere. Also, if BNet sells full connectivity there will be
some point where traffic from CNet can reach BNet. So X-Corp is still fully
connected and can receive traffic from Y-Corp over Y-Corp -> CNet -> DNet ->
ANet -> X-Corp or Y-Corp -> CNet -> ??? -> BNet -> X-Corp.

> The question in a nutshell, is: how does one deal with
> "exception routing" in the event one cannot guarantee a
> always fully-interconnected geographical area?

The answer is that the geographical area MUST always be fully
interconnected. This is easily accomplished by just increasing the area until
it is.

> That is, if one draws an addressing abstraction boundary
> around a geographical area rather than a topological area,
> must one/can one/how can one guarantee that the enclosed
> area can always be abstracted?

I think you assume a fixed relationship between the area where the addresses
are used and the area where the routes are known. The only relationship
necessary is that the former falls within the latter.

Obviously, the geographic region in which the addresses may be used needs to
be well-defined and must be observed by everyone. But, every network should
be free to decide where specific routes for a region may live. This can be
just the region where the addresses are used and one other for redundancy, or
the whole continent or even the whole world.

Since all networks carry customer routes everywhere, there is no need for
networks to connect within the target region. A network may pick up routes
for a multihomed New York business in Sydney if it so desires. So even if
this network only connects to the transit networks for the New York business
in Sydney, there is still connectivity. But if for some strange reason the
network in Sydney has a customer in New York, the other networks will very
likely ignore this route in Sydney, because it falls outside their idea of
the area where specific routes to New York addresses are needed. This is a
somewhat unlikely situation, but it can still work if the other networks make
an exception and accept the New York route in Sydney from this network.

It all gets somewhat complex but the good thing is it should be possible to
deploy this type of aggregation within IPv4/BGP4 without breaking anything as
long as multihomed addresses are assigned geographically.

The only real problem is that of transit networks that are so large even the
number of routes from customers and customers of customers becomes too large
for the routers.

Iljitsch van Beijnum