[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 rrg-request@psg.com 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