Hi Alvaro Thanks for your review. Please find some comments below
-----Original Message----- From: Alvaro Retana [mailto:[email protected]] Sent: Tuesday, October 10, 2017 22:51 To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Alvaro Retana's Discuss on draft-ietf-rtgwg-uloop-delay-07: (with DISCUSS and COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-rtgwg-uloop-delay-07: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.1. (Definitions) refers to a couple of “existing IGP timers”. I understand the concepts, but can you please reference the IGP documents where these timers are defined? I quickly checked rfc2328 and couldn’t find a specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a similar concept. SPF_DELAY seems to be introduced by I-D.ietf-rtgwg-backoff-algo. Given that the rest of Section 5. (Specification) is built on these “existing IGP timers”, I think that the references should be Normative. [SLI] ISIS does have the minimumLSPGenerationInterval defined in the ISO specification. I will add it. For OSPF, I do not see the equivalent in the base spec. I will check with Acee if he knows some references or if it's purely local features that have been implemented. Note also that the description in Section 5.2. (Current IGP reactions) is described (in 5.3) as the “standard IP convergence” and carries a “MUST” associated with it. It was mentioned (in 5.1) that the timers in question are “often associated with a damping mechanism”, which is not part of the base IGP specifications. [SLI] I agree with your point. I think that the "standard" word is badly used it and "regular" may be more appropriate. The behavior defined in 5.2 cannot be defined as a standard, as it clearly depends on the implementation and additional timers may be involved. My proposal is to: - change the word "standard" to "regular" in section 5.3 - change the title of Section 5.2 to "Regular IGP reaction" to accommodate the change in 5.3 - In 5.2, modify slightly the text as follows: " Upon a change of the status of an adjacency/link, the regular IGP convergence behavior of the router advertising the event involves the following main steps: " It's important to keep the "MUST" in section 5.3, as applying the delay timer to complex outages is dangerous and may lead to side effects. I’m putting this comment in as a DISCUSS given that understanding the definitions (and having then Normative references) is necessary for the implementation of the mechanism described. I think it should be easy to resolve by just adding the appropriate references. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Where do the numbers in the “Route computation event time scale” table come from? Please put a reference or at least some guidance to the origin of the information. If it's just for informational purposes, then please say so. BTW, please also put a number on the table. [I have the same question for the tables in Section 9.] [SLI] That's purely an example. I'm adding some statements before each table to make it clear. " The table 1 below describes a theorical sequence of events happening when the B-C link fails. This theorical sequence of events should only be read as an example." " The table 5 is based on a theorical sequence of event that should only been read as an example." (2) Section 5.4. (Local delay for link down) specifies that “update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.” When would ULOOP_DELAY_DOWN_TIMER not be applied? [SLI] The text states " If the condition of a single local link-down event has been met ". The "otherwise" is linked to this statement. This means that the FIB/RIB SHOULD be updated immediately when this condition is not met. (2)Along the same lines, if there’s no delay mentioned in Step 5 of 5.3, when would the RIB/FIB not be updated immediately? IOW, why are these “SHOULDs” not “MUSTs”? [SLI] Do you refer to 5.2 (and not 5.3) as there is no Step 5 in 5.3. In 5.2, the RIB/FIB are updated immediately after the SPF computation. (3) What should be the default setting for ULOOP_DELAY_DOWN_TIMER? Section 9. (Examples) shows a couple of manually configured (?) scenarios, but no guidance is present in the document. Please include guidance (maybe based on the local network convergence, or even a default that manufacturers can use) in the Deployment Considerations section. [SLI] Make sense, we cannot propose a default value as it should be adjusted based on the convergence time of the network. I will add a statement in the deployment consideration (4) Section 11. (Existing implementations). Please take a look at RFC7942. Thanks for the pointer, I'm updating it. Does it look better like this ? " 11. Implementation Status At this time, there are three different implementations of this mechanism. o Implementation 1: * Organization: Cisco * Implementation name: Local Microloop Protection * Operating system: IOS-XE * Level of maturity: production release * Coverage: all the specification is implemented * Protocols supported: ISIS and OSPF * Implementation experience: tested in lab and works as expected * Comment: the feature gives the ability to choose to apply the delay to FRR protected entry only * Report last update: 10-11-2017 o Implementation 2: * Organization: Cisco * Implementation name: Local Microloop Protection * Operating system: IOS-XR * Level of maturity: deployed * Coverage: all the specification is implemented * Protocols supported: ISIS and OSPF * Implementation experience: deployed and works as expected * Comment: the feature gives the ability to choose to apply the delay to FRR protected entry only * Report last update: 10-11-2017 ... " Nits: s/any traffic destined to D if a neighbor did not/any traffic destined to D; if a neighbor did not s/can be work/can work “IGP shortcut feature”: a reference would be nice _________________________________________________________________________________________________________________________ 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
