Toodles, ] > 2. Even better, accept my routes into your network but only use them ] > within region... I know this isn't nearly as easy as #1, so I don't ] > expect it to happen, but it would be a significant performance benefit ] > for the local traffic your customers in the region are generating which ] > is headed towards me. Once outside the region, of course, you ignore the ] > direct routes from me and just give them to my transit provider. ] ] It becomes very entertaining to scale the above model (although it does ] provide an excuse to use nearly every BGP routing feature in IOS. :-) 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 Internet-Net.net. 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. 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
On Sat, 11 May 1996, Alan Hannan wrote:
I run Internet-Net.net. I have a POP in every city w/ over 10,000 people.
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.
Here's another scenario. I run Web o' Wonder, the most popular web site on the net but magazine writers are complaining it is slow and unreliable. I hire a net guru who tells me the problem is I am too big for one site. She says I should install WWW servers at several geographically diverse locations, preferably at or near NXP's. She explains that the servers at my main site (all CNAMEs for www.web-o-wonder.com) will no longer serve documents but will determine the topological closest site to the client based on route server info and issue redirects to seamlessly and speedily serve the client documents from the site closest to them in the topology. Seems to me that this scenario would also benefit from a tool and database that could determine topological "closeness" even if it doesn't need to generate filter lists. If this scenario were easier to implement it could reduce the load of the major exchange points by encouraging traffic to stay closer to the network periphery. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
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 Internet-Net.net. 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. Erik
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
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
Drawback: It is technically challenging to create an automate system to regionalize and create appropriate filter lists.
I always did enjoy a challenge. It's really pretty trivial up on the whiteboard. My model includes BGP confederations to define regions. In the absence of enough IP Addresses to divide your allocations by confederate AS, I am fairly sure the use of communities could be used to hack the distribution of more specifics into conforming the way you want. This is all from memory. I haven't revisted this model much since I developed my first one late last year. Maybe they're some new knobs which make it even easier. Dave -- Dave Siegel Sr. Network Engineer, RTD Systems & Networking (520)623-9663 x130 Network Consultant -- Regional/National NSPs dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/~dsiegel/ for an ISP."
participants (5)
-
Alan Hannan -
Dave Siegel -
Erik Sherk -
Michael Dillon -
Nick Williams