[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