Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols
RFC 6827
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(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) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- 6.1 says the router IDs SHOULD NOT be zero but I don't get when it'd be ok for zero to be used (just asking as its always good to say when going against a SHOULD NOT is fine). - I wondered if the combination of exporting routing information up, down and sideways, and dealing with not-quite overlapping ASON and OSPF hierarchical concepts might increase the probability of error here to the point where this draft ought say something about that. I don't know the answer, just asking. - Is the definition of looping in 7.2 appropriate? Why are only ASON-specific loops considered? Why not consider anything that causes a routing loop, regardless? - 7.2.1, 2nd last para, should that "must" be a "MUST" in "The RA ID value must be a unique identifier for the RA within the ASON routing domain." - I was surprised not to see the string "ASON" in any of the TLV names defined here. - Section 9, 2nd para: How can message authentication improve security against passive attacks? Seems plain wrong. Adding crypto for integrity/authenticaiton is purely to prevent/detect active attacks. My suggestion is to do s/secure against passive attacks and// - Section 9, 3rd para: Signatures do not by themselves provide stronger security than MACs. That all depends on key management and specific algorithms. I'd argue to just delete that paragraph.
(Stewart Bryant; former steering group member) (was Discuss) No Objection
This is a well written document. Since the security of this mechanism is fundamentally associated with the security of OSPF, an informational reference to draft-ietf-karp-ospf-analysis would seem useful to the reader.
(Wesley Eddy; former steering group member) No Objection