Subject: [spring] I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt

From: [email-masked]
Date: Mon, 19 Sep 2016 10:39:53 -0700

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

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 19 Sep 2016 17:43:34 +0000

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, [email-masked] wrote:
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: <[email-masked]>
Date: Tue, 20 Sep 2016 12:07:25 +0000

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:[email-masked]] 
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,

Thanks.
s.

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

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Thu, 22 Sep 2016 16:18:11 +0000

Hi Stephane,

> On Sep 20, 2016, at 2:07 PM, [email-masked] wrote:
> 
> Hi Stefano,
> 

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

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

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

ok for me.

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

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 10:10:19 +0000

Hi Stefano

Answers inline

Best Regards,

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
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,

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

something like:

[SLI] Yes, you need to add also that the path will need to merge asap of the primary path (bypass case).

[SLI] Right

[SLI] Fine

ok for me.

agreed.

Thanks.
s.

>> https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cas
>> e
>> s/
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-resiliency-use-ca
>> s
>> es-05
>> 
>> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Fri, 23 Sep 2016 12:35:05 +0000

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, [email-masked] wrote:
> 
> Hi Stefano
> 
> Answers inline
> 
> Best Regards,
> 
>

---

From: <[email-masked]>
Date: Fri, 23 Sep 2016 13:13:14 +0000

Hi Stefano,

Thanks for the updates, it's fine for me . I just noted that you finally kept the name "Shortest path based protection".
If that's your preference I'm fine.

I will complete the shepherd review in the next couple of days.

Best Regards and thanks again,

Stephane

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Friday, September 23, 2016 14:35
To: LITKOWSKI Stephane OBS/OINIS
Cc: SPRING WG
Subject: Re: I-D Action: draft-ietf-spring-resiliency-use-cases-05.txt

Hi Stephane,

Thanks.
s.

>> Subject: Re: I-D Action: 
>> draft-ietf-spring-resiliency-use-cases-05.txt
>> 
>> Hi Stephane,
>> 
>> _____________________________________________________________________
>> _ ___________________________________________________
>>