Skip to main content

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