[Ballot comment]
Section 2, point 5--calculation of the number of adjacencies includes "link bandwidth". What seems to be related is the total BW available for the control
plane, not one of an individual link, since the number of links may changes
depending on the router configuration and link status.

[Ballot discuss]
The document states:

---
In this document as we refer to OSPF we usually mean OSPFv2 [Ref1].
The scalability and stability improvement techniques described here
may also apply to OSPFv3 [Ref2] but that will require further study
and operational experience.
---

This document needs to be more precise with it's
definitions. 'we usually mean OSPFv2' is very vague. How can a reader
know when the authors mean OSPFv2, OSPFv3 or OSPF in general ?

Also, the title of the document should probably be 'OSPFv2 scalability'
considering that the document says that further study is needed whether
it also applies to OSPFv3.

[Ballot discuss]
My original DISCUSS said this:

      "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328.  That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled.  In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders."

I'm unhappy with one of the proposed changes; for now, my DISCUSS stands.

Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing.  But the document goes on to suggest  two sequence number spaces, one for high priority packets and one for low priority packets.  The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly.  But there is no explicit signaling defined, so that's not an option.  Nor is there adequate analysis of other possible effects of having separate sequence number spaces.  To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs?

My suggestion is to delete the part about dual sequence number spaces.  If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation.  The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this.  Also, is receiver priority implemented, per RFC 1264?

[Ballot discuss]
My original DISCUSS said this:

      "This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328.  That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled.  In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders."

I'm unhappy with one of the proposed changes; for now, my DISCUSS stands.

Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing.  But the document goes on to suggest  two sequence number spaces, one for high priority packets and one for low priority packets.  The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly.  But there is no explicit signaling defined, so that's not an option.  Nor is there adequate analysis of other possible effects of having separate sequence number spaces.  To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs?

My suggestion is to delete the part about dual sequence number spaces.  If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation.  The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this.

[Ballot discuss]
My original DISCUSS said this:

      This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328.  That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled.  In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders.

I'm unhappy with one of the proposed changes; for now, my DISCUSS stands.

Saying that the priority treatment scheme should be applied at the receiver can work, though it will cause implementation complexity for the security handler: security processing (including sequence number checking) will have to be done at receive time, before the priority queueing.  But the document goes on to suggest  two sequence number spaces, one for high priority packets and one for low priority packets.  The authors note that this change isn't backwards-compatible, and must be signaled explicitly or implicitly.  But there is no explicit signaling defined, so that's not an option.  Nor is there adequate analysis of other possible effects of having separate sequence number spaces.  To give one example, would having that help or hinder the calculations in Recommendation 4 of the number of unacknowledged LSAs?

My suggestion is to delete the part about dual sequence number spaces.  If it looks like a good idea after further analysis, it can be the subject of a separate RFC, one that would include signaling and/or negotiation.  The suggestion about receiver priorities is a good one and will suffice for this purpose, but there should be some discussion about the effects of congestion on the ability to actually benefit from this.

Replies from the document editor to the IESG evaluation:

Response to IESG Reviewer's Comments:

Comments From Ned Freed:

Comment 1: Not sure if the separate sequence number business mentioned
in the security considerations section is really a "security issue" with
a "recommended" solution. To me it sounds more like a processing
requirement for correct operation. But this is not my area of expertise
so I'll leave it up to the security folks.

Response 1:  Please see the response to Steve Bellovin's comment below.

Comment 2 : Nits:
A fair number of grammar errors appear throughout.
(date) in copyright boilerplate needs to be filled in.
I don't think the copyright on the doc qualifies as an IP consideration,
so it seems strange to see it as a list item in the IP considerations
section.

Response 2: We looked carefully at the document and corrected grammar
errors wherever possible.  (date) in
copyright boilerplate is filled in as (2004).  We made it clear that the
"Copyright Notice" is not part of "IP Considerations".

Comments from Steve Bellovin:

Comment 1: This scheme breaks cryptographic authentication as described
in D.4 and D.5 of RFC 2328.  That RFC has no provision for the different
sequence number spaces described by this document, nor do I see any way
in which the use of this priority queuing scheme is signaled.  In other
words, it's not only not backwards compatible with 2328's security, it
doesn't even provide a way for a new receiver implementation to
interoperate with both old and new senders.

Response 1:  We understand your concern and address it as follows.  We
now recommend that in OSPFv2 and with Cryptographic Authentication
(AuType = 2), no prioritized processing be done at the transmitter since
that may cause packets to be received out of sequence and break the
Cryptographic authentication.  We do, however, recommend prioritized
treatment at the receiver after receiving a valid OSPF packet since it
does not cause the out of sequence problem.  Also we mention that
prioritized processing at transmitter can only be done if both sides of
the interface use separate sequence number spaces for "High" and "Low"
priority packets and can signal that fact to each other explicitly or
implicitly (the fact that this mechanism is not backwards-compatible is
also mentioned).  The specific text used in this respect in Page 3 is
given below (also similar clarifications given on Page 6 and Page 13):

