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

[Xu Xiaohu <xuxh@huawei.com>]

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

How about replacing the "local system" by "local autonomous system"? That is
to say, those PI prefixes with a new BGP attribute will be selectively
installed into FIB by several aggregate routers of one AS, and these
aggregate routers will advertise the aggregated routes with no-export
community and draw the traffic towards those more specific prefixes. The RIB
will not be suppressed and the most specific prefixes will be advertised
outside the AS. In a word, the FIB rather than RIB is to be shrinked.
In this way, there is no need for the ISPs in some location to be
interconnected, which is the known issue with geo-aggregation approach.

Xiaohu XU

> 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



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