OSPFv2 Multi-Instance Extensions
RFC 6549

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

(Jari Arkko) Yes

(Stewart Bryant) Yes

(Adrian Farrel) (was Discuss) Yes

Comment (2012-01-15)
No email
send info
I have a few additional Comments that I think would improved the
document and I hope you will consider incorporating them into a new
revision.

---

The Abstract is very dense. Nothing wrong with what you have written,
but it's quite hard work. How about...

   OSPFv3 includes a mechanism to support multiple instances of the
   protocol running on the same interface.  OSPFv2 can utilise such a
   mechanism in order to support multiple routing domains on the same
   subnet.

   This document defines the OSPFv2 instance ID to enable separate
   OSPFv2 protocol instances on the same interface.  Unlike OSPFv3 where
   te instance ID can be used for multiple purposes, such as putting the
   same interface in multiple areas, the OSPFv2 instnce ID is reserved
   for identifying protocol instances.

   This document updates RFC 2328.

Note that I have left out of the Abstract the statementabout how a
different funciton is supported by a diffenent protocol extension defined
in a different document!

---

You are inconsistent about whether to say "OSPF" or "OSPFv2" when
refering to OSPFv2. Given that you keep comparing to OSPFv3, I think it
would be helful to always say "OSPFv2".

---

You use phrases such as "OSPFv2 currently doesn't offer" which are, of
course, correct before this becomes an RFC, whereupon they become wrong.
If you can avoid this sortof thing by saying "This document defines..."
then the draft is future-proofed.

---

Can you please replace the future tense with the present tense. For
example, Section 3

   OSPF [OSPFV2] describes the conceptual interface data structure in
   section 9.  The OSPF Interface Instance ID will be added to this
   structure.  The OSPF Interface Instance ID will default to 0.

---

Section 3.1

   When sending OSPF packets, if the OSPF Interface Instance ID has a
   non-zero value, it will be set in the OSPF packet header.

Surely the zero value is also set in the packet header. That is, the
field is not left uninitialised.

(Ron Bonica) No Objection

Comment (2012-01-16 for -)
No email
send info
I agree whole-heartedly with Adrian's Discuss regarding redefining fields from another RFC rather than referencing them. 

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2012-01-19)
No email
send info
Yep, I agree with all the "what a hack" comments. OTOH, I 
do agree that its not likely that a 256th auth type will be
needed here.

I also agree that the abstract is very unclear and should be
rewritten.

(Russ Housley) No Objection

(Pete Resnick) No Objection

(Dan Romascanu) (was Discuss) No Objection

(Peter Saint-Andre) No Objection

Comment (2012-01-17 for -)
No email
send info
Although the authors appear to have documented the interoperability implications of reducing the AuType field from 2 octets to 1 octet, that still feels like a hack to me. However, I lack the context to judge whether the implications have been fully understood or documented. (Note also that this issue is not even mentioned in the shepherd writeup!)

(Robert Sparks) No Objection

Comment (2012-01-16 for -)
No email
send info
The abstract (identical to the introduction except for references) doesn't actually describe what this document does.

(Sean Turner) No Objection

Comment (2012-01-18 for -)
No email
send info
I'm with Peter on this draft - I too lack the background and ultimately trust that the AD is doing the right.  But, I am curious why this wouldn't be a version # change especially if it affects all implementations.