Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 13 Jun 2018 14:59:36 +0000

Hi all,
I have looked up Section 3.1.1 "Prefix-SID Algorithm" of the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft (already In the RFC Editor queue) and found there the following statement (the relevant part is highlighted):

This document defines two algorithms:

   o  "Shortest Path": this algorithm is the default behavior.  The
      packet is forwarded along the well-known ECMP-aware SPF algorithm
      employed by the IGPs.  However it is explicitly allowed for a
      midpoint to implement another forwarding based on local policy.
      The "Shortest Path" algorithm is in fact the default and current
      behavior of most of the networks where local policies may override
      the SPF decision.

   o  "Strict Shortest Path (Strict-SPF)": This algorithm mandates that
      the packet is forwarded according to ECMP-aware SPF algorithm and
      instructs any router in the path to ignore any possible local
      policy overriding the SPF decision.  The SID advertised with
      Strict-SPF algorithm ensures that the path the packet is going to
      take is the expected, and not altered, SPF path.  Note that Fast
      Reroute (FRR) [RFC5714<https://tools.ietf.org/html/rfc5714>] mechanisms are still compliant with the
      Strict Shortest Path.  In other words, a packet received with a
      Strict-SPF SID may be rerouted through a FRR mechanism.

At the same time, the TI-LFA draft<https://tools.ietf.org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> discusses protection of active Prefix-SIDs (e.g., in Section 3 that discusses P-Space and Q-space) but, to the best of my understanding, does not mention algorithms that form the context of these SIDs.

My question to the authors of the TI-LFA draft is:

Are the mechanisms defined in the draft (and examples discussed in Section 4) applicable to Prefix-SIDs associated with the default forwarding algorithm as defined in the Segment Routing Architecture draft?

I strongly suspect that it is not so, and that these mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an example that confirms this suspicion.)

Do I miss something substantial here?

Regards, and lots of thanks in advance,
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: <[email-masked]>
Date: Thu, 14 Jun 2018 10:56:30 +0000

Hi Sasha,

Could you elaborate on :" I strongly suspect that it is not so, and that these mechanisms are only compatible with the Strict-SPF. (Actually, I can provide an example that confirms this suspicion.)" ?

Thanks,

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To: [email-masked]
Cc: Stewart Bryant; Michael Gorokhovsky; [email-masked]; [email-masked]; [email-masked]
Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

Hi all,

At the same time, the TI-LFA draft<https://tools.ietf..org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> discusses protection of active Prefix-SIDs (e.g., in Section 3 that discusses P-Space and Q-space) but, to the best of my understanding, does not mention algorithms that form the context of these SIDs.

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

_________________________________________________________________________________________________________________________

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: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jun 2018 13:31:19 +0100

RFC5714 was written when we were focused on routing in base along normal 
Dijkstra shortest paths.

As policy and flexible algorithms become prevalent we need to specify 
that any RFC5714 action is compliant to the policies and intended 
algorithms along the entirety of its path.

We need to think this through carefully, but that may mean that in a 
network where any of these enhanced routing methods are deployed, ALL 
routers doing FRR need to validate the safety of the packet path. There 
may be more computationally efficient ways to do this, but worse case 
looks like needing to precompute the full path to all destinations 
reachable via the failure including applying the policy and algorithms 
installed on all of those routers. What I am unclear of is how we find 
that policy to do that.

Maybe I am being overly pessimistic here, but Sasha makes an interesting 
observation that we need to think through very carefully.

- Stewart

On 14/06/2018 11:56, [email-masked] wrote:
>
> Hi Sasha,
>
> Could you elaborate on :” I strongly suspect that it is not so, and 
> that these mechanisms are only compatible with the Strict-SPF. 
> (Actually, I can provide an example that confirms this suspicion.)” ?
>
> Thanks,
>
> *From:*spring [mailto:[email-masked]] *On Behalf Of 
> *Alexander Vainshtein
> *Sent:* Wednesday, June 13, 2018 17:00
> *To:* [email-masked]
> *Cc:* Stewart Bryant; Michael Gorokhovsky; 
> [email-masked]; [email-masked]; 
> [email-masked]
> *Subject:* [spring] Is TI-LFA compatible with the default SR algorithm?
>
> Hi all,
>
> I have looked up Section 3.1.1 “*Prefix-SID Algorithm*” of the Segment 
> Routing Architecture 
> <https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> 
> draft (already In the RFC Editor queue) and found there the following 
> statement (the relevant part is highlighted):
>
> Reroute (FRR) [RFC5714 <https://tools.ietf.org/html/rfc5714>] 
> mechanisms are still compliant with the
>
> At the same time, the TI-LFA draft 
> <https://tools.ietf..org/html/draft-bashandy-rtgwg-segment-routing-ti-lfa-04> 
> discusses protection of active Prefix-SIDs (e.g., in Section 3 that 
> discusses P-Space and Q-space) but, to the best of my understanding, 
> does not mention algorithms that form the context of these SIDs.
>
> Are the mechanisms defined in the draft (and examples discussed in 
> Section 4) applicable to Prefix-SIDs associated with the default 
> forwarding algorithm as defined in the Segment Routing Architecture draft?
>
> I strongly suspect that it is not so, and that these mechanisms are 
> only compatible with the Strict-SPF. (Actually, I can provide an 
> example that confirms this suspicion.)
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2018 12:45:59 +0000

Stephane,

The default algorithm for Prefix-SIDs is defined in Section 3.1.1 of the Segment Routing Architecture<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> draft as following (the important text is highlighted):

Consider now the following scenario:

1.       The PLR node P uses a simple primary next hop N to reach a destination prefix D.

a.       IP FRR (as defined in RFC 5286<https://tools.ietf.org/html/rfc5286>) is enabled in this node, and it identifies the neighbor L of P  as a local loop-free alternative for reaching D if the link P-->N fails.

b.       In addition, P computes its post-convergence path to D after failure of link P-->N, and decides that L is its primary NH in the post-convergence topology.

c.       According to Section 4.1 of the TI-LFA draft, P decides that:

                                                               i.      N is the repair node for reaching D when the link P-->N fails

                                                             ii.      The egress interface to use is the link P-->L

                                                           iii.      The repair segment list is empty

2.       Now suppose that L is configured with a local policy that overrides its SPF computation and sets its primary NH for reaching D to P

a.       Since this is a local policy (say, implemented using policy-based routing), it remains unknown to P

b.       This policy will not result in any routing loop (at least in some scenarios) as long as the link P-->N is OK

c.       Activation of this policy in L is conditional (how this can be done is not really important at the moment) so that when the link P-->N fails, this policy would be deactivated

d.       However, when this link fails, the combination of the repair path selected by P and the local policy configured in L will result in a routing loop that would exist until  IGP converges again.

Please note that RFC 5286 explicitly states that it is only applicable to intra-domain routing only with OSPF or IS-IS as IGP.
It does not mention the possibility of local policies overriding shortest path routing provided by these protocols.

Does this explanation help?
Regards,
Sasha

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

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 14, 2018 1:57 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>; Michael Gorokhovsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Is TI-LFA compatible with the default SR algorithm?

Hi Sasha,

Thanks,

From: spring [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To: [email-masked]<mailto:[email-masked]>
Cc: Stewart Bryant; Michael Gorokhovsky; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [spring] Is TI-LFA compatible with the default SR algorithm?

Hi all,

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

Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2018 12:47:40 +0000

Stewart,
Lots of thanks for a prompt and highly meaningful response.

Regards,
Sasha

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

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, June 14, 2018 3:31 PM
To: [email-masked]; Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: Michael Gorokhovsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Is TI-LFA compatible with the default SR algorithm?

RFC5714 was written when we were focused on routing in base along normal Dijkstra shortest paths.

As policy and flexible algorithms become prevalent we need to specify that any RFC5714 action is compliant to the policies and intended algorithms along the entirety of its path.

We need to think this through carefully, but that may mean that in a network where any of these enhanced routing methods are deployed, ALL routers doing FRR need to validate the safety of the packet path. There may be more computationally efficient ways to do this, but worse case looks like needing to precompute the full path to all destinations reachable via the failure including applying the policy and algorithms installed on all of those routers. What I am unclear of is how we find that policy to do that.

Maybe I am being overly pessimistic here, but Sasha makes an interesting observation that we need to think through very carefully.

- Stewart

On 14/06/2018 11:56, [email-masked]<mailto:[email-masked]> wrote:
Hi Sasha,

Thanks,

Hi all,

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

Thank you.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jun 2018 13:58:32 +0100

On 14/06/2018 13:45, Alexander Vainshtein wrote:
>
> Please note that RFC 5286 explicitly states that it is only applicable 
> to intra-domain routing only with OSPF or IS-IS as IGP.
>
> It does not mention the possibility of local policies overriding 
> shortest path routing provided by these protocols.
>

10 years ago when we were thinking about these early IPFRR schemes I 
don't recall anyone considering anything
other that simple Dijkstra paths for IP. The exception perhaps was 
Not-Via, but in that case base connectivity
and repair had orthogonal address spaces. I am not sure is that is the 
direction with policy and flex, but
that may be a required direction for unconditional safety.

- Stewart

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 14 Jun 2018 13:58:40 +0000

Stewart,
Lots of thanks for the clarification.

Coming back to the TI-LFA draft, I think that it should explicitly state that  in the case of Prefix-SIDs it is applicable to Prefix-SIDs associated with the  strict SPF algorithm but does not guarantee any results in the case of Prefix-SIDs associated with the default algorithm.

Regards,
Sasha

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

From: Stewart Bryant [mailto:[email-masked]]
Sent: Thursday, June 14, 2018 3:59 PM
To: Alexander Vainshtein <[email-masked]>; [email-masked]
Cc: Michael Gorokhovsky <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Is TI-LFA compatible with the default SR algorithm?

10 years ago when we were thinking about these early IPFRR schemes I don't recall anyone considering anything
other that simple Dijkstra paths for IP. The exception perhaps was Not-Via, but in that case base connectivity
and repair had orthogonal address spaces. I am not sure is that is the direction with policy and flex, but
that may be a required direction for unconditional safety.

- Stewart