Skip to main content

Early Review of draft-ietf-rtgwg-segment-routing-ti-lfa-12

Request Review of draft-ietf-rtgwg-segment-routing-ti-lfa
Requested revision No specific revision (document currently at 15)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2023-12-15
Requested 2023-11-23
Requested by Gunter Van de Velde
Authors Ahmed Bashandy , Stephane Litkowski , Clarence Filsfils , Pierre Francois , Bruno Decraene , Daniel Voyer
I-D last updated 2023-12-17
Completed reviews Opsdir Early review of -12 by Gyan Mishra (diff)
Secdir Last Call review of -13 by Wes Hardaker (diff)
Rtgdir Last Call review of -13 by Ben Niven-Jenkins (diff)
Genart Last Call review of -13 by Roni Even (diff)
Opsdir Early review of -11 by Gyan Mishra (diff)
Secdir Early review of -10 by Wes Hardaker (diff)
Rtgdir Early review of -09 by Andy Smith (diff)
Intdir Early review of -11 by Antoine Fressancourt (diff)
-11 reviewer asked to re-review the draft and update based upon document enhancements
Assignment Reviewer Gyan Mishra
State Completed
Request Early review on draft-ietf-rtgwg-segment-routing-ti-lfa by Ops Directorate Assigned
Posted at
Reviewed revision 12 (document currently at 15)
Result Ready
Completed 2023-12-17
I have reviewed version 12 and am updating my initial review of TI-LFA in
August which this review.

Based on revision 12 review, the draft is ready for publication.

Review details:

IETF 118 side meeting discussion summary:

We had a very productive discussion during the side meeting, and the review
comments and open issues have been addressed.

Outcome of the discussion:
It’s important for the draft to clarify that with ti-lfa, when IGP starts to
reconverge, there is still a possibility for micro-loops. So customers should
be advised to deploy some micro-loop protection mechanisms to prevent traffic

Action items for authors of the ti-lfa draft:
•  To include text from RFC7490 second paragraph of section 10 - done
•  To include the text summary in the email thread - done
•  Change the text in section 6.1 from node to link - done

Next steps:
After the draft is updated to address the open issues which was completed with
version 12, Gyan Mishra will update the OPS Directorate review, and the RTGWG
WG Chairs will start the WGLC of this draft.

Draft updates from v11 to v12 below:

When the network reconverges, micro-loops [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], [RFC6976],
   [RFC8333], or [I-D.bashandy-rtgwg-segment-routing-uloop] should be

   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 – as part of the
      distributed IGP convergence [RFC5715] on the paths to the
      destination that do not pass thru TI-LFA paths:

      -  As explained in [RFC5714], such micro-loops may result in the
         traffic not reaching the PLR and therefore not following TI-LFA

      -  Segment Routing may be used for prevention of such micro-loops
         as described in [I-D.bashandy-rtgwg-segment-routing-uloop].

   *  Micro-loops that appear – or do not appear - when the failed link
      is repaired.

   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

   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 Section 6.2, Section 6.3, or Section 6.4
   of the draft.  One of the possible ways to prevent such micro-loops
   is local convergence delay ([RFC8333]).

   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

   *  The paths used in the micro-loop avoidance procedures typically
      cannot be pre-computed.

6.1.  FRR path using a direct neighbor

   When a direct neighbor is in P(S,X) and Q(D,x) and the link to that
   direct neighbor is on the post-convergence path, the outgoing
   interface is set to that neighbor and the repair segment list SHOULD
   be empty.

   This is comparable to a post-convergence LFA FRR repair.

Major issues:

Minor issues:

Stewart Bryant pick up something that was agreed but was not included in this
summary: we agreed to remove the reference to draft-bashandy in order to make
the discussion on uloop prevention technology neutral.

So the  TI-LFA draft even though it has loop preventing mechanisms that can 
possibly work independently of a separate uLoop avoidance mechanism, that there
are cases as we both pointed out that uLoops can form, in those cases for
further convergence time optimization a separate uLoop prevention mechanism
maybe necessary.

So in that case the current reference to the uLoop avoidance draft could apply.

However, I do think the uLoop draft needs a lot of work particularly section 3
and is an I-D.

So I agree we need to remove any references to the uLoop draft and stating that
a separate from TI-LFAs uLoop prevention technology is necessary.  The uLoop
draft as it exists would be the appropriate draft to be referenced but
unfortunately it’s not ready so I don’t think we should reference it.