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

["Cheng, Dean" <[e-mail]>]

Jerry et. al,

   Just have a general comment on your I-D.

   For congestion and overload problems that may occur
   in the networks where LS protocols used, there are
   quite a few possibilities that may have nothing
   to do with the LS protocols themselves, such as:

     1) Implementation faults.

     2) Configuration problems.
        This includes the wrong setting of protocols'
        parameters such as timer values.

     3) Network design/planning problems.
        This includes, for example, too many nodes in
        a single area/peer-group, etc.

   It would be better in your I-D to list all the
   non-protocol related problems along with suggestions
   (I believe that would resolve most of the problems
   as seen), before looking at the protocols themselves.
   Enhancements to existing protocols, if any,
   may not be able to resolve networking problems
   that are caused by anyone of the above.

   Also, the routing protocol used in the Frame Relay
   network where a failure occurred (the example
   given in the Section 2) is actually not a link-state
   protocol at all.

Regards,
Dean

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALASO [mailto:[e-mail]]
> Sent: Wednesday, July 03, 2002 12:20 PM
> To: [e-mail]
> Subject: Re: Congestion Avoidance & Control for OSPF Networks
> <draft-ash-manral-ospf-congestion-control-00.txt>
>
>
> 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-c
> ongestion-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-c
ongestion-control-00.txt and in
http://search.ietf.org/internet-drafts/draft-ash-ospf-isis-congestion-contro
l-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-0
7.txt,
multi-area TE
http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-exte
nsions-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.