Subject: Re: [spring] Issue with path protection for SR-TE LSPs

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 4 Oct 2016 09:36:59 +0000

Stephane, Sasha, All,

just to be sure w’ere in sync.

It is obvious to me that it won’t make much sense to have a requirements stating that disjointness must be guaranteed in all cases and even when “any” failure occurs. 

In real networks, multiple (correlated or not) events may happen simultaneously and despite the theoretical possibility to always find disjointness, in practice the requirements is different.

Disjointness is computed on a specific topology and for a specific service (i.e.: no resource sharing between paths).

What’s important is that the spring architecture must be capable of ensuring disjointness in a given topology, monitor it and, in case of any network event, validate it (or re-validate it).

If something has changed in the network that brakes the disjointness, then the pdisjoint paths must be recomputed.

Thanks.
s.

> On Sep 30, 2016, at 2:21 PM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
> 
> Sasha, Stephane,
> 
> 
>> On Sep 30, 2016, at 1:29 PM, [email-masked] wrote:
>> 
>> Hi,
>> 
>> Expressed this way I agree that this is an interesting additional requirement for the draft.
> 
> 
> I agree. I’ll update the draft.
> 
> s.
> 
> 
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -----Original Message-----
>> From: Alexander Vainshtein [mailto:[email-masked]] 
>> Sent: Tuesday, September 27, 2016 14:41
>> To: LITKOWSKI Stephane OBS/OINIS
>> Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; [email-masked]; Marina Fizgeer; Rotem Cohen; DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
>> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Stephane,
>> Lots of thanks for an important clarification.
>> 
>> But don’t you think that in addition to your statement "SPRING architecture MUST provide a way to compute paths that MUST NOT be protected by local repair techniques" the draft should also say that " SPRING architecture MUST provide a way to instantiate pairs of paths that will would remain disjoint in spite of any topology changes in the network"?
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:      +972-549266302
>> Email:   [email-masked]
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> Sent: Tuesday, September 27, 2016 2:41 PM
>> To: Alexander Vainshtein <[email-masked]>; DECRAENE Bruno IMT/OLN <[email-masked]>; Stefano Previdi (sprevidi) <[email-masked]>
>> Cc: [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Marina Fizgeer <[email-masked]>; Rotem Cohen <[email-masked]>
>> Subject: RE: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Hi,
>> 
>> As Stefano mentioned, as it's a use case and requirement draft, we do not have to talk about solutions, and about issues in using one or other mechanism.
>> Such considerations about using or not some particular SIDs to fill the "path must not be protected by any local repair" constraint are up to a solution draft and not this document. Regarding this document, the requirement is clear : " SPRING architecture MUST provide a way to compute paths that MUST
>>     NOT be protected by local repair techniques", that's all we can expect from this document.
>> 
>> Best Regards,
>> 
>> Stephane
>> 
>> 
>> -----Original Message-----
>> From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
>> Sent: Tuesday, September 27, 2016 12:22
>> To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
>> Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; [email-masked]; Marina Fizgeer; Rotem Cohen
>> Subject: Re: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Stefano, Bruno and all,
>> Lots of thanks for detailed responses that, frankly, now go much deeper than my original question.
>> 
>> My concern was about combining "regular" prefix SIDs advertised with the default algorithm and path protection for SR LSPs.
>> To the best of my understanding, within his, admittedly limited, scope:
>> - there is no way to guarantee that Main and Protection paths will remain disjoint following some topology changes in the network
>> - if some local protection for these SIDs is enabled in the network, there is no way to guarantee that it will not affect some segments of such LSPs.
>> 
>> To the best of my understanding, Stefano's answers says that you can use some "special" prefix-SIDs (e.g., marking them as not protecting, advertising tem with some non-default algorithm etc.). I have no problem with these answers - but from my POV they are out of the narrow scope of my original questions. 
>> I do not think that this draft should list any specific solutions. But maybe it should say that "the default prefix-SIDs" (i.e. prefix-SIDs advertised with the default algorithm etc.) should not be used in specification of SR-LSPs employing the path protection scheme?
>> 
>> Regards,
>> Sasha
>> 
>> Office: +972-39266302
>> Cell:      +972-549266302
>> Email:   [email-masked]
>> 
>> -----Original Message-----
>> From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
>> Sent: Tuesday, September 27, 2016 12:08 PM
>> To: Stefano Previdi (sprevidi) <[email-masked]>
>> Cc: [email-masked]; Alexander Vainshtein <[email-masked]>; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Marina Fizgeer <[email-masked]>; Rotem Cohen <[email-masked]>
>> Subject: Re: [spring] Issue with path protection for SR-TE LSPs
>> 
>> Hi Stefano,
>> 
>>> From: Stefano Previdi (sprevidi) [mailto:[email-masked]]  > Sent: 
>>> Tuesday, September 27, 2016 10:53 AM
>>> 
>>>> On Sep 27, 2016, at 9:50 AM, [email-masked] wrote:
>>>> 
>>>> Hi Stefano,
>>>> 
>>>> As an individual contributor, please find a comment inline  > >  > >> From: Stefano Previdi (sprevidi) [mailto:[email-masked]]  > Sent: Monday,  > September 26, 2016 11:22 AM  > >>  > >> <see below>  > >>  > >>  > >>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi) <[email-masked]> wrote:
>>>>>> 
>>>>>> Hi Sasha,
>>>>>> 
>>>>>> sorry for being late. See below.
>>>>>> 
>>>>>> 
>>>>>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein  > >> <[email-masked]> wrote:
>>>>>>> 
>>>>>>> Hi all,
>>>>>>> I have read the SR Resiliency Use Cases draft and I have an issue with the path  > >> protection use case.
>>>>>>> 
>>>>>>> The draft defines this use case with the following constrains/qualifiers (quoting  > from  > >> Section 2):
>>>>>>> ·         The operator configures two SPRING paths T1 and T2 from A to Z
>>>>>>> ·         Initially, the customer traffic (e.g., PW traffic) is sent from A to Z via T1. When
>>>>> T1 fails, the traffic is sent via T2.
>>>>>>> ·         The two paths are made disjoint using the SPRING architecture
>>>>>>> ·         The two configured paths T1 and T2 MUST NOT benefit from local protection
>>>>>>> 
>>>>>>> The draft does not go into any detail regarding the type of segments that the  > operator  > >> uses when specifying T1 and T2, and the example given in the draft can be interpreted  > in  > >> two ways:
>>>>>>> ·         T1 and T2 are specified using only adjacency SID
>>>>>>> ·         T1 and T2 are specified using node SIDs (or a mix of node SIDs and adjacency
>>>>> SIDs).
>>>>>> 
>>>>>> 
>>>>>> this is intentional.
>>>>>> 
>>>>>> It’s a use case draft where we describe the various protection requirements and  > >> strategies for protection.
>>>>>> 
>>>>>> It has never been intended to describe a specific solution.
>>>>>> 
>>>>>> 
>>>>>>> If T1 and T2 are specified using node SIDs, there is no guarantee that these paths,  > even  > >> if initially disjoint, will remain disjoint when the underlying network topology changes.
>>>>>> 
>>>>>> 
>>>>>> It all depends on various factors among which the topology and how these paths have  > >> been computed (i.e.: for which failure: link/node/srlg). IOW, you _can_ compute  > disjoint  > >> paths taking into account a given srlg failure.
>>>>>> 
>>>>>> For sure, a path expressed through an exhaustive (list of adj-sid will give you the best  > >> guarantee on the path the packet will take in all cases but it is not the point of the  > draft.
>>>>>> 
>>>>>> 
>>>>>>> Further, if TI FRR is enabled in the network for protection of non-TE SR LSPs, the  > >> fragments of T1 and T2 that are specified using node SIDs will not be excluded from  > local  > >> protection.
>>>>> 
>>>>> 
>>>>> sorry, I realized something is missing in my answer.
>>>>> 
>>>>> In fact, even using node-sids and even for non TE SR traffic, you can still ensure the  > path  > >> you computed uses non protected sid’s.
>>>>> 
>>>>> Think about the use of strict-spf sid’s where the rule is clear: just fowllow spt and do  > not  > >> diverge from it.
>>>> 
>>>> IMO, it would be useful to indicate in draft-ietf-spring-segment-routing that strict-spf  > SID MUST NOT be protected by a local protection (aka Fast ReRoute).
>>>> It may be obvious to you, but it was not for me. In particular in the case of TI-LFA where  > the protection _do_ follow the SPF (indeed in the new topology, but just like strict-spf  > after the IGP convergence)  >  >  > Well, I’m not recommending this. I just took an example on how you could enforce a  > specific forwarding rule through a given segment identifier. There are multiple choices for  > that:
>>> 	. add a flag to prefix-sid (i.e.: do not protect)
>>> 	. define new “unprotected” SIDs
>>> 	. define new algorithm
>>> 	. use strict-spf algorithm
>>> 	. probably more...
>>> 
>>> Here, in the context of this draft, I don’t think we have to list the possible solutions, right ?
>> 
>> Agreed.
>> 
>> 
>>> My answer was given to Sasha when he claimed that there are now ways to prevent  > protection for a given traffic. That statement was wrong (IMO) and I illustrated one way  > to achieve it.
>> 
>> You said to use strict-spf since it is not protected by FRR.
>> For this rule to be enforced, it needs to be clear in the definition of the strict-spf algo.
>> IMO, this rule, as currently written in draft-ietf-spring-segment-routing, is not clear enough. Hence could you please clarify it, in draft-ietf-spring-segment-routing,  to specify whether or not SID using the "Strict Shortest Path" may be protected by FRR or not?
>> 
>> Thanks
>> --Bruno
>> 
>>> Thanks.
>>> s.
>>> 
>>> 
>>>> 
>>>> Thanks
>>>> --Bruno
>>>> 
>>>> 
>>>>> s.
>>>>> 
>>>>> 
>>>>>>> So it seems that path protection for SR LSPs as specified in the draft is only  > applicable  > >> to paths that are specified using only adjacency SIDs.
>>>>> 
>>>>>> I don’t disagree while I believe it mostly depends on the topology.
>>>>>> 
>>>>>> More important is the fact that the document should not focus on one specific way of  > >> computing protection paths.
>>>>>> 
>>>>>> s.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Did I miss something substantial?
>>>>>>> 
>>>>>>> Regards, and lots fo thanks in advance,  > >>>> Sasha  > >>>>  > >>>> Office: +972-39266302
>>>>>>> Cell:      +972-549266302
>>>>>>> Email:   [email-masked]
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> spring mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/spring
>>>>>> 
>>>> 
>>>> 
>>>> 
>>> _________________________________________________________________________
>>> ________________________________________________
>>>> 
>>>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>> _______________________________________________
>> spring mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spring
>> 
>> _________________________________________________________________________________________________________________________
>> 
>> 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.
>> 
>

---

From: <[email-masked]>
Date: Tue, 4 Oct 2016 13:29:08 +0000

We are in sync.

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Tuesday, October 04, 2016 11:37
To: LITKOWSKI Stephane OBS/OINIS; Alexander Vainshtein
Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; [email-masked]; Marina Fizgeer; Rotem Cohen; DECRAENE Bruno IMT/OLN
Subject: Re: [spring] Issue with path protection for SR-TE LSPs

Stephane, Sasha, All,

Thanks.
s.

>> Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; 
>> [email-masked]; Marina Fizgeer; 
>> Rotem Cohen; DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
>> To: Alexander Vainshtein <[email-masked]>; DECRAENE 
>> Bruno IMT/OLN <[email-masked]>; Stefano Previdi (sprevidi) 
>> <[email-masked]>
>> Cc: [email-masked]; Shell Nakash <[email-masked]>; Michael 
>> Gorokhovsky <[email-masked]>; 
>> [email-masked]; Marina Fizgeer 
>> <[email-masked]>; Rotem Cohen <[email-masked]>
>> Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; 
>> [email-masked]; Marina Fizgeer; 
>> Rotem Cohen
>> - there is no way to guarantee that Main and Protection paths will 
>> remain disjoint following some topology changes in the network
>> Cc: [email-masked]; Alexander Vainshtein 
>> <[email-masked]>; Shell Nakash 
>> <[email-masked]>; Michael Gorokhovsky 
>> <[email-masked]>; 
>> [email-masked]; Marina Fizgeer 
>> <[email-masked]>; Rotem Cohen <[email-masked]>
>>> ____________________________________________________________________
>>> _____ ________________________________________________
>>>> 
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> _____________________________________________________________________
>> ____________________________________________________
>> 
>> 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.