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

From: "Cheng, Dean" <[email-masked]>
Date: Mon, 8 Jul 2002 11:07:57 -0700

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:[email-masked]]
> Sent: Wednesday, July 03, 2002 12:20 PM
> To: [email-masked]
> 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.

---

From: "Ash, Gerald R (Jerry), ALASO" <[email-masked]>
Date: Mon, 8 Jul 2002 21:20:37 -0400

Dean,

>    as seen), before looking at the protocols themselves.

While all of the above, of course, can lead to network problems, none of what you list explains the protocol issues raised in the I-D.  Detailed route cause analysis was performed for the failures experienced (as summarized in the I-D).  The conclusions reached are consistent with the proposed protocol extensions.

>    that are caused by anyone of the above.

Simulations have shown us that the enhancements would resolve the problems identified. These are summarized in the I-D and further references are given for more details.
 
>    given in the Section 2) is actually not a link-state

Indeed it was a link-state protocol.  I'll contact you privately if you'd like more information.

Regards,
Jerry Ash

---

From: "Manral, Vishwas" <[email-masked]>
Date: Sun, 14 Jul 2002 23:48:43 -0400

Hi Dean,

Thanks a lot for the comments and sorry for the extremely delayed response(I
have been away from my mails for quite some time now). I will just add "my
little bit" to what Jerry has already stated.

>   as seen), before looking at the protocols themselves.
I agree it would be nice to detail a list of reasons that could cause
similar problems. The problems that you have stated i.e. "implementation
faults" can cause a problem as seen by AT&T.

>   that are caused by anyone of the above.
For "implementation faults"(or others as you stated) a protocol solution
isn't the best way however the solutions provided in the draft do minimize
the effect of such a problem by adding minimal functionality to the
protocol. Besides a lot of suggestions provided in the draft do not require
changes to the protocol but suggest basic functionality required in an
implementation to alleviate such problems.

Thanks,
Vishwas