Last Call Review of draft-ietf-ospf-ospfv2-hbit-09
review-ietf-ospf-ospfv2-hbit-09-rtgdir-lc-jia-2019-10-07-00
Request | Review of | draft-ietf-ospf-ospfv2-hbit |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2019-10-05 | |
Requested | 2019-09-15 | |
Requested by | Acee Lindem | |
Authors | Keyur Patel , Padma Pillay-Esnault , Manish Bhardwaj , Serpil Bayraktar | |
I-D last updated | 2019-10-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 | He Jia |
State | Completed | |
Request | Last Call review on draft-ietf-ospf-ospfv2-hbit by Routing Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/Z0_hG6SLsmlKSE7jSQc9ELXchUc | |
Reviewed revision | 09 (document currently at 12) | |
Result | Has nits | |
Completed | 2019-10-07 |
review-ietf-ospf-ospfv2-hbit-09-rtgdir-lc-jia-2019-10-07-00
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-ospf-ospfv2-hbit-09.txt Reviewer: Jia He Review Date: 07 October 2019 IETF LC End Date: date-if-known Intended Status: Standards Track Summary: This document is basically ready for publication, but has nits that should be considered prior to publication. Comments: The draft is short and the problem to be solved is clear, however, some nits could be fixed to improve the readability. Major Issues: None Minor Issues: 1) The current version updates RFC6987 only. However, there are modifications to RFC2328 as described in the draft. Any thought of adding RFC2328 in the update? Nits: 1) There are several forms of h-bit throughout the document, e.g. Host-Bit (H- bit),H-Bit, Host Bit.... It is better that they are aligned. 2) Introduction, This document describes the Host-bit (H-Bit)functionality that prevents other OSPFv2 routers from using the router for transit traffic in OSPFv2 routing domains. The difference between "other OSPFv2 routers" and "the router" is not clearly described. How about replacing "the router" with "the host router" or "the router with H-bit set"? 3) Section 3, If the host-bit is NOT set routers MUST act transit routers as described in [RFC2328] ensuring backward compatibility. s/act transit routers/act as transit routers 4) Section 4, If this is a router-LSA, and the H-bit of the router-LSA is set, and vertex V is not the root, then the router should not be used for transit s/used for transit/used for transit traffic 5) Section 5, To avoid the possibility of any routing loops due to partial deployment, this document defines a OSPF Router Information (RI) LSA [RFC7770] with and an area flooding scope and a new bit assigned in the OSPF Router Informational Capability Bits Registry. s/with and/within 6) Section 5, " Auto Discovery via announcement of the Host Support Functional Capability", To get aligned with the naming in the OSPF Router Informational Capability Bits Registry, s/Host Support Functional Capability/Host Router Support capability 7) Section 5, For example, in a new router joins an area which previous had only H-bit capable routers with H-bit set then it may take some time for the RI to propagate to all routers. s/in a new router joins an area which previous had only H-bit capable routers with H-bit set /when a new router joins an area which previously had only H-bit capable routers with H-bit set 8) Section 5, All routers, with the H-bit set, MUST advertise all of the router's non-local links with a metric equal to MaxLinkMetric in its LSAs in order to avoid OSPFv2 (unless last resort) routers not supporting the H-bit from attempting to use it for transit traffic. s/avoid/prevent B.R. Jia