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 

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,


-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] 
Sent: Monday, September 19, 2016 19:44
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. 


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

Reply via email to