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

Padma Pillay-Esnault <padma.ietf@gmail.com> Fri, 11 October 2019 03:03 UTC

Return-Path: <padma.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AB71201CE; Thu, 10 Oct 2019 20:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cCfuu70TELTd; Thu, 10 Oct 2019 20:03:25 -0700 (PDT)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6219F120180; Thu, 10 Oct 2019 20:03:22 -0700 (PDT)
Received: by mail-vs1-xe35.google.com with SMTP id p13so5315209vsr.4; Thu, 10 Oct 2019 20:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gVjJnzRPT302UhDTDqL46xYGNh3/E5LUmJhwzOmP3ac=; b=FlyfbdZj/MnRf1sPuW28bO/XI3L6sMMcIfvAUpa2Y/ze67Qn0kKzNiGRTJMU1ifmYY EsFocFTdYp8cRYwHfm1ye8g17IxtIe5y7MQm9YO3IldQoNtFLHcE2wjDIqGXQukUjhC/ lB7B7VUlSvWIDYR1TwgTEpnpqjn8Z1+bxSFDPGk6wAKdxbgeuBb6m7JL+a5BJXa/vHVO wCfC7kYTJZZg2FRwLTQOHywKjuoUBpalhZ/fNOJIVLmKaBPupp8vZRx0Km89gSmANwfm Zv4gt/akIBAXCQmA6t3oyLIDn9dReaDlTP6GupYudNigC6MXYl1oczlW+HJ8Ze5MBQyT gE2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gVjJnzRPT302UhDTDqL46xYGNh3/E5LUmJhwzOmP3ac=; b=t23WC45fuwPNGLIuv1uc+BcQMnmZ4eE/D8SG4Pu18SIydB2leTrTBkoU+6urlOckr6 FYAt8/i785GU/6PNZSlWzqNl0IhCgozDhfTwGCg4Ag8t9Io90y8z8mAN6NOrXqTLPgDl oHcdC2rQgfE5XSR2bo81BjetSjNypul7JcwazK+JUuOzrprll1O54PiGxr9FHNMkGlT5 RsWpVtMHncr82quJCHvypT0uMPCOX6RJaU7VKzeDZyhUCAErsTTn+V25uy9Re1DbM14b +LwUBhLJnkDEReNFZ4/67iUCn2xW8QCabwVpga3QtPUItwYNsVenVoI9BBCelVovIi32 QT1g==
X-Gm-Message-State: APjAAAXJkn88HqwWdCob44sHQ76eh7eUZR6kzsR5UU2MDF4vpjgGExDV WE1Y6aTNgfGNPDaO04qGM4G5IItyv687iiZ4Iq4=
X-Google-Smtp-Source: APXvYqxcss4K74Eq+fwe0ZQmBoOo857eLVTDm/pTk9IszZHAae9+TyZFGj1rRky+WM44vtsp4Ce8ySueVkbuXJe86yc=
X-Received: by 2002:a67:e3d0:: with SMTP id k16mr7678068vsm.205.1570763001247; Thu, 10 Oct 2019 20:03:21 -0700 (PDT)
MIME-Version: 1.0
References: <9f537c84f27f456187ede2867bd63cb2@huawei.com>
In-Reply-To: <9f537c84f27f456187ede2867bd63cb2@huawei.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Fri, 11 Oct 2019 05:03:09 +0200
Message-ID: <CAG-CQxpcbO_7EiJmBktbXCN=wVu3Xu2TspBNgOb6WWjdu+cDZw@mail.gmail.com>
To: "Hejia (Jia)" <hejia@huawei.com>
Cc: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "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>, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b73bad059499c27a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/7-BeIWc5sf2QZ-XCIo7yzb8Nxfs>
Subject: Re: [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: Fri, 11 Oct 2019 03:03:41 -0000

Hello Jia

Thank you for your review.

On Mon, Oct 7, 2019 at 5:08 PM Hejia (Jia) <hejia@huawei.com>; wrote:

> 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?
>
>
> PPE> This has been discussed with the AD and it was deemed that changes
are additions to RFC2328 but does not require a change in RFC2328. The
conclusion of those discussion are NOT to add 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.
>

PPE> OK will made the modifications

>
> 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"?
>

PPE> Agree to this suggestion for clarity.

>
> 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
>

PPE> Agree to the change

>
> 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
>
> PPE> in this context we meant not to be used as a transit router.

>
> 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
>
> ppe> agree

>
> 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
>
>
PPE> Agree to this change

> 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
>
> PPE> Agree to the change

> 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
>
> PPE> we believe avoid is the correct term as for last resort it will not
"prevent" the router being used.

Thanks

Padma

>
> B.R.
> Jia
>
>
>