[j-nsp] BGP route-reflection question

[Danny McPherson]

On 5/29/03 2:18 AM, "Hannes Gredler" <hannes at juniper.net> wrote:

> most of the BGP scaling properties are bound to memory size, you are right:
> 
> however, what i fail to see is why path diversity is negatively impacting
> convergence;
> what i have seen to far is contrary: a healthy path diversity speeds
> up convergence; 

I think you're confusing the issue, what new diversity do you get that
simple loopback peering wouldn't provide?   The transmission substrate
doesn't change, you're simply adding lots of overhead unnecessarily,
subsequently effecting convergence, memory consumption and CPU utilization,
in _any router.

> of course many paths do cost memory; so the main challenge
> is to convince "the other vendor" to ship proper memory with their boxes and
> not to tweak the design of the routing mesh to the limitations of a single
> implementation;

It's not just about memory, or any particular vendor.  Although memory is
one factor (in which case by following your recommendation you'll(J) use
more as well, no?), it's also about the protocol capabilities.  If you send
2x or 3x the amount of updates because they can't be packed as efficiently
that effects the entire routing system -- not just a single box -- although
every individual box is effected as well.  If receivers now have to pack and
process twice as many updates, or aggregate Adj-RIBs-In are much larger,
that eventually effects the characteristics of the entire routing system.
 
> typically the design lives much longer than a single boxes' lifespan ;-)

Indeed, and that's why you, as well as any other vendor, should be concerned
with the effects that recommendations you make have on the larger routing
system.   This isn't about Cisco, Juniper or insert_vendor_here, don't make
it.  It's about clean network architecture, something that will effect not
only the local routing system, but distant networks as well.


-danny