[Lsr] Barry Leiba's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Wed, 04 December 2019 20:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9187712004C; Wed, 4 Dec 2019 12:47:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ospf-ospfv2-hbit@ietf.org, Yingzhen Qu <yingzhen.ietf@gmail.com>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, yingzhen.ietf@gmail.com, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.111.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <157549244759.11118.14543704768089229965.idtracker@ietfa.amsl.com>
Date: Wed, 04 Dec 2019 12:47:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/6rwMh-9_ucnqpp_ZppTklxnwjfo>
Subject: [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
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: Wed, 04 Dec 2019 20:47:28 -0000
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 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 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. 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?
- [Lsr] Barry Leiba's No Objection on draft-ietf-os… Barry Leiba via Datatracker
- Re: [Lsr] Barry Leiba's No Objection on draft-iet… Padma Pillay-Esnault
- Re: [Lsr] Barry Leiba's No Objection on draft-iet… Barry Leiba