I uploaded version -13 with the change Thanks
Ahmed On Mon, Jan 15, 2024, 11:16 PM Gyan Mishra <[email protected]> wrote: > > 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
