Re: [OPS-DIR] Opsdir early review of draft-ietf-rtgwg-segment-routing-ti-lfa-12

[Yingzhen Qu <[e-mail]>]

Hi Gyan,

Thanks for the review and updating the status.

I see you still have one minor issue about referencing
"I-D.bashandy-rtgwg-segment-routing-uloop".
Please let me know if I missed anything.

Authors, please send your reply to the list.

Thanks,
Yingzhen

On Sun, Dec 17, 2023 at 11:05 PM Gyan Mishra <[e-mail]> wrote:

> Hi Yingzhen & Jeff
>
> I completed the updated OPSDIR Review of TO-LFA draft and changed status
> from “serious issues” to “Ready”.
>
> Thank you
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
>
>
> ---------- Forwarded message ---------
> From: Gyan Mishra via Datatracker <[e-mail]>
> Date: Mon, Dec 18, 2023 at 2:00 AM
> Subject: [OPS-DIR] Opsdir early review of
> draft-ietf-rtgwg-segment-routing-ti-lfa-12
> To: <[e-mail]>
> CC: <[e-mail]>, <
> [e-mail]>
>
>
> Reviewer: Gyan Mishra
> Review result: Ready
>
> 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
>
>
> _______________________________________________
> OPS-DIR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir
>