Skip to main content

Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance
draft-ietf-ospf-scalability-09

Discuss


Yes

(Allison Mankin)
(Bill Fenner)

No Objection

(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
(Thomas Narten)

Note: This ballot was opened for revision 09 and is now closed.

Steven Bellovin Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2004-06-21) Unknown
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?
Alex Zinin Former IESG member
Yes
Yes (2004-06-24) Unknown
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.
Allison Mankin Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
Yes
Yes () Unknown

                            
Bert Wijnen Former IESG member
(was Discuss) No Objection
No Objection (2003-12-18) Unknown
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.
David Kessens Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-06-23) Unknown
Reviewed by Spencer Dawkins, Gen-ART
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Ned Freed Former IESG member
No Objection
No Objection (2003-12-13) Unknown
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.
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2003-12-16) Unknown
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.
Thomas Narten Former IESG member
No Objection
No Objection () Unknown