Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

[[e-mail]]

Hi Robert,

> Today from what I see operators (if they even change the default) normally apply same timer value on all interfaces. If the timer is static what would be the incentive for any implementation not to group interfaces with identical transmit delay ? 


Why should the timer be static in an optimal system?  We want to avoid the need for the timer and have systems be adaptive.


> While this thread is very interesting I must observe that from my experience the issue is usually on the receiver. If LSR would publish a one page draft/rfc mandating that links state packets MUST or SHOULD be recognized and separated from any other control plane traffic at the ingress interface level (on their way to local RE/RP) we likely wouldn't be having such debate. 
> 
> Slowing senders just due to bad implementation of the receiving router is IMHO a little suboptimal (not to say wrong) thing to do. 


Heck, we can do better than that: we can outlaw bad implementations of anything.  Do you think that will help? 

The fact of the matter is that even good implementations can congest.  As silicon continues to scale, the ratio of interface bandwidth to control plane processing power continues to shift. Silicon has completely taken over our forwarding planes and scales upwards, where a single chip is now forwardinging for hundreds of interfaces. Meanwhile, buffering is finite and control planes really can’t keep up. Forwarding is a parallel activity. The control plane is not.  This presents us with a situation where congestion is pretty much inevitable. We need to deal with it.

Tony