Support of Address Families in OSPFv3
RFC 5838
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Lars Eggert No Objection
(Ross Callon; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
A bit odd to have the Acknowledgements in an Appendix
(Alexey Melnikov; former steering group member) No Objection
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?
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
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.
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
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?
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
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.
(Tim Polk; former steering group member) (was No Record, Discuss) No Objection