Bruno, Stewart and all,
I think that most of the things about TI-LFA and micro-loops have been said
already (if in a slightly different context) and are mainly self-evident.
However, I share the feeling that somehow the relationship between TI-LFA and
micro-loop avoidance has become somewhat muddled.
Therefore, I would like to suggest adding some text to the TI-LFA draft that
clarifies this relationship, e.g., along the following lines:
1. TI-LFA is a local operation applied by the PLR when it detects failure of
one of its local links. As such, it does not affect:
* Micro-loops that appear – or do not appear –on the paths to the
destination that do not pass thru TI-LFA paths
i. As
explained in RFC 5714, such micro-loops may result in the traffic not reaching
the PLR and therefore not following TI-LFA paths
ii. Segment
Routing may be used for prevention of such micro-loops as described in the
micro-loop avoidance draft
* Micro-loops that appear – or do not appear - when the failed link is
repaired (aside: the need for this line is based on personal experience☹)
1. TI-LFA paths are loop-free. What’s more, they follow the post-convergence
paths, and, therefore, not subject to micro-loops due to difference in the IGP
convergence times of the nodes thru which they pass
2. TI-LFA paths are applied from the moment the PLR detects failure of a
local link and until IGP convergence at the PLR is completed. Therefore, early
(relative to the other nodes) IGP convergence at the PLR and the consecutive
”early” release of TI-LFA paths may cause micro-loops, especially if these
paths have been computed using the methods described in Section 6.2, 6.3 or 6.4
of the draft. One of the possible ways to prevent such micro-loops is local
convergence delay (RFC 8333).
3. TI-LFA procedures are complementary to application of any micro-loop
avoidance procedures in the case of link or node failure:
* Link or node failure requires some urgent action to restore the
traffic that passed thru the failed resource. TI-LFA paths are pre-computed and
pre-installed and therefore suitable for urgent recovery
* The paths used in the micro-loop avoidance procedures typically cannot
be pre-computed.
Hopefully these notes would be useful.
Regards,
Sasha
From: rtgwg <rtgwg-boun...@ietf.org> On Behalf Of bruno.decra...@orange.com
Sent: Thursday, October 19, 2023 7:34 PM
To: Stewart Bryant <stewart.bry...@gmail.com>
Cc: rtgwg@ietf.org; rtgwg-chairs <rtgwg-cha...@ietf.org>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple
pathological network fragment
Hi Stewart,
I agree with you on the technical points, so the first part of your email up to
“So I think”.
But I don’t quite follow why you want to mix IGP Convergence issues with this
Fast ReRoute Solution.
To quote RFC 5714 « IP Fast Reroute Framework”
In order to reduce packet disruption times to a duration commensurate
with the failure detection times, two mechanisms may be required:
a. A mechanism for the router(s) adjacent to the failure to rapidly
invoke a repair path, which is unaffected by any subsequent re-
convergence.
b. In topologies that are susceptible to micro-loops, a micro-loop
control mechanism may be required
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>].
Performing the first task without the second may result in the repair
path being starved of traffic and hence being redundant.
https://datatracker.ietf.org/doc/html/rfc5714#section-4<https://datatracker.ietf.org/doc/html/rfc5714#section-4>
I would assume that you agree with the above (as you are an author of this RFC
and my guess would be that you wrote that text)
My point is that there are two different mechanisms involved, in two different
time periods:
- Fast ReRoute (“a”): this is the scope of
draft-ietf-rtgwg-segment-routing-ti-lfa
o Timing: from detection time , to start of the IGP convergence
- IGP Micro-loop avoidance (“b”)
o Timing: from start of IGP convergence to end of IGP convergence
The scope of draft-ietf-rtgwg-segment-routing-ti-lfa is FRR / “a”. IGP
micro-loop is out of scope. Other documents are proposing solutions for this.
(and for those Micro-loop documents, FRR is similarly out of scope).
Personally I agree with you that both mechanisms are needed. But I think that
this is already highlighted in RFC 5714, and that this is no different than RFC
7490 (RLFA). Therefore, I don’t see why the outcome/text should be different.
Hence my proposition to reuse the text from RFC 7490 (RLFA). I find it
adequate. You wrote it so probably find it adequate.
On a side note, RFC5715, that you also wrote, seems to already cover what you
are asking for. Quoting the abstract, it
provides a summary of the causes and consequences of
micro-loops and enables the reader to form a judgement on whether
micro-looping is an issue that needs to be addressed in specific
networks.
Note that this RFC5715 is already cited in the proposed text.
PS: If you were ready to wrote a 5715bis, I would support this.
Best regards,
--Bruno
Orange Restricted
From: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Sent: Tuesday, October 17, 2023 1:48 PM
To: DECRAENE Bruno INNOV/NET
<bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>>
Cc: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>;
rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs
<rtgwg-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>
Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological
network fragment
Hi Bruno
I was thinking about this some more. It is something that was recognised in the
early days, but somewhat swept aside.
The case that Gyan bought up was an ECMP case, but I fear that the case is more
common and I think we should characterise it as part of the text rather that
giving the impression it is unusual.
I think the problem occurs whenever there are two or more nodes between the
point of packet entry and the failure.
CE1 - R1 - R2 - R3 - R4 -/- R5 - CE2
| |
R6 - R7 - R8 - R9 — R10
The normal path CE1-CE2 is via R2
When R4-R5 fails it is trivial to see how the repair works with R7 as the entry
into Q space.
However unless R1, R2, R3 converge in that order there will be microloops for
traffic entering via any of those three nodes.
So I think we can say that unless the PLR is only receiving traffic to be
protected directly or from its immediate neighbour it is not guaranteed that
there will not be micro loops that are not addressable by the propose strategy
of aligning the repair path with the post convergence path.
Now thinking about the text you have below, I think we need to write in in
terms of - Unless the operator is certain that no micro loops will form over
any path the protected traffic will traverse between entry to the network and
arrival at the PLR a micro loop avoidance method MUST be deployed. Of course I
think that it would be helpful to the operator community for the text to
provide some guidance on how to ascertain whether there is a danger of the
formation of micro loops.
I would note that the long chains of nodes show in the example above were
probably not present in the test topologies which as I remember were all
national scale provider networks, but unless we provide guidance otherwise
Ti-LFA could reasonably be deployed in edge networks and in the case of cell
systems these are often ring topologies.
So I think we need to agree (as a WG) on the constrains that we are prepared to
specify in the text and the degree of warning we need to provide to the
operator community and then we can polish the text below.
Best regards
Stewart
On 16 Oct 2023, at 17:25,
bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> wrote:
Hi Stewart,
Please see inline
Orange Restricted
From: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Sent: Monday, October 16, 2023 2:08 PM
To: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs
<rtgwg-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>>;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>
Cc: Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>
Subject: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological
network fragment
During the operations directorate early review of
draft-ietf-rtgwg-segment-routing-ti-lfa
Gyan Mishra points to a simple pathological network fragment that I think
deserves wider discussion.
https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25/<https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25/>
I am not aware of any response to the RTGWG by the draft authors concerning the
review comment and I cannot see obvious new text addressing this concern.
The fragment is as follows
CE1 –R1- R2-/-R3-CE2
| |
R4 – R5 -R6
In the pre converged network R4 is ECMP CE2 via R5 (cost 4) and via R1 (cost
also 4).
We can easily build a TI-LFA repair path from R2 under link failure to CE2 (so
long as we remember that R4 is an ECMP path to CE2), but the problem occurs
during convergence. If R1 converges before R4, R4 may ECMP packets addressed to
CE2 back to R1 in a micro loop. Meanwhile since no packets for R3 are reaching
R2 the Ti-LFA repair is not doing anything useful.
The Ti-LFA text leads the reader to conclude that it is a loop-free solution,
but gives no guidance on how to determine when this assumption breaks down.
There is an informational reference to
draft-bashandy-rtgwg-segment-routing-uloop, but this short individual draft
does little in the way of helping the reader determine when loop avoidance
strategy needs to be deployed and the loop-free approach it describes does not
seem to be fully developed.
I am worried that proceeding with the Ti-LFA draft without noting that there is
a real risk that simple network fragments can micoloop, and providing a fully
formed mitigation strategy is a disservice to the operator community given the
industry interest in Ti-LDA and the insidious nature of unexpected micro loop
network transients, I am wondering what the view of the working group is on how
to proceed.
One approach would be for the Ti-LFA draft to incorporate detailed guidance on
how to determine the risk of a micro loop in a specific operator network, and
to provide specific mitigation advice. Another approach would be to reference
a developed loop avoidance strategy and recommending its preemptive deployment.
Another approach would be to make draft-bashandy-rtgwg-segment-routing-uloop a
normative reference and tie the fate of the two drafts. Another approach would
be to elaborate on the risks and their manifestations but declare it a
currently unsolved problem. I am sure there are other options that the WG may
formulate.
What is the opinion of the working group on how we should proceed with
draft-ietf-rtgwg-segment-routing-ti-lfa when considering the possible formation
of micro loops?
FRR takes place between the failure (detection) and the IGP reconvergence.
Those are two consecutive steps that the WG has so far addressed with different
solutions and documents.
That’s not new and that’s not specific to TI-LFA. E.g., that’s applicable to
RLFA.
Would the below text, taken verbatim from RFC 7490 (RLFA), work for you? Or
would you say that the text is not good enough?
“When the network reconverges, micro-loops
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>] can form due to
transient inconsistencies in the forwarding tables of different
routers. If it is determined that micro-loops are a significant
issue in the deployment, then a suitable loop-free convergence
method, such as one of those described in
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>],
[RFC6976<https://datatracker.ietf.org/doc/html/rfc6976>], or
[ULOOP-DELAY<https://datatracker.ietf.org/doc/html/rfc7490#ref-ULOOP-DELAY>],
should be implemented.”
https://datatracker.ietf.org/doc/html/rfc7490#section-10<https://datatracker.ietf.org/doc/html/rfc7490#section-10>
Of course, we could update the list of informative references.
E.g., by adding another informative reference to
draft-bashandy-rtgwg-segment-routing-uloop and by removing informative
references to [RFC6976] and [ULOOP-DELAY] which are probably outdated.
--Bruno
- Stewart
____________________________________________________________________________________________________________
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.
____________________________________________________________________________________________________________
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.
Disclaimer
This e-mail together with any attachments may contain information of Ribbon
Communications Inc. and its Affiliates that is confidential and/or proprietary
for the sole use of the intended recipient. Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately and then delete all copies, including any attachments.
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
