Re: [Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)
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) 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 > > Sent: Friday, September 13, 2019 10:06 AM > > To: The IESG > > Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri > > ; aretana.i...@gmail.com; lsr-cha...@ietf.org; > > uma.chund...@huawei.com; lsr@ietf.org > > 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
Re: [Lsr] Barry Leiba's No Objection on draft-ietf-lsr-isis-rfc5306bis-05: (with COMMENT)
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 > Sent: Friday, September 13, 2019 10:06 AM > To: The IESG > Cc: draft-ietf-lsr-isis-rfc5306...@ietf.org; Uma Chunduri > ; aretana.i...@gmail.com; lsr-cha...@ietf.org; > uma.chund...@huawei.com; lsr@ietf.org > 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 >
[Lsr] 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: 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
