[Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Fri, 13 September 2019 17:06 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 4313E120110; Fri, 13 Sep 2019 10:06:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-lsr-isis-rfc5306bis@ietf.org, Uma Chunduri <umac.ietf@gmail.com>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, uma.chunduri@huawei.com, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <156839436326.31870.6902174636359362090.idtracker@ietfa.amsl.com>
Date: Fri, 13 Sep 2019 10:06:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/KpoH2z643L3DxcnYUalX8fuXhWk>
Subject: [Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (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: Fri, 13 Sep 2019 17:06:04 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-lsr-isis-rfc5306bis-05: 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-lsr-isis-rfc5306bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this well written document, which I’ve found easy to read and mostly
clear.  I have some editorial comments below, a few related to clarity.  I
realize that some of these apply to text that was in RFC 5306, and I ask you to
please consider them, but I understand if you want to minimize changes from
5306.

— Abstract —

This is entirely an editorial style comment, and no response is needed; just do
what you think best, and if that is to leave it as it is, then that’s fine.  I
find the “This document…  This document additionally…  This document
additionally…” to be awkward, and suggest this instead:

NEW
   This document obsoletes RFC 5306 and describes a set of mechanisms
   that can improve neighbor reconfiguration when a router restarts.
   Using these mechanisms:

   1. A restarting router can signal to its neighbors that it is
   restarting, allowing them to reestablish their adjacencies without
   cycling through the down state, while still correctly initiating
   database synchronization.

   2. A router can signal its neighbors that it is preparing to initiate
   a restart while maintaining forwarding plane state.  This allows the
   neighbors to maintain their adjacencies until the router has
   restarted, but also allows the neighbors to bring the adjacencies down
   in the event of other topology changes.

   3. A restarting router can determine when it has achieved Link State
   Protocol Data Unit (LSP) database synchronization with its neighbors
   and can optimize LSP database synchronization, while minimizing
   transient routing disruption when a router starts.
END

— Section 1 —

   This document describes a mechanism for a restarting router to signal
   that it is restarting to its neighbors, and allow them to reestablish
   their adjacencies without cycling through the down state, while still
   correctly initiating database synchronization.

As this is written, (1) “to its neighbors” is misplaced (it is not “restarting
to its neighbors”) and (2) it sounds like the restarting router is allowing
them to do the reestablishment, but it’s the signal that is.  I suggest this:

NEW
   This document describes a mechanism for a restarting router to signal
   to its neighbors that it is restarting.  The signal allows them to
   reestablish their adjacencies without cycling through the down state,
   while still correctly initiating database synchronization.
END

— Section 3.1 —

   An instance of the timer T2 is maintained for each LSP database
   (LSPDB) present in the system, i.e., for a Level 1/2 system, there
   will be an instance of the timer T2 for Level 1 and an instance for
   Level 2.

Do you really mean “i.e.” here?  Is this the only possible situation, or is it
an example (for which you would want “e.g.”)?  I think it’s the latter, in
which case I would avoid the Latin, use English, and start a new sentence:

NEW
   An instance of the timer T2 is maintained for each LSP database
   (LSPDB) present in the system.  For example, for a Level 1/2 system,
   there will be one instance of the timer T2 for Level 1 and another
   instance for Level 2.
END

   This is initialized to 65535
   seconds, but is set to the minimum of the remaining times of received
   IIHs containing a restart TLV with the Restart Acknowledgement (RA)
   set and an indication that the neighbor has an adjacency in the "UP"
   state to the restarting router.

I found that quite confusing, because the long clause after “minimum of” is
hard to follow (maybe it’s not an issue for readers who are versed in IS-IS). 
I don’t understand what it’s set to (and when it’s set to it, after the initial
value of 65535), and I can’t suggest a rephrasing because I don’t understand. 
Can you try re-wording this (and maybe splitting it into two sentences)?

— Section 3.2 —

   A new TLV is defined to be included in IIH PDUs.  The presence of
   this TLV indicates that the sender supports the functionality defined
   in this document and it carries flags that are used to convey
   information during a (re)start.

The antecedent of “it” isn’t formally clear from the wording.  I suggest this:

NEW
   A new TLV is defined to be included in IIH PDUs, which carries flags
   that are used to convey information during a (re)start.  The presence
   of this TLV indicates that the sender supports the functionality
   defined in this document.
END

   The functionality associated with each of the defined flags (as
   described in the following sections) is mutually exclusive with any
   of the other flags.  Therefore, it is expected that at most one flag
   will be set in a TLV.  Received TLVs which have multiple flags set
   MUST be ignored.

Is there a reason not to say, “Therefore senders MUST NOT set more than one
flag in a Restart TLV.”?  Why aren’t we forbidding it, if the TLV will be
ignored (MUST be ignored) on receipt otherwise?

— Section 3.2.1 —

   b.  immediately (i.e., without waiting for any currently running
       timer interval to expire, but with a small random delay of a few
       tens of milliseconds on LANs to avoid "storms")

Then it’s not “immediately”, right?  Might “promptly” be an appropriate
characterization?  Or is “immediately but with a small random delay” a common
meaning of “immediately” in this context?

(Similar comment for Section 3.2.3.)