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

[Muthu Arul Mozhi Perumal <[e-mail]>]

Sasha,

On Tue, May 16, 2017 at 4:11 PM, Alexander Vainshtein <
[e-mail]> wrote:

> Muthu,
>
> Again lots of thanks for a prompt response. I still do not think a loop
> would really form because:
>
> ·         A sends packet to its local next hop for B with the stack (B,
> C, D)
>
> ·         B receives this packet with the stack (C, D), but the link C
> has failed. So B sends to its next hop for it back to A *with stack (C,D)*
>
> ·         A now sends the packet to its next hop for C with the same
> stack.
>
​Right, it doesn't cause an infinite loop, but does result in packets being
forwarded from A -> B -> A, over a sub-optimal path, possibly overloading
the A-B link and increasing the load at A, when there are better alternate
paths in the network (including the shortest path from A to D). Moreover,
having enabled e2e path protection at A, the operator might actually want
the traffic to be switched over an alternate disjoint TE path when the
primary TE path is broken -- enabling local protection might act against
that goal, with traffic forwarded over sub-optimal paths.

Regards,
Muthu  ​


>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
> *From:* Muthu Arul Mozhi Perumal [mailto:[e-mail]]
> *Sent:* Tuesday, May 16, 2017 1:25 PM
>
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* Stefano Previdi (sprevidi) <[e-mail]>; [e-mail];
> Shell Nakash <[e-mail]>; Michael Gorokhovsky <
> [e-mail]>; draft-ietf-spring-resiliency-
> [e-mail]; Sidd Aanand <[e-mail]>; Ron Sdayoor <
> [e-mail]>; Rotem Cohen <[e-mail]>
> *Subject:* Re: [spring] A belated comment on end-to-end path protection
> in draft-ietf-spring-resiliency-use-cases
>
>
>
> On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein <
> [e-mail]> wrote:
>
> Muthu,
>
> Lots of thanks for a prompt response.
>
>
>
> I do not think that the loop you have described would actually appear in
> the scenario you’ve described.
>
>
>
> To the best of my understanding of TI-LFA, B would send the traffic back
> to A *complete with an explicit route that says B**à** A**à** C**à**D*,
> and no loop would be formed.
>
>
>
> Not necessarily. B was asked to send the traffic to C and knows that if it
> sends the traffic to A, then A will send it to C over the shortest path
> (i.e from B's perspective only the labeled next-hop changes).
> Unfortunately, A has an explicit route pointing back to B (over the SR-TE
> tunnel T1) that B isn't aware of. If B does strict explicit route for
> everything, then B can run out of its MSD..
>
>
>
> ​
>
>
>
> Similar “loops” can happen also in MPLS FRR with RSVP-TE when the PLR
> sends some traffic back  - but it sends it with the suitable label stack of
> the bypass tunnel so that eventually it reaches the MP.
>
>
>
> ​Are there existing deployments where both e2e path protection and local
> protection are used together with RSVP-TE?
>
>
>
> Regards,
>
> Muthu
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
> *From:* Muthu Arul Mozhi Perumal [mailto:[e-mail]]
> *Sent:* Tuesday, May 16, 2017 12:34 PM
> *To:* Alexander Vainshtein <[e-mail]>
> *Cc:* Stefano Previdi (sprevidi) <[e-mail]>; [e-mail];
> Shell Nakash <[e-mail]>; Michael Gorokhovsky <
> [e-mail]>; draft-ietf-spring-resiliency-
> [e-mail]; Sidd Aanand <[e-mail]>; Ron Sdayoor <
> [e-mail]>; Rotem Cohen <[e-mail]>
>
>
> *Subject:* 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 <
> [e-mail]> wrote:
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
> *From:* Alexander Vainshtein
> *Sent:* Tuesday, May 16, 2017 11:28 AM
> *To:* 'Stefano Previdi (sprevidi)' <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> Shell Nakash <[e-mail]>; Michael Gorokhovsky <
> [e-mail]>; Sidd Aanand <[e-mail]>;
> Ron Sdayoor <[e-mail]>; Rotem Cohen <
> [e-mail]>
> *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: [phone] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> Email:   [e-mail]
>
>
>
>
>
> -----Original Message-----
> From: Stefano Previdi (sprevidi) [mailto:[e-mail]
> <[e-mail]>]
> Sent: Monday, May 15, 2017 11:12 AM
> To: Alexander Vainshtein <[e-mail]>
> Cc: [e-mail]; [e-mail];
> Shell Nakash <[e-mail]>; Michael Gorokhovsky <
> [e-mail]>; Sidd Aanand <[e-mail]>;
> Ron Sdayoor <[e-mail]>; Rotem Cohen <
> [e-mail]>
> 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 <
> [e-mail]> 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: [phone] <+972%203-926-6302>
>
> > Cell:      [phone] <+972%2054-926-6302>
>
> > Email:   [e-mail]
>
> >
>
> >
>
> > ______________________________________________________________________
>
> > _____
>
> >
>
> > 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
>
> > [e-mail]
>
> > 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
> [e-mail]
> 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.
> ____________________________________________________________
> _______________
>
>
>
> ____________________________________________________________
> _______________
>
> 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.
> ____________________________________________________________
> _______________
>