> On Sep 27, 2016, at 9:50 AM, [email protected] wrote:
>
> Hi Stefano,
>
> As an individual contributor, please find a comment inline
>
>> From: Stefano Previdi (sprevidi) [mailto:[email protected]] > Sent:
>> Monday, September 26, 2016 11:22 AM
>>
>> <see below>
>>
>>
>>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi)
>>> <[email protected]> wrote:
>>>
>>> Hi Sasha,
>>>
>>> sorry for being late. See below.
>>>
>>>
>>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein
>> <[email protected]> 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 ?
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.
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 protected]
>>>>
>>>> _______________________________________________
>>>> spring mailing list
>>>> [email protected]
>>>> 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.
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
