Re: [Idr] Fwd:I-D ACTION:draft-pmohapat-idr-acceptown-community-01.txt

John G. Scudder wrote:
> On Apr 30, 2008, at 6:39 PM, Danny McPherson wrote:
>   
>> Traffic wasn't the issue.  It's more CPU, memory, etc..  Just
>> because it's available doesn't mean it's free.
>>     
>
> Regarding memory, it needn't be consumed for a this-is-my-own-route  
> path.  (It may be, but this is an implementation decision.)
>
>   

You need to be careful about steady-state memory usage vs 
high-water-mark memory usage.
Processing updates chews memory *prior* to installation of entries in 
various RIBs/FIBs, and
unless you have an excess of CPU power (and can handle line-rate packets 
in the slow path),
it isn't possible to feasibly pre-filter without degrading performance.

And not pre-filtering means memory gets hit on the transient prior to 
discarding this-is-my-own-route.

> Regarding CPU, remember that you want to optimize the bottleneck,  
> nothing else matters really.  In most cases, the RR is the control  
> plane bottleneck.  Loading it up more to protect the CPUs of non- 
> bottleneck devices seems like an odd design decision.
>
>   

The red flag has gone up. Using the term "*the* bottleneck" means you 
don't understand the nature
of complex systems. Yes, there will *always* be a bottleneck. However, 
solving for one bottleneck
will *always* move the bottleneck to some other place. It may be 
acceptable for a stable state with
several equally-pernicious bottlenecks affecting the system, or to move 
the bottleneck to a portion of
the solution space that scales best (e.g. one that scales as O(n log n) 
vs one that scales as O(n^2).

The two other points I'd like to make, are, that:
(1) saying "in most cases" is the same as saying "it's not always the 
case". Solving for one case without
considering other cases is very short-sighted and can cause unforseen 
consequences. It is much better
to *consider* those cases, explicitly, and discuss whether and to what 
degree they would get affected; and

(2) keep in mind - an RR is *strictly* control plane. It is possible for 
it to reside on a device that also does
data plane stuff. However, if RR performance is a huge deal, throwing 
*computer* hardware at it, rather
than *router* hardware at it, is an entirely feasible solution - with 
likely higher (by orders of magnitude)
ceiling on performance that can be bought, and likely at much lower 
price point than equivalent router vendor
RR solutions. RR can achieve equivalent topological solutions (and thus 
avoid topological variance versus
router-based RR's) by sitting as a one-armed device hanging off a core 
router.

There is something to very much consider, however:
RR's are fundamentally required to achieve suitable scaling on big 
non-VPN networks.
Please keep those networks in mind when messing about with core BGP 
protocols.

(Never mind that I'm working on something to *really* mess with those 
same core BGP protocols... but with good reason. :-) )

Brian Dickson
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr