Hi Stewart, Please see inline [Bruno]
Orange Restricted From: rtgwg <rtgwg-boun...@ietf.org> On Behalf Of Stewart Bryant Sent: Friday, November 3, 2023 10:06 AM To: Gyan Mishra <hayabusa...@gmail.com> Cc: draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; rtgwg-chairs <rtgwg-cha...@ietf.org>; Alexander Vainshtein <alexander.vainsht...@rbbn.com> Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment On 3 Nov 2023, at 02:43, Gyan Mishra <hayabusa...@gmail.com<mailto:hayabusa...@gmail.com>> wrote: Gyan> TI-LFA is a critical draft for operator SR deployments and I agree getting it published asap is a good idea. All vendors that have implemented TI-LFA have implemented uLoop. In reality any operator deploying TI-LFA would always deploy uLoop avoidance at the same time per vendor recommendation. The uLoop I-D is 7 years old and is mature as every vendor that has implemented TI-LFA has also implemented uLoop, so I think this could be slam dunk to do a quick Adoption followed by expedite through WGLC and publish. The other option is combine the drafts which may or may not be favorable to the WG. The uLoop basic concept is simple ->> building a list of adj-sid from PLR to RLFA PQ node merge point with a timer set at time T1 post convergence and removed when T2 timer pops. Simple! The solution for TI-LFA in my mind is not complete without uLoop. The major issue that Stewart pointed out is related to multiple entry points or chain of P space nodes preceding the PLR or multiple Q space nodes preceding the RLFA PQ node merge point is what I documented in my review. Any of those longer chain of nodes can have uLoop distributed convergence cascaded delays. TI-LFA implementations aim to solve with optimized least number of SID to avoid hardware MSD issues to solve the problem using a single node-sid plus maybe an adj-sid and at most 4 sid's. Use of node-sid yields ECMP along the chain of nodes not yet converged resulting in many possible micro loops is the major issue that the hop by hop list of adj-sid's along the post convergence path solves with the uLoop draft. I don't know of any other way to resolve the TI-LFA uLoop issue if implemented by itself if node-sid ECMP is utilized. One option but unlikely is in case of chain of nodes exists, that TI-LFA if configured by itself w/o uLoop while signaling for MSD maximum threshold, can build an adj-sid list across the nodes not yet converged from PLR to PQ node merge point. Other then trying to fix TI-LFA so it can work independently of uLoop feature is to do what we have been discussing in the thread about adding txt related to micro loops and interaction between TI-LFA draft and uLoop draft. Cheers, Gyan As I noted earlier in the thread, unless you need to ensure that the repair path is congruent with the post convergence path for TE reasons, you never need more than two labels for a link repair. [Bruno] That's equally the case with TI-LFA (i.e. when following the post convergence path). If you use the procedures in RFC 7490 then at most you need two labels for link failure. One can be a normal MPLS label, the second is a label that get the packet from P to Q. When we wrote RFC 7490 we did not have SR, so we were expecting to use T-LDP which created additional state in the network. Now SR-MPLS is deployed you can use an SR label to get from P to Q and thus avoid the need for T-LDP [1]. I would point out that none of this actually requires standardisation, since the repair is a unitary action by the PLR and uses existing widely deployed MPLS technology, i.e. any path that gets to P then Q will work and any path can be chosen that meets the needs of the operator. The notion that forcing the repair path to the post convergence path from the PLR solves all the TE problems is questionable since, as was noted the very first time TiLFA was mooted, the operational traffic may no longer go via the PLR post convergence. [Bruno] I should probably refrain from commenting but to me this last point is moot. During fast reroute, the question is rerouting the traffic that reached the PLR. What happened before, happened and nobody can do anything about this. It is also clear from these discussions that whilst TiLFA solves the problem of micro looping along the path from the PLR to Q space, that is not adequate in itself and thus not a useful path constraint. [Bruno] I would assume that we agree that TI-LFA works and provide a loop free path from the PLR to the destination (to the Q space if you want). I'm not sure to see when you call it non-adequate. Simplifying the design to use exiting RFC 7490 with an SR label to get from P to Q would not invalidate any TiLFA implementation but would make it clear that implementations could chose any path that best suited their needs. [Bruno] yes, if you want you could use any path. But TI-LFA use the IGP shortest path which is defined as the best path. Why would you want to pick another path? Plus using this shortest path has extra nice benefits which are described in section 2 (Introduction) If we expect failure to be a rare event, then we could control the convergence with an unoptimised ordered fib solution an approach which is also a unitary action at the PLR. Of course the PLR might choose to calculate the optimum path cost values to speed up the process. [Bruno] we are not preventing you or anyone to use oFIB. You want oFIB, please use oFIB. But here, you are digressing to uloop, while TI-LFA is about FRR. If we need a more expeditious approach then we can achieve this with a method such as nearside tunnelling which also needs at most one ordinary MPLS label. Now let us go up a level. This is an emergency use safety system. Safety engineering teaches two things, firstly that such systems are rarely executed and thus bugs may remain hidden for a long time before then manifest themselves, and secondly they normally need to applied in circumstances where instrumentation is difficult. The design philosophy in such systems is normally that they are extremely simple and thus will obviously work under all circumstances both those that are "expected" and those that are "reasonably unexpected". This is why most safety systems are at first glance quite primitive. With TiLFA I think we have lost sight of the need for simplicity and thus have an higher risk of a repair failure than we would have in a simpler but adequately functional alternative approach. [Bruno] Let's not make it a beauty contest. Personally, having worked on this subject for a long time, on multiple networks, TI-LFA is simpler to operate: to speak to any network operator and refer to the IGP shortest path, and he will know what this path is. Compared to RLFA or MRT computations, where the path are different and the computations not natural for a typical human brain. Best regards, --Bruno Best regards Stewart [1] Node failure is intrinsically more complex for all solutions and many more labels (or network state) may be needed. This was written up as the cartwheel problem in which a node has a black hole effect on the traffic and you need to skim the traffic around the rim of the cartwheel. ____________________________________________________________________________________________________________ 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 rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
