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

Hi Danny,

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

Let me address your concerns one by one ...

* The line is drawn when you have 100s of PEs to send the same 
information to.

* The milion updates to be dropped .... Clearly you must be talking 
about VPN routes. If so there are hardly single PE with milion routes to 
  make such a case today. Total number of routes yes but this draft is 
orthogonal to this. You are complaining about the 2796 case again here.

* Each PE can today receive only legit updates with or without of this 
draft including RRs support for 2796. There are well know standard based 
technics for this example: rfc4684.

Can you tell us how your argument holds when you support rfc4684 ?

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

Memory is just a transient memory. If your CPU suffers with inbound 
filtering I think there are much bigger issues behind the scenes.

Keep in mind that discussed here draft does not increase number of 
routes each PE would receive even by a single one. All of your points 
Danny flame the issue of reflecting back the information to the client 
which were originated by it before. Perhaps this is a valid theoretical 
complain but it is just out of this topic. And as said before this is 
all for VPN space where this problem has already been addressed by rfc4684.

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

You are missing the big picture :) This is to provide functional 
consistency ... RR will propagate the same very update to all PE - which 
very often are in hundreds or maybe thousands of today's large 
providers. Only one of them originated the route .. appending this new 
community will not have any impact in all of the PEs .. only in the 
originator which will accept the route and perform required action which 
will be consistent with all other PEs in the network.

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

Recently we have had hussars bashing "BGP overload" ... now in 2008 
perhaps we see a new trend "routing hygiene". So can you spell what is 
so unhygienic in this draft ? All points you have brought so far talk 
about solved issue (in the VPN space) if reflecting unneeded routes to 
PEs ... but non of your points refer to this draft. Can you put in 
points how this draft make this any worse ?

Cheers,
R.

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