Support of Address Families in OSPFv3
RFC 5838

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

(Ross Callon) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ralph Droms) No Objection

Comment (2009-12-01 for -)
No email
send info
A few nites...

From section 1:

   There are requirements to advertise other AFs
   in OSPFv3 including multicast IPv6, unicast IPv4, and multicast IPv4.

Can details about the source and nature of these requirements be provided?


In section 3:

   Currently the entire Instance ID number space is used for IPv6
   unicast. 

Can a reference to this usage specification be cited here?


Expand "LSAs" on first use?


In section 2.2:

  s/When a router supports AF/When a router supports AF Instance IDs/

for clarity?

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2009-11-27)
No email
send info
A bit odd to have the Acknowledgements in an Appendix

(Russ Housley) (was Discuss) No Objection

Comment (2009-12-02)
No email
send info
  The Gen-ART Review by Christian Vogt raised the following:
  >
  > In section 3, "Backwards Compatibility", it may furthermore be worth
  > mentioning that all modifications to OSPFv3, as specified in this
  > document, exclusively affect the use of OSPFv3 for new address families.
  > Since this is a prerequisite for backwards compatibility, it will
  > further support the backwards compatibility claim of this section.

(Cullen Jennings) No Objection

Alexey Melnikov No Objection

Comment (2009-11-28 for -)
No email
send info
Agreeing with Adrian about the missing Updates field.

2.2.  OSPFv3 Options Changes

   A new AF-bit is added to the OSPFv3 options field.  V6-bit and MC-bit
   are only applicable to the IPv6 unicast AF.

I don't see any bit called "MC" in the table below:

                               1                     2
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  9  0  1  2  3
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+
          | | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x | E|V6|
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+--+--+--+

2.7.  Database Description Maximum Transmissoin Unit (MTU)
      Specification for Non-IPv6 AFs

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              6 (TBD)          |               4               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           IPv6 MTU                            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is MTU in network byte order?

(Tim Polk) (was No Record, Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2009-12-02 for -)
No email
send info
I support Adrian's DISCUSS about the need to mention 'update RFC 5340' in the header of the document because of the changing of semantics in the Instance ID. This being said I think that the backwards compatibility section demonstrates that there are no backward compatibility issues, although it would be useful if some text would be added about the limitations of mixing routers compliant with this specification and 'non-capable' routers in the topology, and maybe operational recommendations about the transition of the network to a fully compliant configuration.

(Robert Sparks) No Objection

Magnus Westerlund No Objection