"The prioritized processing while transmitting may cause OSPF packets
from a neighbor to be received out of sequence. In OSPFv2if
Cryptographic Authentication (AuType = 2) is used (as specified in
[Ref1]) then successive received valid OSPF packets from a neighbor need
to have a non-decreasing "Cryptographic sequence number".  To comply
with this requirement we recommend that in case Cryptographic
Authentication (AuType = 2) is used [Ref1], prioritized processing be
done only at the receiver after receiving a valid OSPF packet but no
prioritized processing be done at the transmitter.  Another possibility
is to use two separate sequence number spaces, one for "high" priority
packets and another for "low" priority packets.  In this case
prioritized treatment at the transmitter would also work since OSPF
packets within the same priority class would not get out of order. This
mechanism is, however, not backwards compatible and so can be used only
if both sides of the interface use this mechanism and can signal that
fact to each other explicitly or implicitly."

Comments From Ted Hardie:

Comment 1: Appendix A lists Router-ID changes as one of the potential
causes of an LSA storm, and notes that this condition may cause a large
number of LSA purges as well as LSA re-originations.  This raises for me
the question of whether there is or needs to be ordering of LSA messages
by type (e.g. process purges, then origination messages).  The core idea
of this (different class for control messages) is not affected by this,
since all of the control messages still fall into the same class, but it
might affect the implementation of some of the related features (FCFS
for the formation of adjacencies, for example, might by within that
particular set of LSA control messages, rather than being FCFS for all
control messages).  If this is handled by normal OSPF processing or not
important for other reasons, mentioning why in the text might be a
useful guide to the less experienced reader.

Response 1: We added a Suggestion (3) in Appendix C (Page 13) to
address your point.  We also got input on this item from Alex Zinin,
Rohit Dube, and Acee Lindem.
     
      "Processing large number of LSA Purges: Occasionally some events
      in the network, such as Router ID changes, may result in a large
      number of LSA re-originations and LSA purges.  In such a scenario
      one may consider processing LSAs in different order, e.g.,
      processing LSA purges ahead of LSA originations.  We, however,
      do not recommend out-of-order LSA processing for several reasons.
      Firstly, detecting the LSA type ahead of queueing may be
      computationally expensive.  Out-of-order processing may also
      cause subtle bugs. We do not want to recommend a major change in
      the LSA processing paradigm for a relatively rare event such as
      Router ID change. However, a Router with a changing ID may flush
      the old LSAs gradually without causing a storm."

Comments From Russ Housley:

Comment 1: Building on Steve's point:  The OSPF sequence number is a
32-bit unsigned integer. If the OSPF Hellos and LSA Acknowledgments draw
from one segment of this space, and other messages draw from another
segment, then implementations of the current OSPF specification will
reject one of the segments altogether.

Response 1: We understand your point and made appropriate changes.
Please see the response to Steve Bellovin's comment above.

Comments From Bert Wijnen:

Comment 1) This document only refers to OSPF as OSPFv2.  How about
OSPFv3? Either way, this requires modifications/clarifications.

Response 1:  To address your point we have added a reference to OSPFv3
(RFC 2740) and added the following text at the beginning of Introduction:

"In this document as we refer to OSPF we usually mean OSPFv2 [Ref1].
The scalability and stability improvement techniques described here
may also apply to OSPFv3 [Ref2] but that will require further study
and operational experience."

Comment 2) this document talks about "point-to-point links", but this
maybe should be generalized, considering work on treating physical LAN
links as point-to-point from the protocol's perspective (ref:
draft-ietf-isis-igp-p2p-over-lan-03.txt)?

Response 2: At the end of Section 2, Recommendations (Page 6), we have
added the following text to address your point:

"In some of the Recommendations above we refer to point-to-point links.
Those references should also include cases where a broadcast network is
to be treated as a point-to-point connection from the standpoint of IP
routing [Ref5]".

Comment 3) (I'm not 100% familiar with OSPF internals, but) assume that
a malicious host sends an OSPF packet, over e.g. 5 hops, directly to a
router, addresses to the routers unicast address.  Would this be
possible?  Would it then be classified to be a received packet per rule
(2) in section 2?  Maybe this wouldn't work, but if it would, this would
be one way to perform DoS by keeping up the adjacencies even if a router
has failed (to send the packets to black hole or whatever).

Response 3:  If the adjacency is really down then no packets will come
over it and so it will be declared down by OSPF within a period of
RouterDeadInterval.  After that OSPF will not accept any packet
over the interface besides Hello packets.  However, we would also like to
point out that the DoS attack can occur even with normal OSPF (without our
recommendations) if there is no authentication mechanism in place. Our
recommendations do not make the situation any better or worse.   

Further Comments from Bert Wijnen

Comment 1: The references lists over a dozen references which are many
probably interesting, but not referred to in the body of the document.
Remove or refer.

Response 1: All references are referred to in the document.  However,
the Normative References and a subset of the Informative references are
referred to in Sections 1-4.  The rest are referred to in the Appendix
Sections.

[Ballot comment]
Nit from OPS directorate review (Pekka):

The references lists over a dozen references which are many probably
interesting, but not referred to in the body of the document.  Remove
or refer.

[Ballot discuss]
From OPS DIrectorate review (Pekka):

Big issues:

1) This document only refers to OSPF as OSPFv2.  How about OSPFv3? 
Either way, this requires modifications/clarifications.

