Yes that is correct. Thank you
<http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Mon, Jan 15, 2024 at 10:33 PM Ahmed Bashandy <[email protected]> wrote: > Question regarding removal of references to > draft-bashandy-rtgwg-segment-routing-uloop. > > My understanding is that you are suggesting I remove the following bullet > from Section 2 > > > * - Segment Routing may be used for prevention of such micro-loops > as described in [I-D.bashandy-rtgwg-segment-routing-uloop].* > > Is my understanding correct? > > Ahmed > On 12/17/23 11:05 PM, Gyan Mishra 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 [email protected] <[email protected]>* > > > > *M 301 502-1347 * > > > > ---------- Forwarded message --------- > From: Gyan Mishra via Datatracker <[email protected]> > 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: <[email protected]> > CC: <[email protected]>, < > [email protected]> > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ops-dir > >
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
