Re: OSPF WG Charter Proposal

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

Rohit, Acee,

From the (consolidated) thread so far:

Rohit/Acee> Here is a strawman of the Charter. Please have a look at and send
Rohit/Acee> any comments you may have to me or Acee or to the list.

Venkata> Can you consider "Flooding Optimizations" into charter?
Venkata> If not, can you please explain the reason, why we should not?
Venkata> This is field of its own - we might expect lot of drafts.

Rohit> We considered this but would like to see some operational requirements
Rohit> before including this in the charter. Is anybody running OSPF networks
Rohit> hitting this problem with no workarounds in sight?
Rohit> It would be a candidate for a future version of the charter once some
Rohit> of the current items clear.

Vishwas> I do think it can be helpful in a few cases. A recent paper by Aman 
Vishwas> Shaikh/Albert Greenberg et.al. about analyzing OSPF for Enterprise 
Vishwas> is one such case. 
Vishwas> One of our drafts "Congestion Avoidance and Control for OSPF networks" 
Vishwas> talks about problems that have been caused by flooding overload in 
Vishwas> production networks.

Rohit> I am familiar with Aman's work. The problem identified there was
Rohit> that of (a) sub-optimal network/ospf configuration and (b) 
Rohit> broken router.
Rohit> This does not of course justify building new protocol mechanisms, 
Rohit> thereby complicating the protocol.
Rohit> I will look at the congestion again to see if/why it concludes otherwise.

We would like to see OSPF 'congestion control' included into the OSPF charter, where 'flooding optimizations' is a key component as discussed in our draft http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt.  We can propose a workplan/goals/milestones if you'd like.

Several other drafts identify needs related to OSPF congestion control:
http://ietf.org/internet-drafts/draft-ietf-ospf-scalability-01.txt
http://www.ietf.org/internet-drafts/draft-choudhury-manral-flooding-simulation-00.txt
http://www.ietf.org/internet-drafts/draft-dovolsky-ccamp-ospf-limited-flooding-00.txt

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 our draft (and in http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-control-02.txt).

In the instances cited, the link-state 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 http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt 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-09.txt,
GMPLS http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-08.txt,
multi-area TE http://www.ietf.org/internet-drafts/draft-kompella-mpls-multiarea-te-03.txt,
MPLS/DiffServ TE http://search.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-06.txt,
etc.

With this ever advancing complexity, the need keeps increasing to address the stated problem, soon.  Thus the need for the charter item on OSPF congestion control.

Thanks,
Jerry Ash