Worldly Thoughts - Regionalizing Peering
sherk at uunet.uu.net
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
> Apply set filter lists onto peering sessions for appropriate
> Let me expound.
> I run Internet-Net.net. I have a POP in every city w/ over 10,000
> 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.
More information about the NANOG