Last Call Review of draft-ietf-ospf-ospfv2-hbit-10
review-ietf-ospf-ospfv2-hbit-10-opsdir-lc-chown-2019-11-07-00
Request | Review of | draft-ietf-ospf-ospfv2-hbit |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2019-11-07 | |
Requested | 2019-10-24 | |
Authors | Keyur Patel , Padma Pillay-Esnault , Manish Bhardwaj , Serpil Bayraktar | |
I-D last updated | 2019-11-07 | |
Completed reviews |
Rtgdir Last Call review of -09
by He Jia
(diff)
Genart Last Call review of -10 by Mohit Sethi (diff) Tsvart Last Call review of -10 by Kyle Rose (diff) Opsdir Last Call review of -10 by Tim Chown (diff) |
|
Assignment | Reviewer | Tim Chown |
State | Completed | |
Request | Last Call review on draft-ietf-ospf-ospfv2-hbit by Ops Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/ops-dir/P88EhPs8chRhr2vcmpeE6CkK5JE | |
Reviewed revision | 10 (document currently at 12) | |
Result | Has nits | |
Completed | 2019-11-07 |
review-ietf-ospf-ospfv2-hbit-10-opsdir-lc-chown-2019-11-07-00
I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes a mechanism by which a node running OSPFv2 can repel transit traffic if it is on the shortest path (and an alternative path exists - though this is not wholly clear in the document). It defines a Host-bit (H-bit) that allows the router to advertise that it is not a transit router, and it describes the changes needed to support the H-bit within a domain, and mitigations against potential routing loops. General comments: Should the document also state that it updates RFC 2328? I think the document could be clearer on the behaviour when the H-bit and MaxLinkMetric are used when there is only one path available, i.e. there is no redundant / alternative path. Section 4 of RFC 6987 implies that if there is only one path the router can still be used as a transit router, by the nature of the definition of MaxLinkMetric. The document has 3 or 4 places where it hints at behaviour, but I think it could be more explicit. It may be worth explicitly stating that OSPFv3 is not mentioned due to it having an R-bit defined for indicating whether a node/router can be used for transit traffic (see Sections 2.7 and A.2 of RFC 5340). The reasons given in Section 1 for the need for the H-bit are different to those given in Section 1 of RFC 6987 for the capability. Should these be more consistent? Also, the document later mentions “a router being gracefully isolated” as a reason, but this is not mentioned in Section 1. Nits: In the abstract: Change “This document defines a bit (Host-bit)” to “This document defines a Host bit (H-bit)” for consistency And “is a non-transit router.”” - remove the spurious “. Section 8: Where it says “beyond those already known in OSPF”, say OSPFv2.