[Lsr] Subject: RtgDir review: draft-ietf-ospf-ospfv2-hbit-09.txt

"Hejia (Jia)" <hejia@huawei.com> Mon, 07 October 2019 15:08 UTC

Return-Path: <hejia@huawei.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D77B31208A1; Mon, 7 Oct 2019 08:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BMYNy_EFjTBI; Mon, 7 Oct 2019 08:08:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7A2120884; Mon, 7 Oct 2019 08:08:23 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown []) by Forcepoint Email with ESMTP id 029D25C4BFBB41EE5586; Mon, 7 Oct 2019 16:08:21 +0100 (IST)
Received: from dggeme753-chm.china.huawei.com ( by lhreml708-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Oct 2019 16:08:20 +0100
Received: from dggeme754-chm.china.huawei.com ( by dggeme753-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 7 Oct 2019 23:08:18 +0800
Received: from dggeme754-chm.china.huawei.com ([]) by dggeme754-chm.china.huawei.com ([]) with mapi id 15.01.1713.004; Mon, 7 Oct 2019 23:08:18 +0800
From: "Hejia (Jia)" <hejia@huawei.com>
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-ospf-ospfv2-hbit.all@ietf.org" <draft-ietf-ospf-ospfv2-hbit.all@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: Subject: RtgDir review: draft-ietf-ospf-ospfv2-hbit-09.txt
Thread-Index: AQHVfSDASf74B1CiRE6OMJN1o8F8bw==
Date: Mon, 7 Oct 2019 15:08:18 +0000
Message-ID: <9f537c84f27f456187ede2867bd63cb2@huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9f537c84f27f456187ede2867bd63cb2huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/GM1QOa-eMaJ7Qxvg7uPksB_kMXc>
Subject: [Lsr] Subject: RtgDir review: draft-ietf-ospf-ospfv2-hbit-09.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Oct 2019 15:08:27 -0000


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


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


This document is basically ready for publication, but has nits that should be

considered prior to publication.


The draft is short and the problem to be solved is clear, however, some nits

could be fixed to improve the readability.

Major Issues:

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?


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

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

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