Re: AD-review comments on draft-ietf-ospf-scalability

"Manral, Vishwas" <VishwasM@NETPLANE.COM> Wed, 02 July 2003 13:39 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id JAA17893 for <ospf-archive@LISTS.IETF.ORG>; Wed, 2 Jul 2003 09:39:56 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; Wed, 2 Jul 2003 9:39:54 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47364715 for OSPF@PEACH.EASE.LSOFT.COM; Wed, 2 Jul 2003 09:39:52 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Wed, 2 Jul 2003 09:39:52 -0400
Received: from ( []) by (Motorola/Ftpbox) with ESMTP id h62DdG0L006504 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 2 Jul 2003 06:39:16 -0700 (MST)
Received: from ( []) by (Motorola/il06exr03) with ESMTP id h62DdDSR012595 for <OSPF@PEACH.EASE.LSOFT.COM>; Wed, 2 Jul 2003 08:39:14 -0500
Received: by with Internet Mail Service (5.5.2653.19) id <NNKYZNWB>; Wed, 2 Jul 2003 09:38:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <>
Date: Wed, 02 Jul 2003 09:40:32 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: AD-review comments on draft-ietf-ospf-scalability
Precedence: list

Hi Alex,

We will get back to you on this soon.


-----Original Message-----
From: Alex Zinin [mailto:zinin@PSG.COM]
Sent: Wednesday, July 02, 2003 05:13
Subject: AD-review comments on draft-ietf-ospf-scalability


 Please find below my AD-review comments on

 "Ed" prefix is for editorial comments.



Ed: Number of authors is quite high. One way to address this would
    be to leave only the editor on the front page Author's info and
    move others to the "Contributors"

Ed: notice the order of the sections:

> Status of this Memo


> IPR Notices

> Copyright Notice
> Abstract

"IPR Notices" should be renamed to "Intellectual Property
Considerations" and moved to the end of the doc before the

Copyright Notice should be the last part of the doc.

Abstract should follow the Status.

> 1. Introduction
>    A large network running OSPF [Ref1] or OSPF-TE [Ref2] protocol may
>    occasionally experience the simultaneous or near-simultaneous update

Ed: This reads like "OSPF-TE" is a separate protocol.

>    (1) Classify all OSPF packets in two classes: a "high priority"
>        class comprising of OSPF Hello packets and Link State
>        Acknowledgment packets, and a "low priority" class
>        comprising of all other packets. The classification is
>        accomplished by examining the OSPF packet header. While
>        receiving a packet from a neighbor and while transmitting
>        a packet to a neighbor, try to process a "high priority"
>        packet ahead of a "low priority" packet.

This suggestion breaks the Crypto Sequence number processing as
described in the OSPF spec. The document should probably suggest
a STD-compatible way of dealing with this by maintaining separate
receive SNs for each class of packets.

>    (2) If the Recommendation 1 cannot be implemented then reset the
>        inactivity timer for an adjacency whenever any OSPF unicast
>        packet or any OSPF packet sent to over a

Should "" be "AllSPFRouters"?

Also, why only DR and BDR will receive on
too, and seems that the time should be adjusted. No?
I would it think it should have been any received valid OSPF packet.

>    (4) Implicit Congestion Detection and Action Based on That:
>        If there is control message congestion at a router, its
>        neighbors do not know about that explicitly.  However, they
>        can implicitly detect it based on the number of unacknowledged
>        LSAs to this router.  If this number exceeds a certain "high
>        water mark" then the rate at which LSAs are sent to this router
>        should be reduced.  At a future time, if the number of
>        unacknowledged LSAs to this router falls below a certain "low
>        water mark" then the normal rate of sending LSAs to this
>        router should be resumed.  An example value for the "high
>        water mark" may be 20 unacknowledged LSAs and that for the "low
>        water mark" may be 10 unacknowledged LSAs.  An example
>        value for the rate on exceeding the "high water mark" may be
>        50% the normal rate.  This recommendation is to be implemented
>        only for unicast LSAs sent to a neighbor or LSAs sent
>        to over a point-to-point link.

it seems that one step is not enough and something like exp back off
should be considered. E.g., if my neighbor can currently process only
50 LSUs per sec, and I step down from 200 to 100, I am still not good

>   (5) Throttling Adjacencies to be Brought Up Simultaneously:
>        If a router tries to bring up a large number of adjacencies to
>        its neighbors simultaneously then that may cause severe
>        congestion due to database synchronization and LSA flooding
>        activities.  It is recommended that during such a situation
>        no more than "n" adjacencies should be brought up
>        simultaneously.  Once a subset of adjacencies have been brought
>        up successfully, newer adjacencies may be brought up as long as
>        the number of simultaneous adjacencies being brought up does not
>        exceed "n". The appropriate value of "n" would depend on the
>        router processing power, link bandwidth and propagation delay.
>        An example value may be 4.

The last sentence almost sounds like n should be a dynamic value
(e.g., the number of links would probably matter too.) Should we just
drop it?

> 3. Security Considerations
>    This memo does not create any new security issues for the OSPF
>    protocol.

Not totally true.
See my note about crypto seq nums.