Hi Adam, Thanks for your review. Some comments inline
-----Original Message----- From: Adam Roach [mailto:[email protected]] Sent: Wednesday, October 11, 2017 00:44 To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Adam Roach's No Objection on draft-ietf-rtgwg-uloop-delay-07: (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-rtgwg-uloop-delay-07: 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-rtgwg-uloop-delay/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document doesn't really define any new on-the-wire protocol. Was publication as a BCP rather than a standards track document considered? The Introduction contains the following text: That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free. I can't parse this sentence. Is there supposed to be a sentence break somewhere in there? [SLI] Good catch, Alvaro saw it also. A break is necessary between "D" and "if a neighbor". The introduction starts talking about post-failure events (e.g., "when S converges to the new topology") before mentioning a failure of the S-D link. This makes it very hard to follow. Would suggest mentioning the failure being considered before talking about the ensuing events. [SLI] Right, I propose: " Consider the case in Figure 1 where S does not have an LFA (Loop Free Alternate) to protect its traffic to D when the S-D link fails. " Section 4 begins: This document defines a two-step convergence initiated by the router detecting a failure and advertising the topological changes in the IGP. This introduces a delay between the convergence of the local router and the network wide convergence. This reads backwards to me. With this technique, the network converges first, followed by an introduced delay, followed by router convergence. Right? [SLI] The network converges first, then the local router thanks to the introduced local delay. Further on in that section: This benefit comes at the expense of eliminating transient forwarding loops involving the local router. I can't make sense of this. Eliminating transient forwarding loops is a good thing, right? Not an expense? [SLI] I think there is a missing word as we mean :" at the expense of eliminating the transient forwarding loops involving the local router ONLY". I also agree that it's not really an expense , but more a limitation. Here is a proposed rewording: " This benefit comes with the limitation of eliminating transient forwarding loops involving the local router only" I agree with Alvaro that the lack of a recommended default for ULOOP_DELAY_DOWN_TIMER is an issue, especially as the values configured in the examples seem to change arbitrarily from 1 second to 2 seconds. [SLI] We cannot propose a default value that would fit all the situations. I agree that a statement is required in the Deployment Section to drive how the timer should be configured. " The ULOOP_DELAY_DOWN_TIMER value should be set according to the maximum IGP convergence time observed in the network (usually observed in the slowest node)." _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
