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):
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.
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
Email: [email protected]
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 14, 2018 1:57 PM
To: Alexander Vainshtein <[email protected]>;
[email protected]
Cc: Stewart Bryant <[email protected]>; Michael Gorokhovsky
<[email protected]>;
[email protected]; [email protected];
[email protected]
Subject: RE: Is TI-LFA compatible with the default SR algorithm?
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 protected]] On Behalf Of Alexander Vainshtein
Sent: Wednesday, June 13, 2018 17:00
To:
[email protected]<mailto:[email protected]>
Cc: Stewart Bryant; Michael Gorokhovsky;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>
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):
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 protected]<mailto:[email protected]>
___________________________________________________________________________
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.
___________________________________________________________________________
_________________________________________________________________________________________________________________________
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.
___________________________________________________________________________
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.
__________________________________________________________________________________________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
