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
- - - - - - - - - - - - - - - - -
] > 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
- - - - - - - - - - - - - - - - -