|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Worldly Thoughts - Regionalizing Peering
>> 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. >Erik Nick - - - - - - - - - - - - - - - - -
|