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

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 05 December 2019 06: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 131301200C7; Wed, 4 Dec 2019 22:03:27 -0800 (PST)
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 95Wj3xmMihrk; Wed, 4 Dec 2019 22:03:23 -0800 (PST)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 0990A120047; Wed, 4 Dec 2019 22:03:23 -0800 (PST)
Received: by mail-ua1-x92b.google.com with SMTP id z17so803189uac.5; Wed, 04 Dec 2019 22:03:22 -0800 (PST)
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=4lOSD7ZTzycAo9zWuW8+dXrZk9/GZILX9ZisD5nmkG8=; b=dDe3L7fQ4UE6DSo0VVag5bp7L4FnHzig+UbSEIfUBKQj5KlD40RBKn+A8JjxBKp98A EhNaReBY56T2uzxxOMXrMnoEgEaK3qyUoIhow74t52hm7C3iYv7NBj+8BcB7xyMK5w1m m/1Sq86VNdKBgiZmpFO/IY/YhYcXCWUI/acUF4iln2VKVkm7bou4btzpcilnAZn/noQU r8vknK6gUAp3KJPm9YjWKvAsfydUMG6UD6rZPW5sZwkSvMEhIKOhjvk2co9TaXzsqvDv uqAYSU9BcDbsZL6m0NSeOcN9fty0fPU8ic76iSip5s+Yt8/3WyCI86MEra+tH/PPxoIz K6UQ==
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=4lOSD7ZTzycAo9zWuW8+dXrZk9/GZILX9ZisD5nmkG8=; b=sd0scZVwZWy48BGH9tMKshCkcoDYc2k5a6UHvdtonWYBVIaBLLMxLTDEnOkGNpl8Ti QPalEAMxVpfoBobbvbIyCCqX4U9I9xgvv4tmBWrKmlUUe9B5VyD6SikouHJyLxbRiMsC NxRGXnbTLOtcNMDFTbWYeEvhhqIbi7F0WrpfRw5U3jmCTNjQywUyQgWILn/w44hkaK66 gpJHEVA/zBkUCusw8UZ6irzONV4dYhLyjqfmcL6WqEtFTCBs69DFPGhja6Mat2uw9FsQ SwWLzmBpfrxDE1WJDIv9Uvnpfm5PCegjeiXW9aeNnseDff/EZcZZDHRUo4bZJFJwQ95U jDEQ==
X-Gm-Message-State: APjAAAV/+R6amcZ8mltcdhkZcue7DpMLX2A116UPpHYywD1xm7RITeat Iy8wcQnnYkyKymXDDF1SCnihW3N/xXu4mP+O3IE=
X-Google-Smtp-Source: APXvYqyhq6QOrZJO+VNSaM4ZpKEr8hu6XdvaZ4DLk32BYD0el214QdlHvr483uC6nG2GinHk+akkgMxt4Gnf4CRVneA=
X-Received: by 2002:ab0:76cb:: with SMTP id w11mr5831721uaq.139.1575525802030; Wed, 04 Dec 2019 22:03:22 -0800 (PST)
MIME-Version: 1.0
References: <157549244759.11118.14543704768089229965.idtracker@ietfa.amsl.com>
In-Reply-To: <157549244759.11118.14543704768089229965.idtracker@ietfa.amsl.com>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Wed, 4 Dec 2019 22:03:11 -0800
Message-ID: <CAG-CQxrDpJr1L6y3+EknzCxp3Mv18xjrqrHBFmZXqHRMKtjRiA@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
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, Padma Pillay-Esnault <padma.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000c3bbf50598eeafc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/0-BC2oj4lVMv2d-2VlHm8qYr5cI>
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 06:03:27 -0000

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