Hi Stefano, Thanks for the great improvments in the text.
Few more comments : §2 : I still have an issue with : "the two paths are installed in the forwarding plane of A." This works for sure, and in this case it would be good to mention that paths are working in a FRR approach providing sub-50msec restoration. But I think it's too restrictive as path protection can be achieved by pre-computing T2 but not installing it in FIB (just present at RIB level or tunnel table => control plane level), so when T1 fails, T2 is pushed to FIB immediately. It would be good to let both options opened as primary/backup LSPs with path protection can be implemented in both ways depending the level of service that we want to achieve for the restoration. §3.1 : What about SRLG protection ? you provided text for link and node protection, it would be good to provide some for SRLG as well. §4 : Again, not sure that SRLG is a good example as it can be achieved using management free local protection. Could you find a more relevant example that could not be achieved through management free local protection ? maybe a BW or latency case ? §4.2 : It would be good to add that the repair path customization should be on a per destination basis. As told it's more a per destination protection. I'm wondering if it would be better to name it in such way rather than using shortest path protection. What do you think ? §9 : "Also, necessary mechanisms SHOULD be provided ... to control when a repair path ..." "When" is important, but "how" is also important, especially for managed protection. Would be good to add this. Best Regards, Stephane -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] Sent: Monday, September 19, 2016 19:44 To: LITKOWSKI Stephane OBS/OINIS Cc: SPRING WG Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt Hi Stephane, this version hopefully addresses your comments. Let me know if there’s anything that still needs to be addressed. Thanks. s. > On Sep 19, 2016, at 7:39 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking of the > IETF. > > Title : Use-cases for Resiliency in SPRING > Authors : Clarence Filsfils > Stefano Previdi > Pierre Francois > Bruno Decraene > Rob Shakir > Filename : draft-ietf-spring-resiliency-use-cases-05.txt > Pages : 11 > Date : 2016-09-19 > > Abstract: > This document identifies and describe the requirements for a set of > use cases related to network resiliency on Segment Routing (SPRING) > networks. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-case > s/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-cas > es-05 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _________________________________________________________________________________________________________________________ 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
