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. - Section 6, I feel we should at least add a reference to Section 8.1 of RFC 8402 [ https://tools.ietf.org/html/rfc8402#section-8.1 ] 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 :)? - 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 - Section 5 could use an example to describe the concept clearly 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. 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://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07 > > (*) 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://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
