Re: Congestion Avoidance & Control for OSPF Networks <draft-ash-manral-ospf-congestion-control-00.txt>

["Ash, Gerald R (Jerry), ALASO" <[e-mail]>]

Hello John, All:

Hopefully by now you've had chance to review our latest draft on OSPF congestion control http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt.

As requested (by John), we've narrowed the scope of the work to propose specific congestion control mechanisms not already addressed by other documents in the OSPF WG.  

These mechanisms will prevent control overloads from bringing down a network, as they have in the past (I give a brief background below).

We request your comments on our I-D.  We also request your suggestions for advancing the work in the working group.

Thanks,
Jerry Ash

Brief background:

AT&T has suffered a few massive failures of operational networks due to control overloads of link-state (LS) protocols ('OSPF', 'PNNI', etc.).  These outages are documented and referenced in http://search.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt and in http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt.

In the instances cited, the LS protocol overwhelmed the network with a control load 'storm' ('LSA overload'), which brought the network down, and then prevented its recovery.  Fortunately such failures are very rare; however, 'rare' for such events is unacceptable, 'never' is the goal.  Other service providers have experienced similar outages caused by similar problems.

Such failures are not the fault of the service provider operation or the vendor/equipment implementation.  They are due to shortcomings in the link-state protocols themselves -- thus the need for the enhancements proposed in the draft. 

The proposals in the draft will prevent such events from being triggered, and/or provide recovery mechanisms in case such events occur.

The problem of control overload is becoming even more acute as LS protocols are enhanced to support new capabilities, such as:

MPLS traffic engineering http://search.ietf.org/internet-drafts/draft-katz-yeung-ospf-traffic-06.txt,
GMPLS http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-07.txt,
multi-area TE http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt,
MPLS/DiffServ TE http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-05.txt,
etc.

With this ever advancing complexity, the need keeps increasing to address the stated problem, soon.