Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Using end-to-end path protection together with local protection can result
in traffic loops. Consider the foll. topology:

B-----C
|    / \
|   /   \
|  /     \
| /       \D----+
A/              Z (CE)
 \         F----+
  \       /
   \     /
    \   /
     \E/

- All links are of equal cost.
- A, D and F are BGP peers.
- Z is a dual-homed CE.

A resolves its BGP next-hop D over the SR-TE tunnel T1.
T1: A->B, B->C, C->D (loosely routed)

Suppose A has enabled end-to-end path protection over tunnel T1 and B has
TI-LFA enabled, and the detection timers are configured as described in
your previous email. If the BC link goes down, B will immediately start
rerouting the traffic via A (in FRR fashion) creating a loop b/w A and B.

A solution would be to make the A-B link ineligible for TI-LFA backup
computation at B. However, managing this network-wide could become
operational expensive. Hence, deploying one of end-to-end path protection
or local protection with sufficiently short detection timers keeps things
simple, IMHO.

Regards,
Muthu

On Tue, May 16, 2017 at 1:59 PM, Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Tuesday, May 16, 2017 11:28 AM
> *To:* 'Stefano Previdi (sprevidi)' <sprevidi@cisco.com>
> *Cc:* draft-ietf-spring-resliency-use-cases@ietf.org; spring@ietf.org;
> Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <
> Michael.Gorokhovsky@ecitele.com>; Sidd Aanand <Sidd.Aanand@ecitele.com>;
> Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Rotem Cohen <
> Rotem.Cohen@ecitele.com>
> *Subject:* RE: [spring] A belated comment on end-to-end path protection
> in draft-ietf-spring-resiliency-use-cases
>
>
>
> Stefano,
>
> Lots of thanks for a prompt response.
>
>
>
> A couple of short comments if you do not mind:
>
>
>
> *Using 2119 language in a "use cases" document*:
>
> 1.       Going back to the source I see that “MUST NOT… mean that the
> definition is an absolute prohibition of the specification”
>
> 2.       I agree that the use case document defines which scenarios
> should be addressed, but I do not see how it can impose an absolute
> prohibition on a certain scenario.
>
>
>
> *Little sense link protection has in the case of path protection*:
>
> 1.       This was definitely correct for traditional traffic engineering
> because the “shortest traffic paths” (e.g., LDL PSPs) could be easily
> differentiated from the “engineered traffic paths”.
>
> 2.       In addition, traditional local protection (e.g., MPLS FRR using
> RSVP-TE) could deal with link and node failures regardless of whether the
> failed link or node appeared in the ERO of the protected path.
>
> 3.       IMHO and FWIW, with SR  the situation is quite different:
>
> o   The shortest traffic paths not only coexist with engineered traffic
> paths: the latter are in many cases “tunneled” within the former.
>
> o   Path protection cannot be applied to shortest traffic paths so they
> must rely on local protection
>
> o   Local protection in the case of failure of a node or link that
> appears in the ERO of an engineered SR path is highly non-trivial at best,
> so path protection for the engineered LSPs looks like a preferred solution
> to me.
>
> I fully agree with you that the operators deploying SR should provide
> feedback on this point based on actual operational experience.
>
> Meanwhile I doubt that *a priori* declaring some use cases as absolutely
> prohibited is the right thing to do.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
>
>
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com
> <sprevidi@cisco.com>]
> Sent: Monday, May 15, 2017 11:12 AM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
> Cc: draft-ietf-spring-resliency-use-cases@ietf.org; spring@ietf.org;
> Shell Nakash <Shell.Nakash@ecitele.com>; Michael Gorokhovsky <
> Michael.Gorokhovsky@ecitele.com>; Sidd Aanand <Sidd.Aanand@ecitele.com>;
> Ron Sdayoor <Ron.Sdayoor@ecitele.com>; Rotem Cohen <
> Rotem.Cohen@ecitele.com>
> Subject: Re: [spring] A belated comment on end-to-end path protection in
> draft-ietf-spring-resiliency-use-cases
>
>
>
>
>
> > On May 11, 2017, at 12:04 PM, Alexander Vainshtein <
> Alexander.Vainshtein@ecitele.com> wrote:
>
> >
>
> > Hi all,
>
> > I have a belated (but hopefully late is still better than never) comment
> on path protection as defined in Section 2 of the draft.
>
> >
>
> > This second para in this section says:
>
> >    A first protection strategy consists in excluding any local repair
>
> >
>
> >    but instead use end-to-end path protection where each SPRING path
>
> > is
>
> >
>
> >    protected by a second disjoint SPRING path.  In this case local
>
> >
>
> >    protection MUST NOT be used.
>
> >
>
> > First of all, I do not think that RFC 2119 language should be used in
> Informational documents, especially in the documents that describe use
> cases.
>
>
>
>
>
> this document is also a requirements document for the resiliency use-case.
> RFC2119 terminology is perfectly usable and even more, it adds clarity on
> what the solution is expected to provide.
>
>
>
>
>
> > In addition, I specifically disagree with the quoted statement above,
> because, from my POV:
>
> > ·         Local repair and end-to-end path protection can be combined
> for the same path
>
> > ·         Such a combination may be beneficial for the operators.
>
>
>
>
>
> are you talking by experience or is it just something that came into your
> mind ? I’d like to hear from operators using a combination of path and link
> protection.
>
>
>
> This document has been deeply reviewed also by operators and it has been
> always obvious the little sense link protection has in case of path
> protection.
>
>
>
>
>
> > One possible way to combine the two is described below:
>
> >
>
> > 1.       A pair of SR paths is set up between the given two nodes –
> later referred to as source and destination -  in the network. These paths
> are “SR-disjoint” in the sense that their “explicit routes”  do not have
> any common elements, be they nodes or adjacencies, with exclusion of the
> final destination
>
> > 2.       Local repair for these paths is enabled in the network. It is
> triggered by locally observed events (link failures etc.), applied by the
> nodes adjacent to the failure and guarantees that, in the case of a link or
> node failure that is not specified in the explicit route, traffic along the
> affected path would be restored within <X> milliseconds
>
> > 3.       End-to-end liveness monitoring is enabled for the two SR paths,
> and detects end-to-end failures of these paths within <Y> milliseconds
> where Y >> X. In other words, end-to-end liveness monitoring for these
> paths will ignore any failures that local repair can fix, but will detect
> failures that cannot be locally repaired (e.g., failures of nodes or links
> that have been specified in the explicit route of one of the paths
>
> > 4.       End-to-end liveness monitoring triggers end-to-end path
> protection to be applied by the source node in the following way:
>
> > a.       If it recognizes both paths as alive, one of them will carry
> the customer traffic, while the other one will be idle. The rules for
> selecting the active path in this scenario may vary
>
> > b.      If end-to-end failure of one of these paths is detected while
> the other one remains alive, traffic will be carried across the live path
>
> > c.       If end-to-end failure of both paths is detected (e.g., if the
> final destination node fails, or if the network is partitioned), this is
> recognized as an unrecoverable failure.
>
> >
>
> > From my POV the combination of local repair and end-to-end protection
> for SR paths is one of a few possibilities to protect such paths against
> failures of nodes and/or links that have been specified in their explicit
> routes. (Another option has been described in Node Protection for SR-TE
> Paths, but this draft has expired).
>
> >
>
> > Do I miss something substantial?
>
>
>
>
>
> to my view you created a use-case that doesn’t bring much to the picture
> but I’d let operators to comment.
>
>
>
> s.
>
>
>
>
>
> >
>
> > Regards,
>
> > Sasha
>
> >
>
> > Office: +972-39266302 <+972%203-926-6302>
>
> > Cell:      +972-549266302 <+972%2054-926-6302>
>
> > Email:   Alexander.Vainshtein@ecitele.com
>
> >
>
> >
>
> > ______________________________________________________________________
>
> > _____
>
> >
>
> > This e-mail message is intended for the recipient only and contains
>
> > information which is CONFIDENTIAL and which may be proprietary to ECI
>
> > Telecom. If you have received this transmission in error, please
>
> > inform us by e-mail, phone or fax, and then delete the original and all
> copies thereof.
>
> > ______________________________________________________________________
>
> > _____ _______________________________________________
>
> > spring mailing list
>
> > spring@ietf.org
>
> > https://www.ietf.org/mailman/listinfo/spring
>
>
>
> ____________________________________________________________
> _______________
>
> This e-mail message is intended for the recipient only and contains
> information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
> received this
> transmission in error, please inform us by e-mail, phone or fax, and then
> delete the original
> and all copies thereof.
> ____________________________________________________________
> _______________
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>