Thank you <http://www.verizon.com/>
*Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347* On Tue, Jan 16, 2024 at 1:47 AM Ahmed Bashandy <[email protected]> wrote: > OK > > I'll make the change in the next few days and reply to this email with > version 13 > > > Ahmed > > > On 1/15/24 8:12 PM, Gyan Mishra wrote: > > > 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
