OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type
RFC 6845
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
(Stewart Bryant; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
Thank you for addressing my Discuss
(Barry Leiba; former steering group member) (was Discuss) No Objection
I don't think this should "Update" any other documents, but the IESG has to sort this point out in general, and we shouldn't hold this document up for that. Total nits, just because I came across them while reviewing; no need to respond to these. -- Section 1 -- OLD to each of the neighboring routers on the network in it's router LSA. NEW (nit; remove apostrophe) to each of the neighboring routers on the network in its router LSA. OLD configuration of the identity of it's neighboring routers. It also NEW (nit; remove apostrophe) configuration of the identity of its neighboring routers. It also Or better... configuration of the identity of neighboring routers. It also OLD network. Further, it mandates establishment of adjacencies to all all configured or discovered neighbors on the network. However, it NEW (nit; duplicate "all") network. Further, it mandates establishment of adjacencies to all configured or discovered neighbors on the network. However, it -- Section 3 -- OLD 2 topology as well as various link quality metrics such as bandwidth, delay and jitter among others. NEW (nit; add comma) 2 topology as well as various link quality metrics such as bandwidth, delay and jitter, among others. -- Section 4.2 -- OLD Routers MUST support an additional field called the Neighbor Output Cost. This is the cost of sending a data packet to the neighbor, expressed in the link state metric. The default value of this field is the Interface output cost. It MAY be set to a different value SHOULD THIS BE (adding capitals)?: [...] The default value of this field is the Interface Output Cost.
(Brian Haberman; former steering group member) (was Discuss) No Objection
Thanks for addressing my DISCUSS points so quickly.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
The use of 2119 language in sections 4.1 and 4.2 is bogus. These are all conformance and configuration statements that have nothing to do (at least as stated) with requirements (or options) for interoperability or prevention of damage. For example, in 4.1:
Routers MUST support configuration of the Router Priority for the
interface.
The default value of the LinkLSASuppression is "disabled". It MAY be
set to "enabled" via configuration.
Change to:
Routers implementing this specification will have a configuration option
for the Router Priority for the interface.
The default value of the LinkLSASuppression is "disabled". It may be
set to "enabled" via configuration.
Similarly for 4.2.
In 4.8, you also have odd constructions with the 2119 language:
o If a router is the DR on the interface, it MUST NOT examine the
pre-restart network LSA for the interface in order to determine
the previous set of adjacencies.
The requirement is not on the examination, it is on the use. I suggest simply:
o If a router is the DR on the interface, the pre-restart network
LSA for the interface MUST NOT be used to determine
the previous set of adjacencies.
For the other bullet:
o If a router is in state DROther on the interface, it MUST consider
an adjacency to non-DR and non-BDR neighbors as reestablished when
the neighbor state reaches 2-Way.
"Considering" is not the requirement. In fact, I suspect this is not a requirement at all, but rather a definition. I think this works better:
o If a router is in state DROther on the interface, an adjacency
to non-DR and non-BDR neighbors is reestablished when
the neighbor state reaches 2-Way.
(Ralph Droms; former steering group member) (was Discuss) No Objection
(Modified after e-mail exchange with Acee Lindem) Expand "DR" and "BDR" on first reference. I cleared my Discuss, deferring to and supporting Barry's Discuss regarding text that explicitly explains how this document updates the OSPF specification.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
Apologies for the delay. I've cleared.
(Stephen Farrell; former steering group member) No Objection
- Its a bit of a concern that the IPR declaration isn't visible on the tools page [1] for this, but is on the tools page for draft-nsheth [2] that preceeded this. Can somoene do whatever's needed to ensure the IPR declaration will be linked from the tools page for the eventual RFC? [1] http://tools.ietf.org/html/draft-ietf-ospf-hybrid-bcast-and-p2mp [2] http://tools.ietf.org/html/draft-nsheth-ospf-hybrid-bcast-and-p2mp - section 3: having read this, the motiviation still isn't very clear to this reader, perhaps a concrete example of different costs of communication that this spec addresses would help. - 4.1 & 4.2: what does " It MAY be set to "enabled" via configuration" in 4.1 mean? It seems like a tautology so I don't know what you're trying to say. Similarly, in 4.2, " It MAY be set to a different value using mechanisms which are outside the scope of this document" is odd. - expanding DR/BDR in 4.4 would be good.
(Wesley Eddy; former steering group member) No Objection