Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[Yingzhen Qu <[e-mail]>]

Hi,

I looked at the side meeting schedule, and found the following slot:
 Wednesday (11/8) 14:00 - 15:30.

I hope to have the following key contributors available for the discussion:
Stewart Bryant
Gyan Mishra
Sasha Vainshtein
Stephane Litkowski
Bruno Decraene
Ahmed Bashandy

Of course anyone is welcome to join the discussion.

Please let me know your availability. If this doesn't work out, we'll
schedule an interim after IETF 118.

Thanks,
Yingzhen





On Fri, Nov 3, 2023 at 2:06 AM Stewart Bryant <[e-mail]>
wrote:

>
>
> On 3 Nov 2023, at 02:43, Gyan Mishra <[e-mail]> 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.
>
> 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. 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>