2) this document talks about "point-to-point links", but this maybe
should be generalized, considering work on treating
physical LAN links as point-to-point from the protocol's
perspective (ref: draft-ietf-isis-igp-p2p-over-lan-03.txt)?

3) (I'm not 100% familiar with OSPF internals, but) assume that a
malicious host sends an OSPF packet, over e.g. 5 hops, directly to a
router, addresses to the routers unicast address.  Would this be
possible?  Would it then be classified to be a received packet per
rule (2) in section 2?  Maybe this wouldn't work, but if it would,
this would be one way to perform DoS by keeping up the adjacencies
even if a router has failed (to send the packets to black hole or
whatever).

[Ballot discuss]
From OPS DIrectorate review (Pekka):

Big issues:

1) This document only refers to OSPF as OSPFv2.  How about OSPFv3? 
Either way, this requires modifications/clarifications.

2) this document talks about "point-to-point links", but this maybe
should be generalized, considering work on treating
physical LAN links as point-to-point from the protocol's
perspective (ref: draft-ietf-isis-igp-p2p-over-lan-03.txt)?

3) (I'm not 100% familiar with OSPF internals, but) assume that a
malicious host sends an OSPF packet, over e.g. 5 hops, directly to a
router, addresses to the routers unicast address.  Would this be
possible?  Would it then be classified to be a received packet per
rule (2) in section 2?  Maybe this wouldn't work, but if it would,
this would be one way to perform DoS by keeping up the adjacencies
even if a router has failed (to send the packets to black hole or
whatever).

[Ballot discuss]
Building on Steve's point:  The OSPF sequence number is a 32-bit unsigned
integer. If the OSPF Hellos and LSA Acknowledgments draw from one segment
of this space, and other messages draw from another segment, then
implementations of the current OSPF specification will reject one of
the segments altogether.

[Ballot comment]
Appendix A lists Router-ID changes as one of the potential causes of an LSA storm, and notes
that this condition may cause a large number of LSA purges as well as LSA re-originations.  This
raises for me the question of whether there is or needs to be ordering of LSA messages by type
(e.g. process purges, then origination messages).  The core idea of this (different class for
control messages) is not affected by this, since all of the control messages still fall into the
same class, but it might affect the implementation of some of the related features (FCFS
for the formation of adjacencies, for example, might by within that particular set of
LSA control messages, rather than being FCFS for all control messages).  If this is
handled by normal OSPF processing or not important for other reasons, mentioning
why in the text might be a useful guide to the less experienced  reader.

[Ballot discuss]
This scheme breaks cryptographic authentication as described in D.4 and D.5 of RFC 2328.  That RFC has no provision for the different sequence number spaces described by this document, nor do I see any way in which the use of this priority queuing scheme is signaled.  In other words, it's not only not backwards-compatible with 2328's security, it doesn't even provide a way for a new receiver implementation to interoperate with both old and new senders.

[Ballot comment]
Not sure if the separate sequence number business mentioned in the
security considerations section is really a "security issue" with
a "recommended" solution. To me it sounds more like a processing
reqirement for correct operation. But this is not my area of
expertise so I'll leave it up to the security folks.

Nits:

A fair number of grammar errors appear throughout.
(date) in copyright boilerplate needs to be filled in.
I don't think the copyright on the doc qualifies as an IP
  consideration, so it seems strange to see it as a list item
  in the IP considerations section.

From: Rohit Dube <rohit@utstar.com>
Subject: Re: Working Group Last Call for
        draft-ietf-ospf-scalability-06.txt
Date: Fri, 05 Sep 2003 15:13:54 -0400
To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Cc: fenner@research.att.com, zinin@psg.com

This working group call has ended without further comment.
The drafts now goes back to the ADs.

FYI,
--rohit.

Subject: Re: Working Group Last Call for draft-ietf-ospf-scalability-05.txt
Date: Fri, 13 Jun 2003 11:03:58 -0400
From: Rohit Dube <rohit@xebeo.com>
To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Cc: zinin@psg.com, fenner@research.att.com

This last call has ended and I am forwarding the draft to
the ADs for review.

--rohit.