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

Kyle Rose <krose@krose.org> Mon, 09 December 2019 16:27 UTC

Return-Path: <krose@krose.org>
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 24146120052 for <lsr@ietfa.amsl.com>; Mon, 9 Dec 2019 08:27:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 Twu__wnjCVET for <lsr@ietfa.amsl.com>; Mon, 9 Dec 2019 08:27:55 -0800 (PST)
Received: from mail-yw1-xc33.google.com (mail-yw1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (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 8FAE21200CE for <lsr@ietf.org>; Mon, 9 Dec 2019 08:27:55 -0800 (PST)
Received: by mail-yw1-xc33.google.com with SMTP id l14so6022184ywh.1 for <lsr@ietf.org>; Mon, 09 Dec 2019 08:27:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nRfzSkkrSDaI2MmMZCoN/XlNeXaY43s5Uw+r0CCQk+Y=; b=OrwAiiOXuIrbVL+cX2FGRs9PdxfapGaGi0tLsoSI/UP0DZ+EtlJ83SSI2IWGaXfiju chdVtJ7weRqz3girNMAUKk3qAyvIk3T0SaNyabVIc0xcAP7UU752cPRndu5eaMyc4Ubj WPZ1IUMTaWYeHOEFscqW8PBHXrPl8PhRdUDqY=
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=nRfzSkkrSDaI2MmMZCoN/XlNeXaY43s5Uw+r0CCQk+Y=; b=pPW6BQXU3J5p6QdcUxFja6BoE/XMzLjiM8WJVo2XLFAKXEg9EHMDq6emjDOBTm9aZO 3Xz2dWPztFM2XsoOIlnb7QT9E2oFvPlX7/+2htNhLoUe4OWZPlBFfSp0GpnBXzuElMah RFgK370OdxnZUrbIg1XQ4mHKmYvP8wnPXhwS9bRCSzWv4XMp2nPfYqt6o6a+KTlxO2Q6 EsLbci07uUaJkFm9TX2z1QHdUtQX2HtxYNurlbsACvRiZ5eKwEzINzh4daMIbZ3Vq8dg 4wdjXWCHkOo/QM2u+dEz9YlPA4tUKbMPYumO/Bf6kL0sYzTTcVjNhK3UkwzaExWtl8ZB WyFg==
X-Gm-Message-State: APjAAAXw5jlUHp9bBS18iPvePn/qrBbW9yc2NFClfoOfGh3gBmlx2Ycn g+0/7+lFn0C9Eqli+jqB8+rU5afeZQVwzOB1Plyh4A==
X-Google-Smtp-Source: APXvYqzw8zpkHnhZ1EfvIQj/O4wyJTmG4EHnZPYNov2SF0ZU6ia0ydoMPzhMNKGaaGZ4I6k6KklRZ/UVEPH0y4phcRg=
X-Received: by 2002:a81:50d6:: with SMTP id e205mr21232177ywb.208.1575908874526; Mon, 09 Dec 2019 08:27:54 -0800 (PST)
MIME-Version: 1.0
References: <157255845092.30400.10881471178799546764@ietfa.amsl.com> <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com>
In-Reply-To: <CAG-CQxr2OJgHgLZMC0kmK1U6=OhrEggGH0K-zFE9uVXyd9KcqQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 9 Dec 2019 11:27:43 -0500
Message-ID: <CAJU8_nXjqUV5Gg0aAQoWfiB1OZ0vh6ViHvOOvS-vpZ7Be_FkGA@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: TSV-ART <tsv-art@ietf.org>, last-call@ietf.org, draft-ietf-ospf-ospfv2-hbit.all@ietf.org, lsr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000aa3cac059947e0a0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VfKxoLXw2-wpzsWeXiJmVtpy7Xg>
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: Mon, 09 Dec 2019 16:27:58 -0000

Draft 11 satisfies all points I made in my review. Thanks.

Kyle


On Thu, Oct 31, 2019 at 6:50 PM Padma Pillay-Esnault <padma.ietf@gmail.com>;
wrote:

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