Subject: Geo RIB-FIB compression, was: Re: [RRG] Geographic aggregation-based routing is at odds with reality

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 21 Jul 2008 11:23:12 +0200

On 21 jul 2008, at 6:17, Brian Dickson wrote:

>> |If I want to shrink my routing tables I can filter out any  
>> Canadian  |more specifics all over the world except in Canada, and | 
>> instead put in  |an aggregate that covers the address space used in  
>> Canada.

>> True, but if you do that unilaterally, you affect the flow of  
>> traffic as
>> most specifcs draw the traffic around your network, and you incur  
>> the phone
>> calls from Canada, who will kindly ask you to cease and desist,  
>> eh?  ;-)

I'm not sure what you have in mind here...

In the draft I wrote half a decade ago (wow, said that way it sounds  
even older!) I specified that the aggregates wouldn't be propagated  
outside the AS that creates them, except perhaps to customers. For  
obvious business reasons a network isn't going to announce any more  
specifics that it gets from peers to other peers, and with geo  
aggregation that wouldn't be possible in most places anyway as these  
more specifics are filtered out. So what would the network announce  
that draws traffic?

As for the outgoing traffic, obviously the people who receive it  
announced the prefixes in question at those locations, inviting the  
traffic...

>> We discovered this when we tried to do proxy aggregation the first  
>> time: the
>> abstraction action boundary MUST be carefully and thoughtfully  
>> engineered to
>> avoid unintended consequences.  This requires cooperation.

Right. A pan-Canadian network that also peers in some US cities may be  
somewhat surprised if it suddenly sees all traffic from the US east  
coast to Vancouver be delivered in Montreal rather than New York. But  
this isn't the kind of coordination where the entire internet needs to  
be upgraded before something useful can happen.

> The problem is not the generation of covering aggregates, but rather  
> the suppression of more-specifics.

> I think there is a very suitable boundary at which this can occur,  
> without impacting anything non-local.

> And that is, in the RIB->FIB stage.

Well, smaller and less volatile RIBs are also good. But we need to  
start somewhere.

> If there were a suitable attribute (e.g. a new BGP attribute, or a  
> well-known community) that could be applied
> to arbitrary prefixes in the BGP table, which triggered their  
> suppression only in the RIB->FIB, but not in any other place,
> then shrinking the FIB could be done locally, with no impact at all  
> outside of the local system.

Well, the obvious attribute to aggregate on when creating the FIB from  
the RIB would be the next hop address. I don't think adding an  
attribute at the source or somewhere in the middle is useful here, at  
those locations it can't be known whether two prefixes share a common  
next hop elsewhere.

The question is: how much aggregation could you get in this way? That  
depends on whether neighboring/overlapping prefixes share a common  
next hop. With random address assignment this isn't too likely, but  
with geographical address assignment this could happen in a much  
larger percentage of all cases.

Doing geographical PI assignments for RIB->FIB compression could be  
much easier to sell than actual geographical routing/aggregation.

Interested in working on running some numbers for this with me?

> What about the allocation schemes?
> It should be noted that one size never fits all, and knowing that in  
> advance should inform any allocation scheme.

Right. Using address assignment that is topologically relevant is much  
better than anything else, but every network has a different topology  
so this doesn't work. We all share the same planet, though, and as  
long as it makes sense that cables from Europe to North America land  
in NY or DC and not in LA or SF, we have _something_ to work with.

> For example, hierarchy of scopes for geographic allocation pools,  
> such as:

Michel Py wrote a script that slices and dices a /16 into /32s for  
cities, which seems to make sense for this. The algorithm for this is  
documented in my draft.

> Not having to rely on anyone else to *do* the aggregation, but only  
> on the RIRs to assign addresses (and specifically, PI prefixes)  
> according to geography and scope, means the problems *can* be  
> reduced to network engineering problems - hardware and software.

Right.

>> Almost every carrier operates with hot potato in mind, out of vested
>> self-interest.
>>

Also because it happens automatically while cold potato requires doing  
work.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg