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

Re: [RRG] Geographic aggregation-based routing is at odds with reality

Tony Li wrote:

Hi Iljitsch,
|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?  ;-)
Yeah. We're mad as heck, and we're not going to take it for very much longer. :-) 


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.
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.
We are much more concerned about the size of, and to a slightly lesser degree, the stability of, the FIB.
It would be nice to reduce the rate of change in the RIB, and to curtail the growth of the RIB, but except where it leads to bloat in the FIB, the size of the RIB isn't really important per se.
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.
BGP table entries would not be suppressed, and thus would continue to be propagated and usable beyond the local system.
This would differ considerably from the proxy aggregation method that suppresses *in bgp*, the more-specific prefixes.
And, having given it quite a bit of thought, I think this mechanism (coupled with appropriate allocation schemes and reasonable means of calculating and generating tables of aggregates and RIB->FIB suppression maps) could be just the thing needed to achieve 
the goals of the RRG. (The devil is in the parentheses, BTW.)

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.
I think that schemes that acknowledge the scope of the recipient, are most likely to be useful, widely accepted, and 
even self-documenting.

For example, hierarchy of scopes for geographic allocation pools, such as:
Planets {
 earth;
 continents {
   north america;
      countries {
         canada;
            provinces {
               ontario;
                  cities {
                     toronto;
                     [etc...]
                     }
                  counties {
                      durham;
                      york;
                      [etc...]
                     }
         usa;
         mexico;
   south america;
   [etc...]
   }
}
Requests would be directed to the region+scope that best matches the need of the requester, based on the expected routing policy.
A bunch of small satellite sites, would each get an individual entry from the appropriate pools. A big entity that has its own internal infrastructure would get an entry from the pool of corresponding location and scope, e.g. city-wide, state-wide, continent-wide, or even global (for really big telcos or multinationals).
Whatever aggregation is able to be done, is a consequence on the eventual alignment that naturally occurs due to economics.
Over the long-haul networks, aggregation is generally going to occur because there are just fewer long-haul links, and the unit cost of large capacity is smaller, as a general rule.
The alignment of allocation pools with topology can be expected to be proportional to the difference in scope, because of the long-haul aggregation. The number of paths to all destinations in a near-by city in the same state/province, are generally going to be orders of magnitude greater than the number of paths to all destinations in a remote city on another continent.
The relationship between scope size, and number of entities getting address space at that scope, globally, is likely to be order-of-magnitude. If there are O(N) entities with global prefixes, there will likely be O(N^2) continental prefixes, O(N^3) country-level, O(N^4) province/state, O(N^5) city/county, and O(N^6) neighborhood prefixes.
This happens to have very nice properties, BTW. If you are in any given scope, you would expect to be able to aggregate, to some degree, non-local prefixes, and need to keep all the local prefixes. Here, "local" has more than one meaning, but the number of local entries contributed by each scope can expect to be nearly constant, and very well behaved, the sum of linear terms.
Yes, maintaining this hierarchy of pools would have administrative costs - but any allocation scheme has such costs. Minimizing the costs by taking advantage of existing schemes for parameterization, e.g. CLLI codes, NANP info, ISO country codes, etc., would certainly be advisable. Making the aggregation itself a local activity, avoids many of the pit-falls such as cost/benefit asymmetry, changing the economic model(s) of the various players, etc.
The point is to make it possible, and to do so without making aggregation itself mandatory.
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. 

Brian
|If you are also a large network with customers in Canada, I |don't care |whether you also implement this aggregation or not. I can either do |hot potato and give you the Canadian traffic close to the source and |thus optimize for traffic flow, or filter those more specific, |transport the traffic to Canada and then give it to you, optimizing |for routing table size. 


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

Tony


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



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