Early Review of draft-ietf-rtgwg-segment-routing-ti-lfa-12
review-ietf-rtgwg-segment-routing-ti-lfa-12-opsdir-early-mishra-2023-12-17-00

I have reviewed version 12 and am updating my initial review of TI-LFA in
August which this review.

Summary:
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
loss.

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
   implemented.

   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
         paths.

      -  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
   pass.

   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
      recovery

   *  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:
None

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.

Nits:
None