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

In message <p05100318bcbd8be8bfa0@[192.168.0.2]>, "Howard C. Berkowitz" writes:
> 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.

We need more di-lithium crystals captain.  Or whatever they make those
processors out of these days.

Multiple processors responsible for the adjacency processing has
helped the "too many peers" problem in some routers.

So what does any of this have to do with RFC1863?  John Scudder
summarized things quite well.

Curtis

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