Re: Worldly Thoughts - Regionalizing Peering
At 8:24 PM 5/11/96, Alan Hannan wrote:
The model scales well, imho. Regionalize your network into pieces. Apply each of the pieces into 1 or more proximities to a NAP|MAE.
Been there, done that.... I've already stated my view on the scalability of such arrangements.
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.
It also complicates every peering relationship and multi-homed customer connection, as you have to worry about both multiple external AS's and your internal routing redistribution from all of these regional routing clouds. If you presume a fairly dense set of interconnects among transit providers, then you're not going to get a significant improvement in latency despite the added complexity. /John
On Sun, 12 May 1996, John Curran wrote: |} At 8:24 PM 5/11/96, Alan Hannan wrote: |} |} > 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. |} |} It also complicates every peering relationship and multi-homed |} customer connection, as you have to worry about both multiple |} external AS's and your internal routing redistribution from all |} of these regional routing clouds. The level of complication is dependant on how the network is structured. For example, in a topology which reflects internal routes between access/service and core nodes, it will be treated as a single AS, or as an alternate it can be treated as external. This is because you've distributed the processing throughout the majority nodes in the network, rather than a design which is doing the processing on the edges of the network. This greatly eases the amount of constant re-configuration and work that is required to connect to a dense set of exchange points. -jh-
participants (2)
-
John Curran
-
Jonathan Heiliger