Hi Stephane, I incorporated your last comments and submitted a new version of the draft. Let me know if it addresses your comments.
Thanks. s. > On Sep 23, 2016, at 12:10 PM, stephane.litkow...@orange.com wrote: > > Hi Stefano > > Answers inline > > Best Regards, > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent: Thursday, September 22, 2016 18:18 > To: LITKOWSKI Stephane OBS/OINIS > Cc: SPRING WG > Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt > > Hi Stephane, > > >> On Sep 20, 2016, at 2:07 PM, stephane.litkow...@orange.com wrote: >> >> 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. > > > I’m ok with that but note that the whole paragraph starts with “For > example...” which means that it is just to illustrate one possible way. > > So, I will remove the “installation" part of the paragraph. > > >> 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. > > > I agree but I wouldn’t even try to list all the options... > > [SLI] The idea is not to list all options but not to close options. As it is > written now, it looks as the only supported use cases will be the FRR use > case that you are presenting. So here, I just want the text to be more open. > > >> §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. > > something like: > In case of SRLG protection, the bypass will avoid > members of the same SRLG of the protected link. > > [SLI] Yes, you need to add also that the path will need to merge asap of the > primary path (bypass case). > > >> §4 : >> Again, not sure that SRLG is a good example as it can be achieved using >> management free local protection. > > > I agree. Note that the example works the same in case of BW constraint too. > > [SLI] Right > >> Could you find a more relevant example that could not be achieved through >> management free local protection ? maybe a BW or latency case ? > > > in the case the node doesn’t want to use two links to protect each other due > to the amount of BW available on each of these links and that can’t absorb > the other link traffic. > > [SLI] Fine > >> §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 ? > > > ok for me. > > >> §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. > > > agreed. > > I’ll submit the new version with your comments asap. > > Thanks. > s. > > >> >> >> 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-cas >>> e >>> 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-ca >>> s >>> 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. >> > > > _________________________________________________________________________________________________________________________ > > 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
