Alexander,
On 30/04/2020 17:21, Alexander Vainshtein wrote:
Hi all,
I have a question about the proposed usage of SRLG in the IGP Flexible
Algorithm <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-07> draft.
This usage is defined Section 12 of the draft with the reference to the
SRLG exclude rule as following:
2. Check if any exclude SRLG rule is part of the Flex-Algorithm
definition. If such exclude rule exists, check if the link is
part of any SRLG that is also part of the SRLG exclude rule. If
the link is part of such SRLG, the link MUST be pruned from the
computation.
This looks effectively undistinguishable from the usage of the exclude
Admin groups rule as described in the same Section 12 of the draft:
1. Check if any exclude rule is part of the Flex-Algorithm
definition. If such exclude rule exists, check if any color that
is part of the exclude rule is also set on the link. If such a
color is set, the link MUST be pruned from the computation.
From my POV, with such a definition, there is no need in the dedicated
“Exclude SRLG” rule as part of the specification of the Flexible
Algorithm, since such the SRLG Exclude rule can be replaced with a
matching Exclude All rule using Admin groups.
there is one very important point. Maintaining the affinities is
operationally complex. Some networks have already deployed SRLGs. If
SRLG exclude with flex-algo gives people what they want, asking them to
deploy affinities would be redundant. That's the main point.
Simple use case:
I have two SRLGs in the network. For some specific traffic I want to
send the data via two independent streams. I want to avoid single SRLG
failure to affect both streams. I define two flex-algos, each one
excluding one SRLG. No need to define extra affinities. This is btw not
an academical example, this has been requested by real users.
I also think that such a usage of SRLG does not fit the needs of the
TI-LFA
<https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-03>
draft that considers an SRLG as a resource that fails when any of the
links/nodes comprising it fails. E.g., it says in Section 2:
The Point of Local Repair (PLR), S, needs to find a node Q (a repair
node) that is capable of safely forwarding the traffic to a
destination D affected by the failure of the protected link L, a set
of links including L (SRLG), or the node F itself. The PLR also
needs to find a way to reach Q without being affected by the
convergence state of the nodes over the paths it wants to use to
reach Q: the PLR needs a loop-free path to reach Q.
I see no conflict between the LFA draft and flex-algo one. If you do,
please be precise where the conflict is.
To me this suggests that SRLGs are only relevant when computing backup
paths for specific failures, e.g., an LFA for failure of a link hat
belongs to a specific SRLG must be computed in the topology from which
all the links belonging to the same SRLG are pruned. This understanding
matches RFC 4090 that states in Section 6.2 “Procedures for Backup Path
Computation”:
SRLG is a mechanism to express fate share. I see no reason why SRLG
could not be used for other than LFA purposes.
thanks,
Peter
- The backup LSP cannot traverse the downstream node and/or link
whose failure is being protected against. Note that if the PLR
is the penultimate hop, node protection is not possible, and
only the downstream link can be avoided. The backup path may be
computed to be SRLG disjoint from the downstream node and/or
link being avoided.
If SRLGs are only relevant for computation of backup paths, it is not
clear to me if they should be part of the definition of a specific
Flexible Algorithm.
What, if anything, did I miss?
Regards, and lots of thanks in advance,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
transmission in error, please inform us by e-mail, phone or fax, and
then delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
