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

Alex Zinin <zinin@PSG.COM> Tue, 01 July 2003 23:43 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id TAA20795 for <ospf-archive@LISTS.IETF.ORG>; Tue, 1 Jul 2003 19:43:27 -0400 (EDT)
Received: from PEAR.EASE.LSOFT.COM ( by (LSMTP for Digital Unix v1.1b) with SMTP id <>; Tue, 1 Jul 2003 19:43:28 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 47289091 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 1 Jul 2003 19:43:26 -0400
Received: from by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 1 Jul 2003 19:43:26 -0400
Received: from [] (helo= ident=zinin) by with esmtp (Exim 4.14) id 19XUmU-000MNe-7B for OSPF@PEACH.EASE.LSOFT.COM; Tue, 01 Jul 2003 23:43:26 +0000
X-Mailer: The Bat! (v1.62i) Personal
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Tue, 01 Jul 2003 16:42:58 -0700
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Alex Zinin <zinin@PSG.COM>
Subject: AD-review comments on draft-ietf-ospf-scalability
Precedence: list
Content-Transfer-Encoding: 7bit


 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.