Worldly Thoughts - Regionalizing Peering

Erik Sherk sherk at
Mon May 13 14:02:24 UTC 1996

>   The model scales well, imho.  Regionalize your network into
>   pieces.  Apply each of the pieces into 1 or more proximities to a
>   NAP|MAE.
>   Apply set filter lists onto peering sessions for appropriate
>   peers.
>   Let me expound.
>   I run  I have a POP in every city w/ over 10,000
>   people.
>   I aggregate M number of POPs to N number of Hubs.
>   (use acronym NXP to mean network exchange point.....)
>   I am connected to P number of NXPs.
>   I go through each of my N Hubs, and identify if he is
>   or is not in Pn's region.  If he is, I add NXPn's peers to the
>   allow list.  If he's not, I don't.
>   Won't this work?  Is it "too confusing"?
>   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.


>   I have a HUB in San Mateo.  I decide that he's in the region of
>   MAE-W and PACBELL and MAE-LA, but not the NXP in Phoenix.  So, I
>   accept routes from the folks at those NXPs, and only give the
>   routes for my folks homed to my San Mateo HUB.  My San Mateo
>   Customers get to the folks at the NXP, and the other providers
>   customers get to my customers CLOSE to the NXP in San Mateo.
>   However, I don't have to backhaul them to another larger
>   aggragation point, or to another NXP at which I hand off packets
>   to their transit provider.
>   Benefit:  I gain low latency transit to most everyone.
>   Drawback:  It is technically challenging to create an automate
>   system to regionalize and create appropriate filter lists.
> ----
>   Perhaps this is a problem that's only challenging to the smaller
>   folks, those of us w/out the nationwide DS3|OC3 networks.
>   However, I do feel it's a worthy problem, and one that would
>   benefit the NANOG community were it intelligently solved.
>   -a

More information about the NANOG mailing list