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.vainsht...@ecitele.com> wrote:
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
> Email: alexander.vainsht...@ecitele.com
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Tuesday, May 16, 2017 11:28 AM
> *To:* 'Stefano Previdi (sprevidi)' <sprev...@cisco.com>
> *Cc:* draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org;
> Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky <
> michael.gorokhov...@ecitele.com>; Sidd Aanand <sidd.aan...@ecitele.com>;
> Ron Sdayoor <ron.sday...@ecitele.com>; Rotem Cohen <
> rotem.co...@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.vainsht...@ecitele.com
>
>
>
>
>
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:sprev...@cisco.com
> <sprev...@cisco.com>]
> Sent: Monday, May 15, 2017 11:12 AM
> To: Alexander Vainshtein <alexander.vainsht...@ecitele.com>
> Cc: draft-ietf-spring-resliency-use-ca...@ietf.org; spring@ietf.org;
> Shell Nakash <shell.nak...@ecitele.com>; Michael Gorokhovsky <
> michael.gorokhov...@ecitele.com>; Sidd Aanand <sidd.aan...@ecitele.com>;
> Ron Sdayoor <ron.sday...@ecitele.com>; Rotem Cohen <
> rotem.co...@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.vainsht...@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.vainsht...@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
>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
