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:spring-boun...@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Tuesday, September 27, 2016 12:22
To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi)
Cc: spring@ietf.org; Shell Nakash; Michael Gorokhovsky;
draft-ietf-spring-resiliency-use-ca...@ietf.org; 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: alexander.vainsht...@ecitele.com
-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of
bruno.decra...@orange.com
Sent: Tuesday, September 27, 2016 12:08 PM
To: Stefano Previdi (sprevidi) <sprev...@cisco.com>
Cc: spring@ietf.org; Alexander Vainshtein <alexander.vainsht...@ecitele.com>;
Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky
<michael.gorokhov...@ecitele.com>;
draft-ietf-spring-resiliency-use-ca...@ietf.org; Marina Fizgeer
<marina.fizg...@ecitele.com>; Rotem Cohen <rotem.co...@ecitele.com>
Subject: Re: [spring] Issue with path protection for SR-TE LSPs
Hi Stefano,
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent:
> Tuesday, September 27, 2016 10:53 AM
>
> > On Sep 27, 2016, at 9:50 AM, bruno.decra...@orange.com wrote:
> >
> > Hi Stefano,
> >
> > As an individual contributor, please find a comment inline > > > >>
> > From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com] > Sent:
> > Monday, > September 26, 2016 11:22 AM > >> > >> <see below> > >> > >>
> > > >>> On Sep 26, 2016, at 11:14 AM, Stefano Previdi (sprevidi)
> > <sprev...@cisco.com> wrote:
> >>>
> >>> Hi Sasha,
> >>>
> >>> sorry for being late. See below.
> >>>
> >>>
> >>>> On Jul 10, 2016, at 11:07 AM, Alexander Vainshtein > >>
> >>>> <alexander.vainsht...@ecitele.com> 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: alexander.vainsht...@ecitele.com
> >>>>
> >>>> _______________________________________________
> >>>> spring mailing list
> >>>> spring@ietf.org
> >>>> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
