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...
> §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.
> §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.
> 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.
> §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-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
