Hi Stewart, From: Stewart Bryant <[email protected]> Sent: Wednesday, November 8, 2023 3:07 PM On 8 Nov 2023, at 13:18, [email protected]<mailto:[email protected]> wrote:
Hi Stewart, Thanks for your email and your rephrased summary. Strangely, I feel that we are in agreement. At least, unless I missed a point, I agree with your below email. I'd propose to rephrase it to check if you do agree with my rephase. (3-way handshake seems safer). Please find below my summary: a. TI-LFA is a FRR solution which works. It provides a loop-free protection from the PLR to the destination. b. When IGP convergence starts, micro-loop may happen because of this distributed IGP convergence. It may affect the forwarding from the source/ingress to the PLR (and hence starve the PLR) c. If one promised 50 ms recovery to their customers, one need both a FRR solution and a micro-loop solution. (TI-LFA being a FRR solution, you still need a micro-loop solution) Are we in sync on the above? (on a side note, what we call "micro-loops" is "a possibility for micro-loops". They may not happen (by topology or chance) in which case, the customer did see an improvement with FRR only) We agree. However I would note that it is hard to be sure of the topology because a failure may move the a network element and move the network from uloop free to uloop possible. Excellent. To me the key point is agreement on the technical aspects. Based on this we can discuss the wordings. If not, please correct me. If so, * I agree. This is not new (IMO) and also applicable to RLFA, which did mention this (credit to you) in its section 10. https://datatracker.ietf.org/doc/html/rfc7490#section-10 * I had proposed you to add the same text in TI-LFA (for simplicity since you, WG and IESG already agree on this) but after discussion with you and Sasha the current proposed text is the following 1. 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: a. 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 i. As explained in RFC 5714, such micro-loops may result in the traffic not reaching the PLR and therefore not following TI-LFA paths ii. Segment Routing may be used for prevention of such micro-loops as described in the micro-loop avoidance draft How about: Ii. Any of the methods described in RFC 5714 may be used to prevent the formation of micro loops and some of these methods may be enhanced, or new methods designed through the use of Segment Routing. A number of these methods may be used concurrently in the network. It's better. Thanks for the suggestion. I can live with that, but I don't hold the pen and for sure others person may further comment. (on a side note, as an operator, draft-basandi makes sense to me since its restriction is the requirement for SR and one having deploy TI-LFA has already deploy SR which makes both solution complementary IMHO. But draft-bashandi is an individual draft while RFC 5714, although old, is a RFC. Plus I'd rather avoids discussion about beauty contest on something which is largely independent of TI-LFA) b. Micro-loops that appear - or do not appear - when the failed link is repaired 2. 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 3. 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 6.2, 6.3 or 6.4 of the draft. One of the possible ways to prevent such micro-loops is local convergence delay (RFC 8333). 4. TI-LFA procedures are complementary to application of any micro-loop avoidance procedures in the case of link or node failure: 1. 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 2. The paths used in the micro-loop avoidance procedures typically cannot be pre-computed. https://mailarchive.ietf.org/arch/msg/rtgwg/oY3gGIZMRCTRptTDxrpuSaBztGY/ (proposal) https://mailarchive.ietf.org/arch/msg/rtgwg/oY3gGIZMRCTRptTDxrpuSaBztGY/ (next email with Sasha agreeing) That being said, I'm not married with this text: it's just that Sasha proposed text (thanks Sasha) and I agreed with it. It's ok to change the text if you want to propose something else to change some parts. (Personally, I feel that the text could be made more synthetic/shorter, but after so many difficulties to communicate, I was happy to jump on a proposed text). I would just assume that the text you would propose would be on the same line. Next, is this micro-loop aspect the only issue you wanted to raise or is there another point? Yes, this is the other key point. It should probably go on a section on microloops. I'd rather leave the name of the section to the editor. To me, main point is to agree on the technical aspect first, and then on the text to be adding. Then I might suggest that we need a section similar to section 10 of RFC7490 that addresses the management considerations and points back to the uloop text in the TilFA draft. This ensures that the operator community (and in particular their managers and accountants) are more easily made aware of this concern and are not tempted to optimise it away. Putting the micro-loop text in this section would works for me. But again, up to the editor. I'm less certain about the path management considerations discussions. To me TI-LFA is quite different than LFA & RFLA on those aspects: * With LFA and RLFA one kind of struggle to increase protection coverage. Then sometimes one have multiple/too many options, which open the question is choosing the "good" one. * With TI-LFA, you can define your preferences upfront (e.g., for me, best path as per IGP metric), compute exact best path according to those preferences, and then ask TI-LFA/SR to do it's magic to enforce that path. At this point, TBH, I would be reluctant to open a new can of worms. And I'm not interested in comparing TI-LFA with RLFA (on those path management aspects or others) (FYI, to me, TI-LFA is very good, but the magic mainly comes from SR. The building block was RLFA.). So I'd rather say that if someone is interesting on this, he should initiate an RFC 7916bis if he believes that this is needed. Thank you for considering these points Thank you for rephrasing your points. (versus the text in your slides) --Bruno Stewart --Bruno Orange Restricted From: Stewart Bryant <[email protected]<mailto:[email protected]>> Sent: Wednesday, November 8, 2023 9:37 AM To: Gyan Mishra <[email protected]<mailto:[email protected]>> Cc: Stewart Bryant <[email protected]<mailto:[email protected]>>; Ahmed Bashandy <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; rtgwg-chairs <[email protected]<mailto:[email protected]>> Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment On 8 Nov 2023, at 05:18, Gyan Mishra <[email protected]<mailto:[email protected]>> wrote: In the below RLFA RFC 7490 style loop topology R1, R4, R5 are in the extended P space and and Q space being R5, R6, R3 and TO-LFA algorithm post convergence path calculated RLFA PQ node being R5. Using section 6.4 to build the post convergence repair path using RFC 5715 near side tunneling the repair path is NodeSid(R5), AdjSid(R6). So a near side tunnel is now built from R1 to R6. Looping is not an issue with R4 or R5 in looping packets back to R1 as the repair path is built from R1 to R6, tunneling over any nodes with un-converged FIBs. Micro loop problem solved! CE1 -R1- R2-/-R3-CE2 | | R4 - R5 -R6 I think that it is important to note that if R1 reconverges first it will send packets to R4 using normal forwarding. However R4 is ECMP to CE2 via R1 which will micro loop back to R4. At this point the repair is starved and no longer works. Hence the point that I have been making and I think the point that Gyan originally made. Without FRR the network converges in its own time and we accept micro loops and traffic discontinuity for an unknown time plus collateral damage to traffic that never used the failed link. However once we deploy FRR we make a contract with the user that after a short while - of the order of 50ms - productive forwarding will continue uninterrupted. However this is not the case in some topologies (see above) and thus uloop prevention is required. The thread has become somewhat difficult to follow with time, so I am now not sure what Bono's text is. It would be helpful if it were repeated. However I think the draft has to say that in order to warrant that FRR continues to provide traffic continuity until the network is reconverged a uloop strategy is required. I would note as it is easily forgotten that a uloop strategy is also required when R2-R3 goes back into service. This is because if R4 converges first it will ECMP back to R1 which will send the packet back to R1. Now we need to be clear that the micro looking is not the fault of the TiLFA design per se, but given that networks will deploy TiLFA with certain traffic continuity expectations we must clearly note to the reader that those expectations may not be met without addressing the uloop problem. By way of referencing earlier work, RFC5714 does point to RFC5715 stating that a uloop technology is needed. In Section 10 of RFC 7490 the issue of loops is drawn to the attention of the network manager although perhaps with hindsight the text should be stronger. - Stewart ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. Orange Restricted ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
