Hi, Les. Thanks for the response, and for considering my comments. All is good.
Barry On Tue, Sep 17, 2019 at 11:07 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > > Barry - > > Thanx for the thoughtful review. > > I have uploaded V6 of the document to address some (but not all) of your > points. > > More inline. > > > -----Original Message----- > > From: Barry Leiba via Datatracker <[email protected]> > > Sent: Friday, September 13, 2019 10:06 AM > > To: The IESG <[email protected]> > > Cc: [email protected]; Uma Chunduri > > <[email protected]>; [email protected]; [email protected]; > > [email protected]; [email protected] > > Subject: Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: > > (with > > COMMENT) > > > > 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: > > > > [Les:] I appreciate your point - but decided to leave this section as is. > > > 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 > > > > [Les:] This has been revised - though a bit differently than your proposed > text. > > > — 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 > > [Les:] Done. > > > > > 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)? > > > > [Les:] I added a reference to Section 3.2.1a where the details are explained. > > > > — 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 > > [Les:] Revised - again a bit differently than your proposed text. > > > > > 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? > > > > [Les:] This paragraph was added recently as a result of some AD review > comments. I have now also added the prohibition against sending the TLV with > multiple flags set. > > > — 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? > > > > [Les:] Hellos are normally sent at regular intervals (e.g., every 10 seconds) > with jitter applied. > The point being made here with "immediately" is that the normal delay is NOT > to be applied. We want the response to be sent as quickly as possible because > we want the actions associated with the exchange to happen as quickly as > possible. > I do not think "promptly" conveys the same meaning . > > Maybe this helps clarify?? > > Les > > > (Similar comment for Section 3.2.3.) > > > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
