Re: plug: thesis on site multihoming

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

On zondag, maa 30, 2003, at 18:23 Europe/Amsterdam, Pekka Savola wrote:

> > I'm afraid that my geo proposal has again been mangled beyond
> > recognition. Let me say it once more: NOBODY announces the aggregates
> > (except maybe to customers). They are local to each ISP network, hence
> > the "provider-internal aggregation" part.
> And as I've said before, I fail to see how it actually solves the 
> relevant
> multihoming problem then :-).  Clearly this seems to be somethng that
> needs to be said more clearly.. Having geographical addresses that are
> specific to an ISP is a complete non-solution,
You don't say.

"To make multihoming (as we know it today) possible, individual routes
must be present in the global routing table. But in order to fit the
routing table into a router, there must be aggregation. These
requirements seem at odds with each other. This is because there is an
unspoken assumption: the full global routing table must be present in
all routers that are part of the default-free zone. Dropping this
requirement makes everything much more complex, but it is possible. The
global routing table can then be split into several parts, where
individual routers all handle one (or a few) of those parts.

This works as long as traffic for a certain subset of the destination
networks present in the global routing table is always sent to a router
containing that part of the global routing table. The obvious way to
accomplish this is for each router to announce an aggregate covering the
part of the global routing table it serves. For instance, if a network
has four routers and wants to divide routing information for the IPv6
global unicast address space over those routers, it could have router A
handle 2000::/5, router B 2800::/5, router C 3000::/5 and router D
3800::/5. So if this network peers with another network that announces
2200:abc::/35 and 3ffe:def::/35, all routers except router A filter out
the first route, and all routers except router D filter out the second
route. When router C then has a packet for 2200:abc:1:2::1, it sends the
packet to router A (because router A announces the 2000::/5 aggregate)
and router A delivers the packet to the right peer. Note that this
behavior is completely hidden from the peer: the aggregates are only
used within the local network, they are not announced to peers. To avoid
confusion with regular provider aggregatable routes, the term "pilot
routes" will be used for this type of private aggregates."