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

["John G. Scudder" <jgs at bgp.nu>]

On Apr 30, 2008, at 6:39 PM, Danny McPherson wrote:
>> With current link bandwith the amount of traffic generated due to  
>> that
>> is just white noise.
>
> 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.)

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.

>> IMHO based on the most common implementations at that time that was
>> the
>> main reason for the RR spec change.
>
> "Implementations" should be "implementation" there, not the
> plural.

FWIW I'm aware of at least three implementations that independently  
arrived at this same "optimization".

>> Now back to accept-own community I really see nothing wrong with it.
>> If
>> you are trying to say this is bad just because some implementations  
>> to
>> not support 2796 that's I am afraid wrong avenue.
>
> Perhaps, if you're in the business of selling CPUs and memory.

I don't really see the connection.

>> There are practical applications for this enhancement of which one is
>> described in the draft.
>
> Yes, one that introduces even local PE VRF-VRF connectivity
> reliance on upstream RRs..

As we've discussed already.  I don't think this point is any different?

--John
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr