Re: [Lsr] Barry Leiba's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Thu, 05 December 2019 13:44 UTC

Return-Path: <barryleiba@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 077FE12004A; Thu, 5 Dec 2019 05:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.472
X-Spam-Level:
X-Spam-Status: No, score=-1.472 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.073, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 09K5VB2jjLDr; Thu, 5 Dec 2019 05:44:54 -0800 (PST)
Received: from mail-il1-f179.google.com (mail-il1-f179.google.com [209.85.166.179]) (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 2C0D0120020; Thu, 5 Dec 2019 05:44:54 -0800 (PST)
Received: by mail-il1-f179.google.com with SMTP id b15so3006288ila.7; Thu, 05 Dec 2019 05:44:54 -0800 (PST)
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:content-transfer-encoding; bh=nkH8P732wGUJRzCdWGDxIPj9qYSADqpLg1ivSmSqRYQ=; b=XJtxQifuKJZ6gQk6PxKdgXQfCMtkdZ/SQtotKV9xhGVT8QZkOOnuezw2umdYMUSLW2 rqqn/djbfMddLfjEtG+sePsv3ZSTqqE4RS7KcuKK7y8CKFBF0e3RWU6vUej+6QuZPZ7G MDZVNr8PmZeUHMgl2FF3CFJtu0+Z7E/E0UmbCeycoQmNEu8xyjgL7GQ/7VZJjbXgfcjI tsIYWex14NokhuRCjzyPhoEkY0VDJvL0XwS026uM5YqQ3MBAJLGSnly7pmb3qwYQ1sZ2 /uMwmp68ubg9aPLRLxa42WP49LHfjbwIRbDMne157PqUA16k+Es3ZFGFr7Ab0Qb5IqiX rYMg==
X-Gm-Message-State: APjAAAWyCShwm+2GWmgzicH8MGytlzKKui08L3Lh5kwGFwMKLl6ebrGr OYVIBcpu8wM7fpSax3xTq/CLqSd52hZA9la3U+eEBQ==
X-Google-Smtp-Source: APXvYqxMXKy0Fo0MD6fapz2nsFuAAqZoCcQCbThvS3VF397weLIdsaDnriSuz35yDQyEgVpTZLXVPhQ19k6u4hgPz3c=
X-Received: by 2002:a92:5c4a:: with SMTP id q71mr9051048ilb.266.1575553493191; Thu, 05 Dec 2019 05:44:53 -0800 (PST)
MIME-Version: 1.0
References: <157549244759.11118.14543704768089229965.idtracker@ietfa.amsl.com> <CAG-CQxrDpJr1L6y3+EknzCxp3Mv18xjrqrHBFmZXqHRMKtjRiA@mail.gmail.com>
In-Reply-To: <CAG-CQxrDpJr1L6y3+EknzCxp3Mv18xjrqrHBFmZXqHRMKtjRiA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Thu, 5 Dec 2019 08:44:42 -0500
Message-ID: <CALaySJJLRLCtRa=p7kW6cYCK0L2wpB9BsQybOEN7iCv1kQ+NfQ@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ospf-ospfv2-hbit@ietf.org, Yingzhen Qu <yingzhen.ietf@gmail.com>, Alvaro Retana <aretana.ietf@gmail.com>, lsr-chairs@ietf.org, lsr@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/T4YhJoW_d7fslu7QkdUCV3cZk24>
Subject: Re: [Lsr] Barry Leiba's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)
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, 05 Dec 2019 13:44:56 -0000

Thanks, Padma... the new paragraph now seems completely clear to me!
Thanks for the work on this.

Barry

On Thu, Dec 5, 2019 at 1:03 AM Padma Pillay-Esnault
<padma.ietf@gmail.com> wrote:
>
> Hi Barry
>
> Thank you for your review
>
> See below PPE for my comments
>
> On Wed, Dec 4, 2019 at 12:47 PM Barry Leiba via Datatracker <noreply@ietf.org> wrote:
>>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-ospf-ospfv2-hbit-11: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'm going to complain about some wording in Section 5 that Ben already called
>> out, but I'll try to put in some specific suggestions for corrections here:
>>
>>    In normal operation, there is no guarantee that the RI LSA will reach
>>    all routers in an area in a timely manner, which may result in
>>    forwarding loops in partial deployments.
>>
>> This wording makes it sound exactly the opposite of what you mean, that if the
>> RI LSA *does* reach all routers in a timely manner it can cause forwarding
>> loops.  I suggest this:
>>
>> NEW
>>    In normal operation, it is possible that the RI LSA will fail to
>>    reach all routers in an area in a timely manner.  That can result
>>    in forwarding loops in partial deployments.
>> END
>>
> PPE - See below for the whole paragraph change.
>
>>
>>    For example, if a new
>>    router joins an area, which previously had only H-bit capable routers
>>    with H-bit set then it may take some time for the RI to propagate to
>>    all routers.
>>
>> First, change "area, which" to "area that" (no comma).  That fixes a usage
>> problem.
>>
>> But second, Ben and I are both unsure whether you mean that the new router does
>> or doesn't support the H bit, or whether it matters.  Maybe the right approach
>> here is to say a little more about what happens.  Something like this (adjust
>> as needed to make it correct):
>>
>> NEW
>>    For example, if a new
>>    router joins an area that previously had only H-bit capable routers
>>    with H-bit set then it may take some time for the RI to propagate to
>>    all routers.  While it is propagating, the area as a whole is unsure of
>>    the status of the new router, and that can cause <what problem?>
>> END
>>
>
> PPE - I see what you mean.
> See below combining your suggestion and the one I made to Ben earlier.
>
> Suggested NEW (whole paragraph):
> In normal operation, it is possible that the RI LSA will fail to reach all routers in an area in a timely manner.  For example, if a new router without H-bit support joins an area that previously had only H-bit capable routers with H-bit set then it may take some time for the RI to propagate to all routers. While it is propagating, the routers in the area will gradually detect the presence of a router not supporting the capability and revert back to normal SPF calculation. During the propagation time, the area as a whole is unsure of the status of the new router, and that can cause temporary transient loops.
>  END
>
>>    o  All routers, with the H-bit set, MUST advertise all of the
>>       router's non-stub links with a metric equal to MaxLinkMetric
>>
>> Both commas need to be removed here.
>
>
> PPE - ok
>>
>>
>>    o  All routers supporting H-Bit MUST check all the RI LSAs of nodes
>>       in the area before actively running the modified SPF to account
>>       for the H-bit in order to verify that all routers are in routing
>>       capability.
>>
>> This is very awkwardly worded and is really hard to decipher.  I *think* you
>> mean to say this:
>>
>> NEW
>>    o  All routers supporting the H-Bit MUST check the RI LSAs of all
>>       nodes in the area to verify that all nodes support the H-Bit before
>>       actively using the H-Bit feature.
>> END
>
>
>>
>> Did I get that right?
>>
>
> PPE - Yes you did. I will adopt the suggestion above. It is close to what I suggested to Ben earlier.
>
> Let me know if this addresses all your comments
>
> Padma