Re: [Lsr] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 31 October 2019 22:51 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 09C7B120090; Thu, 31 Oct 2019 15:51:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 BVnEGWaG-MNE; Thu, 31 Oct 2019 15:50:57 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 A652612001E; Thu, 31 Oct 2019 15:50:57 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id f21so2410688uan.3; Thu, 31 Oct 2019 15:50:57 -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=uJziZOrVtnHWS/Dzyc7GHmuIvUczyZlGb7oC92LP+Cs=; b=bZRHNx8xzB5v4XB1tvA2lOVXA1eNIr/p8h5A5nJevs3ClqUfWKZmUwE+9tY7GhRqmR s/sWZo1LwZ8zR8bbVdp8jCFZsYwdV1ipeWeRa5I1QNVkmRh8maFTO97TyATT+GstdRT4 x0Hkc8a83IMTeGYW7t/ylWyD+CHGuA9Y0cf33RUdwVFi4qiSLh4Gdlhu0ntQR6/J832j lZze9uC9kb9hE4RXA0mXUK0ERTyHDMv+amefYblN0kWHs4DGqfzKhoRIWfk/iJMZvsK9 k5nrEAoPmY3I0E10FRAhplwBNHptGOcPndG+Qs4uBsQGSqJkAVFy+vEf68M9xQTwCBv/ EcNg==
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=uJziZOrVtnHWS/Dzyc7GHmuIvUczyZlGb7oC92LP+Cs=; b=rwUYfOyOZlHhkQ1oN5wDZDXUkDMclE+yqPLFroSK+EHtNBT5Ytsrpf8I8HHXQSYNAW vw5wPOUMSOnyWG5U0HU1LdEALKIUD48PKbzjnGohQAe//7cG0ZK1sga7EfI+Am/h4YGd +o2DXRkrB8PECr6KLiDG9ZE3aqwu4dejOfMyMwXZ5wD315WS2MsOpWJ3TYJCj2/qUvLm nz7cd8uGPEkoRgi72Uq1rxVgx4sbpDzQwt7zD9ogrb1hq/lpW3EQ6HGa83+wVfjSg0aV Kjhtl6pW3D2fxlFLYDAPZIew7QWYt0qwUmiUrXOakQT21NrngWkIR2DXPWIcmgVdT6Bj 3qNA==
X-Gm-Message-State: APjAAAXVASXJh0P0vi8UbnCrOYiwdavFI4hnAQwYE9pvthDbbQ3/hUNC oZXzAMbDAZAl6nsjcEUpqWYrsvc+9SbOWh220Kw=
X-Google-Smtp-Source: APXvYqz6tHeHyWOe7ftHzIGDExqEsHNve6Z4PoESQV2JyhfqnjUbCEIMm6EKbWuWIHJrqA7m71eJu7qGMBkPvhKjB4c=
X-Received: by 2002:ab0:1602:: with SMTP id k2mr4051038uae.103.1572562256731; Thu, 31 Oct 2019 15:50:56 -0700 (PDT)
MIME-Version: 1.0
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com>
In-Reply-To: <157255845092.30400.10881471178799546764@ietfa.amsl.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Thu, 31 Oct 2019 15:50:45 -0700
Message-ID: <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, lsr@ietf.org, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b321f705963cae64"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Jlsxpyv3gXAKeHbb6Fq7_XBD0Rk>
Subject: Re: [Lsr] Tsvart last call review of draft-ietf-ospf-ospfv2-hbit-10
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: Thu, 31 Oct 2019 22:51:00 -0000

Hi Kyle

Thank you for your review

Please see below PPE

On Thu, Oct 31, 2019 at 2:47 PM Kyle Rose via Datatracker <noreply@ietf.org>;
wrote:

> Reviewer: Kyle Rose
> Review result: Ready with Nits
>
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the
> document's
> authors and WG to allow them to address any issues raised and also to the
> IETF
> discussion list for information.
>
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-art@ietf.org if you reply to or forward this review.
>
> This document is basically ready. I have the following comments:
>
> * LSA should be defined where it is first used.
>

PPE - Fixed for next version of draft

* I'm curious what happens if a router sets the H-bit when it is on the only
> feasible transit path.
>

PPE - The router with the H-bit set will not be "on the only feasible
transit path" to other destinations.  The H-bit functionality will exclude
the host router from the path calculation in the SPF.


> * In the security considerations, the document states:
>
> q( The feature, however does introduce the flooding of a capability
>    information that allows discovery and verification that all routers
>    in an area are capable before turning on the feature )
>
> I'm not sure "flooding" is the right term here, as the communication
> comprising the OSPF control plane is not new: only a single bit has a
> new meaning. This statement is also worded awkwardly, but without
> a clearer understanding of what is meant, I don't know that I can
> suggest alternative wording.
>
>
PPE: OSPF will flood the LSA containing the capability... Perhaps
"advertising" instead of flooding.
See below:

OLD:
The feature, however does introduce the flooding of a capability
   information that allows discovery and verification that all routers
   in an area are capable before turning on the feature.

SUGGESTED NEW:
The feature introduces the advertising of a host router capability
information to all OSPFv2 routers
   in an area. This information can be leveraged for discovery and
verification that all routers in the
area support the capability before the feature is turned on.

Please let me know if this addresses your comment.

Thanks
Padma