Worldly Thoughts - Regionalizing Peering
nmw at haven.ios.com
Mon May 13 20:33:44 UTC 1996
>> Let's say I have 1 HUB in Arizona. I decide that they are in the
>> region of MAE-W, PACBELL, and the NXP in Phoenix. So, I accept
>> routes from everyone at any of those NXPs, and I give my routes
>> for this HUB only, to everyone at the NXP. I don't tell them
>> about my route to customers homed to San Mateo, because I don't
>> want to carry their traffic there, only stuff that's topolgically
>> 'close' to them, as I feel that benefit to my customers is worth
>> the peering relationship.
>Unless you were precient when you allocated your CIDR blocks, this means
>that you will not be able to aggregate your networks.
Well, that is the problem with CIDR, if you aggregate, you lose control
of details. However, it is possible to apply the regional peering model
with relative ease by using tags/communities to tag the origin of your
routes as well as routes you hear from your peers and filter
accordingly. As for aggregates you can do one of two things:
1) let your specifics float around on your backbone as well as the
aggregates, and pass on the specifics to regional peers, or the
aggregates to "complete" peers (to everyone else pass nothing or
announce them only your aggregates); or
2) be more selective with respect to long specifics and either announce
none of those to your regional peers or announce the aggregates (even
though they include non-regional information).
You also have to sortof trust your regional peers to give you only
reasonably regional routes; if they lie, well, they only get half the
route back from your non-regional sites to theirs, the rest they must
get through somewhere else.
More information about the NANOG