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

[Alex Zinin <[e-mail]>]

Folks-

 Please find below my AD-review comments on
 draft-ietf-ospf-scalability.

 "Ed" prefix is for editorial comments.

 Regards

--
Alex
http://www.psg.com/~zinin/


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
refs.

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 224.0.0.5 over a

Should "224.0.0.5" be "AllSPFRouters"?

Also, why only 224.0.0.5? DR and BDR will receive on 224.0.0.6
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 224.0.0.5 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
enough.

>   (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.