Subject: Re: I-D ACTION:draft-ash-manral-ospf-congestion-control-00.txt

From: "Manral, Vishwas" <[email-masked]>
Date: Wed, 24 Apr 2002 09:49:13 -0400

Hi Folks,

A new draft which talks about failures that some providers have had with
their LS protocols, due to congestion/overload and solutions to it for OSPF
networks has been posted.

We have been working on this draft for quite some time now and we discussed
this with a lot of folks in Minneapolis at the last IETF. We have received a
lot of feedback for the pre-published versions of this draft, for which we
would like to thank Alex Zinin, Russ White, Dave Katz, Alvaro Retana and
others.

It would be nice to discuss any issues you may have with the draft and
either mail Jerry or me regarding any queries, either on the list or
personally.

The link to the draft again is
http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control
-00.txt

Thanks a lot,
Vishwas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, April 24, 2002 5:34 PM
To: [email-masked]
Subject: I-D ACTION:draft-ash-manral-ospf-congestion-control-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Congestion Avoidance & Control for OSPF Networks
        Author(s)       : J. Ash et al.
        Filename        : draft-ash-manral-ospf-congestion-control-00.txt
        Pages           :
        Date            : 23-Apr-02

Based on overload and failure experience with link-state protocols, this
draft identifies means to enable link-state protocols to:
o avoid getting into congestion states wherever possible
o respond gracefully to network overloads and failures
o gracefully recover from massive loss of topology database
information
The proposed mechanisms include the following:
o throttle setups of link adjacencies
o reduce the rate of flooding of link-state-advertisements(LSAs)
o prioritized treatment of Hello & LSA ack packets
o database backup & resynchronization for graceful recovery from loss
of topology database information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ash-manral-ospf-congestion-control
-00.txt

To remove yourself from the IETF Announcement list, send a message to
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ash-manral-ospf-congestion-control-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE
/internet-drafts/draft-ash-manral-ospf-congestion-control-00.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Erblichs <[email-masked]>
Date: Thu, 25 Apr 2002 12:14:42 -0700

My comment on section 4.1.1

1) "router goes down and comes back up again"
A) If the new state of the neighbor is "down", then the RFC specifies
to discard the resources associated with the neighbor.

A new possible state of "zombie" (inherited from the UNIX OS)
could keep some information from this now dead neighbor could be
used to identify that this neighbor went down or is possibly
unstable.

Yes, additional CLI configuration commands and a timer would then be
necessary to free the zombie neighbors after they have been down
for x period of time. You could also do some special processing of
router neighbors that return from the zombie state.

B) If the new state is lesser than the oldstate, then new fields
would be necessary to identify whether the oldstate was FULL or
2-WAY.. And again todo the necessary work in the future. It is
possible to then only mark some type of work and being delayed
until some time in the future (assuming that the 2-way or full
will return in just a short period of time).

MAX_ADJ_BUILD_COUNT
1) My suggestion is to use a time field here to identify if and when
this value was reached and how long it is relevent. This time
field will determine whether this just a burst (transient) of new
adjs (2-way or full ) or a sustained problem.

2) Low Watermark value:
With most threshold values, it is sensible to impliment a low-watermark
type value that may be derived from the high-watermark value. This
could be imlimented here by waiting for the MAX_ADJ_BUILD_CNT to
drop to the low-watermark value before allowing new building of
adjs back to the high watermark value. Then if the transition moves
from high to low and back to high, the router would then know that
there is still a sustained amount of work involved to finish building
all the adjs.

nit within 4.1.2 right now--
[RFC2474] :::: I don't see it listed in the section 8 referenes..

Mitchell Erblich

---

From: Erblichs <[email-masked]>
Date: Fri, 26 Apr 2002 09:59:18 -0700

Suggestion for a new section...
Sorry, I have done alot of work with congestion and scaling...

With the assumption of heterogeneous devices that support
different levels of support for congestion, I would to
add something like the following for the legacy devices.

With the knowledge of sustained local congestion, some
processes may have delayed processing of such items
as the Link State database (See the 4.2.2.4 section).

Thus, to support the legacy devices it is suggested that
some flooding of originated LSAs with excessively high
link cost metrics be done. This value should be set to
LSInfinity or a close approximate value. This should minimize
the use of this congested router as a transit router
while under congestion...

When congestion subsides the LSAs may be re-flooded with the
appropriate costs of this non-congested link.

Mitchell Erblich