Dhruv, Thanks for the detailed review and comments.
Pls see inline for replies. Juniper Business Use Only -----Original Message----- From: Dhruv Dhody <[email protected]> Sent: Thursday, August 20, 2020 7:38 PM To: [email protected] Cc: [email protected]; [email protected] Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths [External Email. Be cautious of content] Hi WG, Authors, I support adoption. Looking forward to changes as per the discussion in the other thread started by Joel. I found a few things that can increase the readability of the document. Minor - The document doesn't use normative keywords of RFC 2119 (RFC 2119 is in reference somehow still). I am wondering if section 3 and 4 could use them esp section 4. <shraddha> This document is intended to be informational document and will not use normative language. Will remove reference to 2119. Section 4 is a guidance on How this feature interacts with micro-loop avoidance. The normative text should most likely go to micro-loop avoidance draft on how the node failures Should be consistently detected. - Section 6, I feel we should at least add a reference to Section 8.1 of RFC 8402 [ https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8402*section-8.1__;Iw!!NEt6yMaO-gk!SLaOSAoItlCpdxOjxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P97QOeGYPHkW6l$ ] to provide a helpful pointer. Can we add some text regarding the context labels - that they do not impose any security issues with a suitable reference (provided that is true :)? <Shraddha> Sure will add. - Can we expand "externally visible forwarding behavior", the reference to draft-bashandy-rtgwg-segment-routing-ti-lfa but I don't see that term being used there <Shraddha> section 6.2 in draft draft-bashandy-rtgwg-segment-routing-ti-lfa Talks about the externally visible behavior. Will refer to the section to make it clear. - Section 5 could use an example to describe the concept clearly <Shraddha> ok. Will add Nits - Expand sids in abstract - Expand SRGB on first use - Should we state it clearly that this document is applicable for SR-MPLS only! - Suggest to use RFC 8402 notations for the all sids: Node-SIDs, Adj-SIDs, BSIDs instead of node-sids, adjacency-sids, binding-sids - Section 2, not sure about "SPRING enabled on each node" - Section tile for 2.1 and 2.3: I am not sure about the terms "node-sid explicit paths" and "adj-sid explicit paths" where the later is actually a mix of node-sids and adj-sids. Perhaps rename them as - section 2.1 to "Node protection for explicit paths with Node-SIDs" and 2.3 to "Node-protection for explicit paths with Adj-SIDs"? - Figures, add a legend stating what does the values "10", "30", "60" on the links mean - it is clear that it is cost, but would be good to be explicit. <shraddha> Thanks for pointing out. Will fix them in the upcoming version. Thanks! Dhruv On Thu, Jul 30, 2020 at 5:54 PM <[email protected]> wrote: > > Hi SPRING WG, > > > > Authors of draft-hegde-spring-node-protection-for-sr-te-paths [1] have asked > for WG adoption. > > > > Please indicate your support, comments, or objection, for adopting > this draft as a working group item by August 20th 2020. (*) > > > > Could those who are willing to work on this document, please notify the list. > That gives us an indication of the energy level in the working group to work > on this. > > > > Thanks, > > Regards, > > Bruno, Jim, Joel > > > > [1] > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-sp > ring-node-protection-for-sr-te-paths-07__;!!NEt6yMaO-gk!SLaOSAoItlCpdx > Ojxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P97QOeGTxjGU8f$ > > (*) 3 weeks to account for the IETF meeting week and the august/summer period. > > > > ______________________________________________________________________ > ___________________________________________________ > > 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. > > _______________________________________________ > spring mailing list > [email protected] > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri > ng__;!!NEt6yMaO-gk!SLaOSAoItlCpdxOjxp4lwQYk7pKG1Y42tXizJ2oljTOh8n3md5P > 97QOeGa8BZYp4$ _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
