OSPF for IPv6
draft-ietf-ospf-ospfv3-update-23

[Ballot discuss]
Overall, looks quite good --I have only two comments, both of which
should quite easy to address.

The document should have a section describing the most important
changes compared to RFC 2740, and what things don't interoperate 100%
between implementations of this spec and RFC 2740. (I'm assuming that
Appendix E will be removed by the RFC Editor)

The security considerations text simply points to RFC 4552; however,
OSPF has many security considerations that go beyond authenticating
and encrypting packets. At the very least, the security considerations
section should provide pointers to documents where these are
discussed.

[Ballot comment]
Section 3.2.2., paragraph 8:
>    o  The standard IPv6 16-bit one's complement checksum, covering the
>      entire OSPF packet and prepended IPv6 pseudo-header, must be
>      verified (see Appendix A.3.1).

  It isn't the IPv6 checksum that's being verified, because IPv6 has no
  checksum. It's the *OSPFv3* checksum that's being verified.

[Ballot discuss]
Section 2.5., paragraph 3:
>    On virtual links, a global scope IPv6 address MUST be used as the
>    source address for OSPF protocol packets.

  Discuss-discuss: Why are virtual links being treated differently? They
  should have link-local addresses, too.

[Ballot discuss]
This is a discuss discuss:

RFC 2740 included the following text in its security considerations:

  Most OSPF implementations will be running on systems that support
  multiple protocols, many of them having independent security
  assumptions and domains.  When IPSEC is used to protect OSPF packets,
  it is important for the implementation to check the IPSEC SA, and
  local SA database to make sure that the packet originates from a
  source THAT IS TRUSTED FOR OSPF PURPOSES.

This text does not appear in either RFC 4552’s or ospfv3-update's
security considerations.  I was wondering why this guidance is no
longer appropriate.  Has the basic assumption (OSPFv3 systems will
support multiple protocols) changed?

[Ballot discuss]
This is more a question that an DISCUSS.

Reading Appendix E, I conclude that implementations built according to this spec will be interoperable with implementations that are strictly compliant with RFC 2740. Do I have that right?

If so, you might want to add some text saying that up front. Especially if you intend to remove Appendix E before publication.

I am a little concerned about the following bullet from Appendix E:

Correct field alignment in packet and LSA figures in Appendix A.

If the field allignment were truly different between this document and 2740, wouldn't that introduce an interoperability problem? However, I stared at the figures in the two documents and couldn't see the difference. What does this bullet really mean?

[Ballot discuss]
There is no information on manageability considerations. At a minimum I would expect the document to mention that new objects need to be added in the management model leading to the OSPF MIB needs to be extended and to point as Informational Reference to http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-mib-12.txt

IANA Last Call comments:

Action #1:

Upon approval of this document, the IANA will make the following
assignments in the Open Shortest Path First v3 (OSPFv3)
Parameters" registry located at
http://www.iana.org/assignments/ospfv3-parameters
sub-registry "Registry Name: OSPFv3 Options (24 bits) "

Value Description Reference
--------- ---------------------- ---------
0x000040 Reserved for OSPFv2 migrated options [RFC-ietf-ospf-ospfv3-update-18]
0x000080 Reserved for OSPFv2 migrated options [RFC-ietf-ospf-ospfv3-update-18]


Action #2:

Upon approval of this document, the IANA will make the following
assignments in the Open Shortest Path First v3 (OSPFv3)
Parameters" registry located at
http://www.iana.org/assignments/ospfv3-parameters
"OSPFv3 Prefix Options (8 bits)"

Registry:
Value Description Reference
------- ------------ ---------
0x08 P-bit [RFC-ietf-ospf-ospfv3-update-18]
0x10 DN-bit [RFC-ietf-ospf-ospfv3-update-18]


Action #3:

Upon approval of this document, the IANA will make the following
changes in the Open Shortest Path First v3 (OSPFv3) Parameters"
registry located at
http://www.iana.org/assignments/ospfv3-parameters
sub-registry "Registry Name: OSPFv3 Options (24 bits) "
Value Description Reference
--------- ---------------------- ---------
OLD:
0x000004 MC-bit [RFC1584][RFC5110]

NEW:
0x000004 Deprecated [RFC-ietf-ospf-ospfv3-update-18]


Action #4:
Upon approval of this document, the IANA will make the following
changes in the Open Shortest Path First v3 (OSPFv3) Parameters"
registry located at
http://www.iana.org/assignments/ospfv3-parameters
"LSA Function Code"

OLD:
LSA Function Code LS Type Description Reference
----------------- ---------------------------------- ---------
6 Group-membership-LSA [RFC2740][RFC5110]

NEW:
LSA Function Code LS Type Description Reference
----------------- ---------------------------------- ---------
6 Deprecated [RFC-ietf-ospf-ospfv3-update-18]


Action #5:

Upon approval of this document, the IANA will make the following
changes in the Open Shortest Path First v3 (OSPFv3) Parameters"
registry located at
http://www.iana.org/assignments/ospfv3-parameters
"OSPFv3 Prefix Options (8 bits)"

Registry:
Value Description Reference
------- ------------ ---------
OLD:
0x000004 MC-bit [RFC1584][RFC5110]

NEW:
0x000004 Deprecated [RFC-ietf-ospf-ospfv3-update-18]

Bill, Ross,

I believe the OSPF WG is done with document and it is ready
for AD evaluation. In the last two revisions, I tried to address comments
that we're being made on other draft during the IETF evaluation.

Thanks,
Acee
Acee Lindem wrote:
> We did a WG last call on the 11 version of this document back in October.
> I've updated it with some comments I received offline as well as
> assuring I
> had addressed issues with other drafts being reviewed by the IESG. Please
> look at the 12 and 13 changes (they are described in Appendix E.12 and
> E.13.
> If there are no further comments, I will send it to AD for evaluation
> on December 13th.
> Thanks,
> Acee