Re: RFC1863 to historic? [Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt (fwd)]

At 11:18 AM -0400 5/4/04, Jeffrey Haas wrote:
>On Tue, May 04, 2004 at 05:58:11PM +0300, Pekka Savola wrote:
>>  Route collectors or route servers used for other debugging purposes
>>  are an entirely different thing from route servers used to replace
>>  iBGP mesh, right?
>
>And an even stronger distinction:
>
>If you're going to do iBGP mesh, a route reflector is usually a better
>solution.
>
>Route servers are generally designed to serve as route proxies to
>create view-based policy.  At the least, this is the design for RSd.

I hope this isn't getting too far afield, but let me share a concept 
that I use in teaching, and, to some extent, we considered in the 
BMWG BGP convergence work.  This idea grew out of the Internet Growth 
panel that Sue, Frank and I did at the Stockholm ISOC.

We have real-world problems with the scalability of actual BGP 
routers (as distinct from the scalability of the overall routing 
system).  One of the limiting factors is the number of peering 
sessions per box.

I argue that we have several techniques for improving scaling by 
reducing the number of sessions.  Route reflection is an obvious 
technique for iBGP scalability.  I tend to think of confederations in 
two ways:  an adjunct to iBGP scalability, but also a way to 
implement finer-grained policies.  I've tended to use RR's for 
service provider implementations, but more often have used 
confederations for enterprises with complex multihoming and internal 
flow policies.

In my experience, newbies better understand all of the scalability 
methods if one adds the idea of the "classic" or "historic" RsD-style 
route server as an _e_BGP scalability technique. SO to come back to 
Jeff's comment, a route server replaces/reduces full eBGP mesh at 
exchange points.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr