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

[Danny McPherson <danny at tcb.net>]

On Apr 30, 2008, at 4:04 PM, Robert Raszuk wrote:

> Hi Danny,
>
> In your below mail you are missing one fundamental practical data.

No, I'm not missing this, I understand it, I know why the spec
change was made.

> It is very cheap and easy to drop the unneeded route on inbound  
> while it
> is very CPU intensive to build separate updates to each peer.

Really?  Where's the line drawn?  What about when there are
one million updates being dropped?  I could probably make a
case for this today?  What about legit updates queued behind
these?  I don't believe introducing extraneous routing system
level state to allow more efficient update generation is a valid
excuse.

> 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.

> 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.

>
> **
>
> 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.

> 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 general rule of thumb I think there is need to support more
> automation in the network provisioning among many providers. There is
> also a demand in the market for more dynamic behavior of running
> applications. This is just right on this spot attempt to support one  
> of
> them.

Perhaps, but I think it ugly because of both clean routing hygiene
issues, and the network architectural fault considerations I've already
outlined.

>
> Cheers,
> R.
>
> PS. As to the comment from Ilya that this draft may break BGP
> implementations ... one needs to realize that conditional one more  
> check
> during inbound processing requires negligible amount of new BGP code.

Negligible, can you quantify that?  How many routes?  How much
churn?

> And I would like to point out that in most BGP implementations I am
> familiar with every month amount of code changes which go in even in  
> the
> fundamental parts of BGP assuming one may freeze all IDR work is much
> much much higher then such draft would require.

I don't understand what point you're making here.

-danny

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