Re: OSPF WG Charter Proposal

["Choudhury, Gagan L, ALASO" <[e-mail]>]

It is great to see that there are lots of discussions on the OSPF Scalability issues (including flooding optimization, prioritized treatment of Hellos so as not to lose adjacency under congestion, congestion notification to neighbor and slowing down of control messages based on that, etc.).  

It appears that people mostly agree that occasionally operational networks do see large scale flooding of control messages or LSA storm (triggered by hardware failure, software bug, faulty operational practice, and so on).  (I have personal experience of observing such LSA storms and resulting CPU/Memory congestion).  In some cases of large scale flooding of control messages the network may get out of it with little difficulty but we all know that there are also cases that results in failures of many nodes and trunks and loss of traffic which is absolutely unacceptable from an operator's point of view.  People might also agree that there is a LSA storm threshold (or "cliff") and a near-simultaneous generation of LSA storm exceeding this threshold (or "cliff") may cause problems.  Ideally, this threshold should be as large as the LSA database size even in very large networks (with potentially many ASE LSAs, and many Traffic-Engineering-Related LSAs in upcoming MPLS networks) but in reality that does not appear to be the case.

The various proposals for OSPF Scalability improvements are to move the LSA storm threshold (or "cliff") significantly upwards.  Some people feel that this should be done only through smart (proprietary) implementation.  However, the points against that are the following:

1) It may be OK to rely on the smart proprietary implementation of a vendor if we run a single-vendor network.  However,  Operators would intend to run multi-vendor networks with standard, non-proprietary solution to scalability problems.  As an example, Dave Katz points out that it is very important not to lose adjacencies during congestion.  We absolutely agree with that and propose either prioritization of Hello messages (facilitated by special marking) or using Implicit Hello (use any received message over an adjacency for the purpose of keeping it alive) to achieve the same goal in a multi-vendor network.  We have also seen large number of retransmissions (default retransmission timer is 5 seconds) as a major cause of congestion and propose prioritizing LSA acknowledgments and slowing down retransmissions during congestion to reduce retransmission traffic.  This can perhaps be achieved by a specific vendor in a proprietary way but an Operator would like to see a non-proprietary solution to this problem.

2) It has been argued that some of the protocol extensions being proposed would make it too difficult for vendors to implement it.  I don't quite get it.  Isn't it also being said that some vendors are already implementing them in a proprietary way ?

3) Some of the protocol extensions proposed are difficult (may be even impossible) to implement in a purely proprietary way.  One example is congestion notification (already pointed out by Dave Katz).  Another example is flooding over only one of many parallel point-to-point links between neighbors (this is already being done in PNNI in a non-proprietary way).               

        	
                        Gagan Choudhury