provider-int geo aggr [Re: plug: thesis on site multihoming]

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote:
> "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.

All routers inside an ISP certainly don't need to have full routing table, 
but if *one* or those with external connections to DFZ don't, you might 
end up in problems.

If you want to remove full routing table from an AS that's in routing 
table -- well, that may be doable to an extent, but I'm not sure how it 
helps, and that's not explicitly stated.

On the other hand, if you want to reduce the number of routes in the full 
routing table inside your AS, that's a non-goal.

> 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."

A,B,C,D are part of one AS.  If you try to expand that so that they 
aren't, you get into trouble.  In the same way, if you don't expand it, 
you are just solving the provider-internal problem -- and are requiring 
the propagation of more specifics in DFZ.

Could you work out an example of AS's rather than routers?  It seems to me 
that there's some huge confusion somewhere.


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings