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

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 11 May 2017 10:04:01 +0000

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<https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/?include_text=1>.

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.

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.

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<https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-00>, but this draft has expired).

Do I miss something substantial?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

___________________________________________________________________________

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.
___________________________________________________________________________

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Mon, 15 May 2017 08:11:50 +0000

> On May 11, 2017, at 12:04 PM, Alexander Vainshtein <[email-masked]> 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 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.

> ·         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.

> 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
> 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).
>  

to my view you created a use-case that doesn’t bring much to the picture but I’d let operators to comment.

s.

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 08:27:37 +0000

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

Cell:      +972-549266302

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

>    but instead use end-to-end path protection where each SPRING path

> is

s.

> Email:   [email-masked]<mailto:[email-masked]>

> ______________________________________________________________________

> _____

> 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.

> ______________________________________________________________________

> _____ _______________________________________________

> [email-masked]<mailto:[email-masked]>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 08:29:11 +0000

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Tuesday, May 16, 2017 11:28 AM
To: 'Stefano Previdi (sprevidi)' <[email-masked]>
Cc: [email-masked]; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: RE: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Stefano,

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 May 2017 10:53:19 +0200

Hi Sasha,

You said:

 "Path protection cannot be applied to shortest traffic paths so they must
rely on local protection"

What makes you think that way ?

Only one specific use case of SR is TE. And could even argue that it is not
the most important one.

Adding protection to shortest traffic paths with TILFA is a very valid use
case for SR.

Another one is use of SR for VPNs. End to end path will still be shortest
from IGP pov yet SR header will be present.

Cheers
R.

On May 16, 2017 4:31 AM, "Alexander Vainshtein" <
[email-masked]> wrote:

> *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.
>
> o   The shortest traffic paths not only coexist with engineered traffic
> paths: the latter are in many cases “tunneled” within the former.
>
> 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>
>
> Cc: [email-masked]; [email-masked];
> Shell Nakash <[email-masked]>; Michael Gorokhovsky <
> [email-masked]>; Sidd Aanand <[email-masked]>;
> Ron Sdayoor <[email-masked]>; Rotem Cohen <
> [email-masked]>
> > I have a belated (but hopefully late is still better than never) comment
> on path protection as defined in Section 2 of the draft.
>
> >
>
> > 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.
>
>
>
>
>
> 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.
>
>
>
>
>
> > 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).
>
> >
>
> > Office: +972-39266302 <+972%203-926-6302>
>
> > Cell:      +972-549266302 <+972%2054-926-6302>
>
> information which is

---

From: <[email-masked]>
Date: Tue, 16 May 2017 09:29:23 +0000

Hi,

I think there is a misunderstanding on what the text 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.
“

The text presents a design option which is to use end-to-end path protection and prevent any local-repair. In this option (the text mention: “In this case”), for sure, we need to prohibit local protection as this is the requirement of this design option.

Now if you want to combine end-to-end protection + local protection, that’s up to you and that’s another design option. IMO, I would not push for this combined design as it brings more complexity rather than solving problems, but it’s a personal design opinion.

Brgds,

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Tuesday, May 16, 2017 10:29
To: Stefano Previdi (sprevidi)
Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; [email-masked]; Sidd Aanand; Ron Sdayoor; Rotem Cohen
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

To: 'Stefano Previdi (sprevidi)' <[email-masked]<mailto:[email-masked]>>

Stefano,

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

_________________________________________________________________________________________________________________________

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.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 16 May 2017 15:04:24 +0530

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 <
[email-masked]> wrote:

> *From:* Alexander Vainshtein
> *Sent:* Tuesday, May 16, 2017 11:28 AM
> *To:* 'Stefano Previdi (sprevidi)' <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> *Subject:* RE: [spring] A belated comment on end-to-end path protection
> in draft-ietf-spring-resiliency-use-cases
>
>
>
> Stefano,
>
> From: Stefano Previdi (sprevidi) [mailto:[email-masked]
> <[email-masked]>]

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 09:44:08 +0000

Stephane,
Lots of thanks for a prompt response and an interesting clarification.
My understanding of this clarification is that the text in question describes the following scenario:

1.       “Shortest SR paths” exist (to the best of my understanding they always exist in SR) but do not require fast protection (e.g., because they do not carry any traffic that requires fast protection)

2.       All traffic that requires fast protection is carried using “engineered SR paths”

3.       End-to-end path protection is sufficient to protect these paths (e.g., it is fast enough)

4.       In this situation you may safely disable all local protection mechanisms.

If this the understanding above is correct, I do not have any issues with it. However, it does not explain “MUST NOT” in the quoted text: even if local protection were enabled, it would not prevent end-to-end path protection from operating normally.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 12:29 PM
To: Alexander Vainshtein <[email-masked]>; Stefano Previdi (sprevidi) <[email-masked]>
Cc: [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: RE: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Hi,

Brgds,

Cc: [email-masked]<mailto:[email-masked]>; Shell Nakash; Michael Gorokhovsky; [email-masked]<mailto:[email-masked]>; Sidd Aanand; Ron Sdayoor; Rotem Cohen

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Stefano,

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 09:57:35 +0000

Muthu,

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.

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.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 12:34 PM
To: Alexander Vainshtein <[email-masked]>
Cc: Stefano Previdi (sprevidi) <[email-masked]>; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
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/

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 <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
Email:   [email-masked]<mailto:[email-masked]>

Stefano,

My 2c,

Sasha

Office: +972-39266302<tel:+972%203-926-6302>

Cell:      +972-549266302<tel:+972%2054-926-6302>

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

> Office: +972-39266302<tel:+972%203-926-6302>

> Cell:      +972-549266302<tel:+972%2054-926-6302>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 16 May 2017 15:55:14 +0530

On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein <
[email-masked]> wrote:

> 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

> *From:* Muthu Arul Mozhi Perumal [mailto:[email-masked]]
> *Sent:* Tuesday, May 16, 2017 12:34 PM
> *To:* Alexander Vainshtein <[email-masked]>
> *Cc:* Stefano Previdi (sprevidi) <[email-masked]>; [email-masked];
> [email-masked]>; draft-ietf-spring-resiliency-
> [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <
> [email-masked]>; Rotem Cohen <[email-masked]>
>
> *Subject:* Re: [spring] A belated comment on end-to-end path protection

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 10:41:34 +0000

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.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Tuesday, May 16, 2017 1:25 PM

On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Muthu,
Lots of thanks for a prompt response.

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..

​

​Are there existing deployments where both e2e path protection and local protection are used together with RSVP-TE?

Regards,
Muthu

Regards,
Sasha

From: Muthu Arul Mozhi Perumal [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 16, 2017 12:34 PM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: Stefano Previdi (sprevidi) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>

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

Regards,
Muthu

Regards,
Sasha

Stefano,

My 2c,

Sasha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 10:59:09 +0000

Muthu,
An additional clarification:

·         If the link BC were OK, B could pop B from the stack and send packets to C with just D in the stack

·         When the link BC fails, B will leave the stack as (CD) IMHO – it would be  just trying to bypass the failed link BC.

·         If the failure of BC as perceived by B was cause by the failure of node B, such a failure could not be recovered by local protection. This is exactly the scenario where local protection for shortest SR path comprising an SR-TE path should be augmented by end-to-end path protection.

Regarding combination of local protection with end-to-end protection for RSVP-TE – AFAIK this was never used because it would not provide any added value.
In SR this is not so because local protection is usually faster (and scales better) than end-to-end protection, but, as opposed to RSVP-TE, there are failures that local protection cannot fix.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Alexander Vainshtein
Sent: Tuesday, May 16, 2017 1:42 PM
To: 'Muthu Arul Mozhi Perumal' <[email-masked]>
Cc: Stefano Previdi (sprevidi) <[email-masked]>; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: RE: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Muthu,

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

​

Regards,
Muthu

Regards,
Sasha

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

Regards,
Muthu

Regards,
Sasha

Stefano,

My 2c,

Sasha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Tue, 16 May 2017 14:01:12 +0000

Hi Stephane,

> On May 16, 2017, at 11:29 AM, [email-masked] wrote:
> 
> Hi,
>  

I agree.

> Now if you want to combine end-to-end protection + local protection, that’s up to you and that’s another design option. IMO, I would not push for this combined design as it brings more complexity r…

I agree.

I would add the precision that such option is NOT what the authors of the draft had in mind so I’d suggest to anyone promoting such option to come with some realistic operational requirements.

Thanks.
s.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 14:24:10 +0000

Stefano, 

I will borrow the quantum mechanics terminology that differentiates between pure and mixed (a.k.a. superposition) states of a quantum system.

As long as "mixed" use cases are not strictly prohibited in the draft (and this was at least one possible interpretation of the text), I do not have any issues with restricting it to just two "pure" use cases:
- End-to-end path protection with disabled local protection
- Local protection (of some kind) without end-to-end path protection.

This would leave the question about operational value and complexity of "superposition" use cases open for further discussion.

Does this correctly reflect your intentions?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Tuesday, May 16, 2017 5:01 PM
To: Stephane Litkowski <[email-masked]>
Cc: Alexander Vainshtein <[email-masked]>; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Hi Stephane,

I agree.

I agree.

Thanks.
s.

> Cc: [email-masked]; Shell Nakash; Michael Gorokhovsky; 
> [email-masked]; Sidd Aanand; Ron 
> Sdayoor; Rotem Cohen
> Subject: Re: [spring] A belated comment on end-to-end path protection 
> Shell Nakash <[email-masked]>; Michael Gorokhovsky 
> <[email-masked]>; Sidd Aanand 
> <[email-masked]>; Ron Sdayoor <[email-masked]>; 
> Rotem Cohen <[email-masked]>
> Subject: RE: [spring] A belated comment on end-to-end path protection 
> Shell Nakash <[email-masked]>; Michael Gorokhovsky 
> <[email-masked]>; Sidd Aanand 
> <[email-masked]>; Ron Sdayoor <[email-masked]>; 
> Rotem Cohen <[email-masked]>
> Subject: Re: [spring] A belated comment on end-to-end path protection 
> > information which is CONFIDENTIAL and which may be proprietary to 
> > ECI Telecom. If you have received this transmission in error, please 
> > ____________________________________________________________________
> > __ _____ _______________________________________________
> > spring mailing list
> > [email-masked]
> ___________________________________________________
> 
> 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.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 16 May 2017 20:42:46 +0530

Sasha,

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

> ·         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)*
>
​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  ​

> *Sent:* Tuesday, May 16, 2017 1:25 PM
>

---

From: Rob Shakir <[email-masked]>
Date: Tue, 16 May 2017 15:32:28 +0000

>
> As long as "mixed" use cases are not strictly prohibited in the draft (and
> this was at least one possible interpretation of the text), I do not have
> any issues with restricting it to just two "pure" use cases:

Use cases drafts should never attempt to be exhaustive in terms of what
they try and cover, but provide sufficient motivation for the features that
are/were required in the technology that is developed as a response to
them. In this case, the use case of path protection - especially with
disjointness requirements - provides motivation for wanting to have a SID
in the network that is explicitly not protected by local protection
mechanisms.

In RSVP-TE, we have the ability to set the "local protection requested" bit
described in RFC4090 - which gives the head-end the ability to control the
re-route behaviour of the LSP. This use case presents the operational case
for the B-flag in the IGP extensions.

Operators can, and will continue to, deploy things that (shockingly!) are
not described in IETF use case documents. At this point, if we consider
that this document provides some explanation of the features that are
required in the protocol - let's go ahead and publish it. Due to the
different technical and business requirements of different operators,
almost certainly, someone will deploy some combination of these features,
but I do not feel that we need to describe such unknown cases within this
document.

Kind regards,
r.

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 16 May 2017 21:41:18 +0530

Sasha,

On Tue, May 16, 2017 at 4:29 PM, Alexander Vainshtein <
[email-masked]> wrote:

> ·         When the link BC fails, B will leave the stack as (CD) IMHO – *it
> would be  just trying to bypass the failed link BC*.
>
> ·         If the failure of BC as perceived by B was cause by the failure
> of node B, such a failure could not be recovered by local protection. *This
> is exactly the scenario where local protection for shortest SR path
> comprising an SR-TE path should be augmented by end-to-end path protection*
> .
>
​If node B fails, the e2e path monitoring at  node A would anyway detect
the failure and switch the traffic over an alternate disjoint path...​

>
>
> Regarding combination of local protection with end-to-end protection for
> RSVP-TE – AFAIK this was never used because it would not provide any added
> value.
>
> In SR this is not so because local protection is usually faster (and
> scales better) than end-to-end protection, but, as opposed to RSVP-TE,
> there are failures that local protection cannot fix.
>

​Agree, there are failures in SR-TE that local protection cannot fix as
desired, so it calls for e2e path protection. However, enabling them
together is not always the best approach since it can introduce other
problems to solve.

Regards,
Muthu

> *Sent:* Tuesday, May 16, 2017 1:42 PM
> *To:* 'Muthu Arul Mozhi Perumal' <[email-masked]>
> [email-masked]>; draft-ietf-spring-resiliency-u
> [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <
> *From:* Muthu Arul Mozhi Perumal [mailto:[email-masked]
> <[email-masked]>]
> [email-masked]>; draft-ietf-spring-resiliency-u
> [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <
> [email-masked]>; draft-ietf-spring-resiliency-u
> [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 16:02:42 +0000

Rob,

Two comments:

1.       I fully agree with you that use cases drafts should not be exhaustive. But from my POV they should not be prohibitive (or be interpreted as prohibitive) either, exactly because “Operators can, and will continue to, deploy things that (shockingly!) are not described in IETF use case documents”.

2.       I have looped up the definition of B-flag in the IS-IS Extensions for SR<https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/?include_text=1> draft, and it looks confusing to me:

a.       This flag is used with Adj-SIDs and, if it is set, the corresponding adjacency is “eligible for protection (e.g.: using IPFRR or MPLS-FRR) as described in  [I-D.ietf-spring-resiliency-use-cases]”

b.      Unfortunately. the Resiliency Use Cases<https://tools.ietf.org/html/draft-ietf-spring-resiliency-use-cases-10> draft does not mention IPFRR, MPLS-FRR or the term “eligible” at all.  So the expected behavior associated with this flag (and, specifically, its relation with suppression of local protection) are not clear to me.
What did I miss?

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Rob Shakir [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 6:32 PM
To: Alexander Vainshtein <[email-masked]>; Stefano Previdi (sprevidi) <[email-masked]>
Cc: [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>; Stephane Litkowski <[email-masked]>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Use cases drafts should never attempt to be exhaustive in terms of what they try and cover, but provide sufficient motivation for the features that are/were required in the technology that is developed as a response to them. In this case, the use case of path protection - especially with disjointness requirements - provides motivation for wanting to have a SID in the network that is explicitly not protected by local protection mechanisms.

In RSVP-TE, we have the ability to set the "local protection requested" bit described in RFC4090 - which gives the head-end the ability to control the re-route behaviour of the LSP. This use case presents the operational case for the B-flag in the IGP extensions.

Operators can, and will continue to, deploy things that (shockingly!) are not described in IETF use case documents. At this point, if we consider that this document provides some explanation of the features that are required in the protocol - let's go ahead and publish it. Due to the different technical and business requirements of different operators, almost certainly, someone will deploy some combination of these features, but I do not feel that we need to describe such unknown cases within this document.

Kind regards,
r.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 16:16:16 +0000

Muthu,
Two points:

1.       There are no infinite loops in Layer 3 networks because they use TTL (or Hop Count) to break them. However, real loops (which do not exist in your scenario) result in blackholoing and hence must be avoided

2.       Local protection is typically employed in the short period between local detection of failure by the adjacent router and completion of global re-routing in response for this failure. As such, it may result in overload of some links and/or nodes and, AFAIK, this is considered as acceptable. In particular, this is what may happen with MPLS FRR based on RSVP-TE (RFC 4090) and with IP FRR using LFA (RFC 5286) or remote LFA (RFC 7490).

a.       Both technologies are well understood and widely deployed for some time already.

b.      IP FRR with local and remote LFA is also fully applicable to SR and are (implicitly) referred to in the resiliency use cases draft:

                                                               i.      Use of FRR with local LFA is described in Section 3 “Management-free local protection”

                                                             ii.      Use of FRR with remote LFA is described in Section 3.1 “Management-free bypass protection”.

The bottom line: It is possible to combine local protection and end-to-end path protection, and it will not result in blackholing due to loops. Whether it is worth the effort is a different story.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Tuesday, May 16, 2017 6:13 PM

Sasha,

On Tue, May 16, 2017 at 4:11 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> 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

​

Regards,
Muthu

Regards,
Sasha

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

Regards,
Muthu

Regards,
Sasha

Stefano,

My 2c,

Sasha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 16 May 2017 16:23:29 +0000

Muthu,
Again lots of thanks for a prompt response.

We seem to agree on the following points:

·         In SR some failures cannot be handled by local protection (actually, there is an expired draft that defines how this could be done, but it introduces serious complexity)

·         Combining local protection with end-to-end path protection is possible. In particular, such a combination speeds up handling of failures that that can be handled locally while also handling failures that could not be addressed by local protection.

Whether combining both forms of protection carries with it some new problems or not is a different story.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sent: Tuesday, May 16, 2017 7:11 PM

Sasha,

On Tue, May 16, 2017 at 4:29 PM, Alexander Vainshtein <[email-masked]<mailto:[email-masked]>> wrote:
Muthu,
An additional clarification:

•         If the link BC were OK, B could pop B from the stack and send packets to C with just D in the stack

•         When the link BC fails, B will leave the stack as (CD) IMHO – it would be  just trying to bypass the failed link BC.

•         If the failure of BC as perceived by B was cause by the failure of node B, such a failure could not be recovered by local protection. This is exactly the scenario where local protection for shortest SR path comprising an SR-TE path should be augmented by end-to-end path protection.
​If node B fails, the e2e path monitoring at  node A would anyway detect the failure and switch the traffic over an alternate disjoint path...​

​Agree, there are failures in SR-TE that local protection cannot fix as desired, so it calls for e2e path protection. However, enabling them together is not always the best approach since it can introduce other problems to solve.

Regards,
Muthu

Regards,
Sasha

To: 'Muthu Arul Mozhi Perumal' <[email-masked]<mailto:[email-masked]>>

Muthu,

Regards,
Sasha

​

Regards,
Muthu

Regards,
Sasha

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

Regards,
Muthu

Regards,
Sasha

Stefano,

My 2c,

Sasha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 16 May 2017 09:57:45 -0700

resending with reduced number of recipients.

Cheers,

Jeff

Sasha,

Don’t forget – RSVP-TE FRR has explicit signaling and state associated with it, as well as well defined state transitions, SR on contrary doesn’t. 

Changes in topology (link/node down events) are not communicated back to the head-end directly but rather flooded thru a routing protocol (for sake of this discussion lets ignore the possibility of running fast failure detection over SR tunnels).

Trying to derive operation state at PLR based on transitional changes in a routing protocol is a rather complicated task.

Cheers,

Jeff

From: spring <[email-masked]> on behalf of Alexander Vainshtein <[email-masked]>
Date: Tuesday, May 16, 2017 at 09:23
To: Muthu Arul Mozhi Perumal <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Shell Nakash <[email-masked]>, Michael Gorokhovsky <[email-masked]>, "[email-masked]" <[email-masked]>, Sidd Aanand <[email-masked]>, "Stefano Previdi (sprevidi)" <[email-masked]>, Ron Sdayoor <[email-masked]>, Rotem Cohen <[email-masked]>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Muthu,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Sasha,

On Tue, May 16, 2017 at 4:29 PM, Alexander Vainshtein <[email-masked]> wrote:

Muthu,

Regards,

Muthu

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Muthu,

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

On Tue, May 16, 2017 at 3:27 PM, Alexander Vainshtein <[email-masked]> wrote:

Muthu,

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.  

​

Regards,

Muthu

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

B-----C   

|    / \

|   /   \ 

|  /     \

| /       \D----+ 

A/              Z (CE)

 \         F----+ 

  \       /

   \     /

    \   / 

     \E/

- Z is a dual-homed CE.

Regards,

Muthu

On Tue, May 16, 2017 at 1:59 PM, Alexander Vainshtein <[email-masked]> wrote:

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Stefano,

My 2c,

Sasha

Office: +972-39266302

Cell:      +972-549266302

 

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]] 
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]; Shell Nakash <[email-masked]>; Michael Gorokhovsky <[email-masked]>; Sidd Aanand <[email-masked]>; Ron Sdayoor <[email-masked]>; Rotem Cohen <[email-masked]>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

 

 

 

 

 

s.

_______________________________________________ spring mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spring

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 17 May 2017 07:36:23 +0000

> On May 16, 2017, at 4:24 PM, Alexander Vainshtein <[email-masked]> wrote:
> 
> Stefano, 

I have nothing against quantum mechanics. Even more, I’d really encourage anyone to study this wonderful aspects of our universe.

Having said that, I’d remind you that ietf is about engineering, not science and we’re not here to list any possible combination of components that we describe in a drafts.

We’re here to address REAL problems and REAL requirements expressed by the industry that, at the end of the day, deploy and operate what we define and implement.

According to all the comments I’ve seen on this read, it looks to me the WG is inline with this and it doesn’t appear to me (please correct if I’m wrong) that there’s any consensus in extending the list of requirements of the resiliency use-cases draft.

Thanks.

s.

PS: nothing prevents you to cook a pizza with ham and chocolate... but that’s not a valid reason to do it...

>>> __

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 17 May 2017 08:16:52 +0000

Jeff,
Lots of thanks for the comment.

I fully agree with your explanation of differences between SR-TE and TE that is based on RSVP-TE LSP.

From my POV the resiliency use cases draft<https://datatracker.ietf.org/doc/draft-ietf-spring-resiliency-use-cases/?include_text=1> implicitly recognizes this differences when it says that E2E path protection requires E2E liveness monitoring of the SR paths involved.

I would like to clarify that I see one more difference between TE that is used on RSVP-TE and SR-TE:

-          RSVP-TE LSPs and “shortest path” (LDP) LSPs run as ships in the night: a local protection scheme that repairs an LDP LSP will not affect any RSVP-TE LSPs and vice versa

-          SR-TE LSPs frequently can be treated as sequences of nested shortest path SR LSPs (at least that is what happens if the ERO of an SR-TE LSP is represented by a sequence of Node SIDs).   Therefore whatever happens to a certain shortest path SR LSP will be “inherited” by all SR-TE LSPs that include it.

This difference is the basic assumption behind  my proposal for combining local and path protection schemes.
It does not assume that PLR makes any decisions “based on transitional changes in a routing protocol”.
Quite on the contrary, local protection would be triggered by locally detected events (e.g., locally detected failure of a link towards the next hop of the shortest path, or loss of IP reachability of this next hop) . Local protection would be then applied to the shortest SR paths (could be IPv6 FRR if the SR data plane is IPv6, or MPLS FRR based  on IP LFA  - same as can be done for LDP LSPs).

Once this happens and shortest SR LSPs that suffered from the failure are repaired by the local protection action, all SR-TE LSPs that use these shortest path LSPs would be automatically repaired as well.

Hopefully these notes clarify my position on the subject.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

From: Jeff Tantsura [mailto:[email-masked]]
Sent: Tuesday, May 16, 2017 7:58 PM
To: Alexander Vainshtein <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Cheers,
Jeff

Sasha,

Cheers,
Jeff

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 16, 2017 at 09:23
To: Muthu Arul Mozhi Perumal <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shell Nakash <[email-masked]<mailto:[email-masked]>>, Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sidd Aanand <[email-masked]<mailto:[email-masked]>>, "Stefano Previdi (sprevidi)" <[email-masked]<mailto:[email-masked]>>, Ron Sdayoor <[email-masked]<mailto:[email-masked]>>, Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

Muthu,

&#0;.     In SR some failures cannot be handled by local protection (actually, there is an expired draft that defines how this could be done, but it introduces serious complexity)

&#0;.     Combining local protection with end-to-end path protection is possible. In particular, such a combination speeds up handling of failures that that can be handled locally while also handling failures that could not be addressed by local protection.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302

Sasha,

Regards,
Muthu

Regards,
Sasha

Muthu,

Regards,
Sasha

​

Regards,
Muthu

Regards,
Sasha

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

Regards,
Muthu

Regards,
Sasha

Stefano,

My 2c,

Sasha

-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:[email-masked]]
Sent: Monday, May 15, 2017 11:12 AM
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Shell Nakash <[email-masked]<mailto:[email-masked]>>; Michael Gorokhovsky <[email-masked]<mailto:[email-masked]>>; Sidd Aanand <[email-masked]<mailto:[email-masked]>>; Ron Sdayoor <[email-masked]<mailto:[email-masked]>>; Rotem Cohen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] A belated comment on end-to-end path protection in draft-ietf-spring-resiliency-use-cases

s.

_______________________________________________ spring mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spring