Re: OSPF WG Charter Proposal

[Manohar Naidu Ellanti <[e-mail]>]

Jerry,
your comment -
"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." is very apt.

You have probably the most qualifying experience to talk
about control protocol.

I would like to raise the following questions
 - OSPF as it is , is it suitable to advertise auxiliary
information
- is the network model right ? spoke and wheel as
opposed to hierarchical model.
-can the protocol be simplified ; it is becoming too
monolithic
If you look at SS7  there is clear seperation of
applications from signaling protocol- comparison of OSPF
to SS7 may not make sense but if you look #7
architecturally - ISUP, TUP etc are applications on top
of signaling/control protocl.

I have asked long time back about breaking the
monilithic function of OSPF into applications/seperate
functions that can use the OSPF basic services rather
than the applicaitons being part of OSPF itself. But no
body seems to be interested or it is too late.

If  applications and their information elements (TLVs)
are seperated from OSPF it woul be feasible to reduce
OSPF LSA congestion as the LSDB itself will be segmented
or the information stored in LSDB can migrate to the
applications themselves. Just my opinions.


-ellanti
> 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-0
> 0.txt
> http://www.ietf.org/internet-drafts/draft-dovolsky-ccamp-ospf-limited-flooding-0
> 0.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.tx
> t,
> 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