RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[Voyer, Daniel]

Hi Bruno & Stewart,

I will start unpacking few things as a warm-up for later this pm when we meet.


  1.  TI-LFA is a FRR solution which works. It provides a loop-free protection 
from the PLR to the destination.
  2.  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)
  3.  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)


[DV] ok, at Bell we did extensive testing (multi-vendor) with different 
topologies, with testset, before going in productions with TI-LFA (and later 
uloop). TI-LFA include local repair (and node protection) and one can achieve 
<50ms convergence “before” adding uloop into the mixt. The testing made sure 
there was NO ECMP paths in the topology just to focus on TI-LFA alone (as well 
as multi-vendor behavior). Our testing included failure AND recovery.
To me, as it was explained before, TI-LFA and micro-loop address different 
problems. And since these concepts were introduced since some time ago already, 
I believe we need real data & facts to continue debating this. I can show 
something “raw” data later today if need be. Perhaps we could ask EANTC if they 
have a public report to show.

With that said, when TI-LFA is combine with micro-loop (and overload-bits is 
tune according to vendor’s platform) you can achieve near <10 ms convergence 
(w/o ECMP in account).

Thanks,
Dan

From: Bruno Decraene 
Date: Wednesday, November 8, 2023 at 2:18 PM
To: Stewart Bryant 
Cc: Ahmed Bashandy , Alexander Vainshtein 
, "rtgwg@ietf.org" , 
"draft-ietf-rtgwg-segment-routing-ti-...@ietf.org" 
, rtgwg-chairs 
, Gyan Mishra 
Subject: [EXT]RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment
Resent-From: 
Resent-To: , , Clarence 
Filfils , Dan Voyer , 
, Bruno Decraene 
Resent-Date: Wednesday, November 8, 2023 at 2:18 PM

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:

  1.  TI-LFA is a FRR solution which works. It provides a loop-free protection 
from the PLR to the destination.
  2.  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)
  3.  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)

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:
 *   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

 *   Micro-loops that appear – or do not appear - when the failed link is 
repaired
  1.  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
  2.  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-loop

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

ed 
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 mailto:stewart.bry...@gmail.com>>
Sent: Wednesday, November 8, 2023 9:37 AM
To: Gyan Mishra mailto:hayabusa...@gmail.com>>
Cc: Stewart Bryant mailto:stewart.bry...@gmail.com>>; 
Ahmed Bashandy mailto:abashandy.i...@gmail.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>; 
rtgwg@ietf.org<mailto:rtgwg@ietf.org>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>;
 rtgwg-chairs mailto:rtgwg-cha...@ietf.org>>
Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment



On 8 Nov 2023, at 05:18, Gyan Mishra 
mailto:hayabusa...@gmail.com>> 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.

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

[Stewart Bryant]

hould probably go on a section on 
microloops. 

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.

Thank you for considering these points

Stewart

>  
> --Bruno
>  
>  
> Orange Restricted
> From: Stewart Bryant  <mailto:stewart.bry...@gmail.com>>
> Sent: Wednesday, November 8, 2023 9:37 AM
> To: Gyan Mishra mailto:hayabusa...@gmail.com>>
> Cc: Stewart Bryant  <mailto:stewart.bry...@gmail.com>>; Ahmed Bashandy  <mailto:abashandy.i...@gmail.com>>; Alexander Vainshtein 
> mailto:alexander.vainsht...@rbbn.com>>; 
> rtgwg@ietf.org <mailto:rtgwg@ietf.org>; 
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org 
> <mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>; rtgwg-chairs 
> mailto:rtgwg-cha...@ietf.org>>
> Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
> network fragment
>  
>  
>  
> 
> On 8 Nov 2023, at 05:18, Gyan Mishra  <mailto:hayabusa...@gmail.com>> 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.

___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

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:

  1.  TI-LFA is a FRR solution which works. It provides a loop-free protection 
from the PLR to the destination.
  2.  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)
  3.  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)

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:
 *   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

 *   Micro-loops that appear - or do not appear - when the failed link is 
repaired
  1.  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
  2.  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).
  3.  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.


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?

--Bruno



Orange Restricted
From: Stewart Bryant 
Sent: Wednesday, November 8, 2023 9:37 AM
To: Gyan Mishra 
Cc: Stewart Bryant ; Ahmed Bashandy 
; Alexander Vainshtein 
; rtgwg@ietf.org; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs 

Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment



On 8 Nov 2023, at 05:18, Gyan Mishra 
mailto:hayabusa...@gmail.com>> 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 w

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

[Stewart Bryant]

> On 8 Nov 2023, at 05:18, Gyan Mishra  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








___
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg

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

[Gyan Mishra]

rect neighbor.  My understanding
AFAIK is that Ti-LFA is a RLFA solution for protection replacing RFC 7490
 T-LDP based RLFA with SR based RLFA.  As well that  AFAIK that TI-LFA is
an extension of the original IP FRR RFC 5286.  So in case where directly
connected path exists for  backup path via local protection in that case it
is a “Local LFA” path.  I don’t think TI-LFA comes into play here.  I have
tested this on Cisco XR on ISIS and OSPF and other vendors as well and when
a directly connected backup path exists the path is flagged as “Local-LFA”
and notTI-LFA. So I don’t agree with section 6.1 that TI-LFA post
convergence path comes into play here.

-Please feel free to use some of the text in this email related to the
importance and characteristics of the post convergence path as well as how
the situation with ECMP is dealt with.

For tomorrows side meeting I could spin up a few slides based on this email
if it would help steer the discussion to closure as I think we are almost
there.

Many thanks to all the folks that participated in this lively discussion!!!


I wish I was in Prague!   Maybe next time!

Cheers!!

Gyan

On Mon, Nov 6, 2023 at 9:36 AM Ahmed Bashandy 
wrote:

> great
>
> I'll change the wording accordingly
>
> Ahmed
>
> On 11/1/23 10:09 PM, Gyan Mishra wrote:
> > Hi Sasha, Bruno & Stewart
> >
> > Thank you for going over my OPSDIR review in detail.
> >
> > I am good with the latest updated verbiage that Bruno had given.
> >
> > Comments in-line
> >
> > On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein <
> > alexander.vainsht...@rbbn.com> wrote:
> >
> >> Bruno,
> >>
> >> Lots of thanks for a prompt and very encouraging response!
> >>
> >>
> >>
> >> Your version of the text is definitely better than mine, I am all for
> >> using it.
> >>
> >>
> >>
> >> As for where the clarifying text could be inserted, I see two options:
> >>
> >> - A common “Applicability Statement” section (there is no such
> section
> >> in the draft)
> >>
> >>
> >> -
> >> - A dedicated section on relationship between TI-LFA and
> micro-loops.
> >>
> >>  Gyan> I think this option would  be best.  This would fix the
> existing
> >> gap on uLoop.  I did mention but not sure if possible- as TI-LFA and
> uLoop
> >> are tightly coupled as a overall post convergence solution is it
> possible
> >> to combine the drafts and issue another WGLC.  (Question for authors)
> >>
> >> In any case, I defer to you and the rest of the authors to decide what,
> if
> >> anything should be done for clarifying the relationship between TI-LFA
> and
> >> micro-loops.
> >>
> >>
> >>
> >>
> >>
> >> Regards,
> >>
> >> Sasha
> >>
> >>
> >>
> >> *From:* bruno.decra...@orange.com 
> >> *Sent:* Monday, October 23, 2023 3:27 PM
> >> *To:* Alexander Vainshtein 
> >> *Cc:* rtgwg@ietf.org; rtgwg-chairs ;
> >> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant <
> >> stewart.bry...@gmail.com>
> >> *Subject:* [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A
> >> simple pathological network fragment
> >>
> >>
> >>
> >> Sasha,
> >>
> >>
> >>
> >> Thanks for the summary and the constructive proposal.
> >>
> >> Speaking for myself, this makes sense and I agree.
> >>
> >>
> >>
> >> Ø  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:
> >>
> >> o   Micro-loops that appear – or do not appear –on the paths to the
> >> destination that do not pass thru TI-LFA paths
> >>
> >>
> >>
> >> As an editorial comment, depending on where such text would be
> inserted, I
> >> would propose the following change:
> >>
> >> OLD: Micro-loops that appear – or do not appear –
> >>
> >> NEW: Micro-loops that appear – or do not appear – as part of the
> >> distributed IGP convergence [RFC5715]
> >>
> >>
> >>
> >> Motivation: some reader could wrongly understand that such micro-loops
> are
> >> caused by TI-LFA
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Regards,
> >>
> >> --Bruno
> >>
> >>
> >>
> >> Orange

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

[Ahmed Bashandy]

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein 
 wrote:


Bruno,

Lots of thanks for a prompt and very encouraging response!

Your version of the text is definitely better than mine, I am all
for using it.

As for where the clarifying text could be inserted, I see two
options:

  * A common “Applicability Statement” section (there is no such
section in the draft)

 *


  * A dedicated section on relationship between TI-LFA and
micro-loops.

    Gyan> I think this option would  be best.  This would fix the
existing gap on uLoop.  I did mention but not sure if possible-
as TI-LFA and uLoop are tightly coupled as a overall post
convergence solution is it possible to combine the drafts and
issue another WGLC.  (Question for authors)

In any case, I defer to you and the rest of the authors to decide
what, if anything should be done for clarifying the relationship
between TI-LFA and micro-loops.

Regards,

Sasha

*From:* bruno.decra...@orange.com 
*Sent:* Monday, October 23, 2023 3:27 PM
*To:* Alexander Vainshtein 
*Cc:* rtgwg@ietf.org; rtgwg-chairs ;
    draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant
    
*Subject:* [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa
: A simple pathological network fragment

Sasha,

Thanks for the summary and the constructive proposal.

Speaking for myself, this makes sense and I agree.

Ø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:

oMicro-loops that appear – or do not appear –on the paths to the
destination that do not pass thru TI-LFA paths

As an editorial comment, depending on where such text would be
inserted, I would propose the following change:

OLD: Micro-loops that appear – or do not appear –

NEW: Micro-loops that appear – or do not appear – as part of the
distributed IGP convergence [RFC5715]

Motivation: some reader could wrongly understand that such
micro-loops are caused by TI-LFA

Thanks,

Regards,

--Bruno

Orange Restricted

*From:*Alexander Vainshtein 
*Sent:* Sunday, October 22, 2023 4:21 PM
*To:* DECRAENE Bruno INNOV/NET ;
Stewart Bryant 
    *Cc:* rtgwg@ietf.org; rtgwg-chairs ;
    draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
*Subject:* RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple
pathological network fragment
*Importance:* High

Bruno, Stewart and all,

I think that most of the things about TI-LFA and micro-loops have
been said already (if in a slightly different context)  and are
mainly self-evident.

However, I share the feeling that somehow the relationship
between TI-LFA and micro-loop avoidance has become somewhat muddled.

Therefore, I would like to suggest adding some text to the TI-LFA
draft that clarifies this relationship, e.g., along the following
lines:

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 –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

b.Micro-loops that appear – or do not appear - when the failed
link is repaired (/aside: the need for this line is based on
personal experience//☹/)

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:

a.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

b.The paths used in the micro-loop avoidance procedures typically
cann

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

Hi Stewart,

Please see inline [Bruno]



Orange Restricted
From: rtgwg  On Behalf Of Stewart Bryant
Sent: Friday, November 3, 2023 10:06 AM
To: Gyan Mishra 
Cc: draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg@ietf.org; 
rtgwg-chairs ; Alexander Vainshtein 

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



On 3 Nov 2023, at 02:43, Gyan Mishra 
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 
ano

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

[Ahmed Bashandy]

great

I'll change the wording accordingly

Ahmed

On 11/1/23 10:09 PM, Gyan Mishra wrote:

Hi Sasha, Bruno & Stewart

Thank you for going over my OPSDIR review in detail.

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:


Bruno,

Lots of thanks for a prompt and very encouraging response!



Your version of the text is definitely better than mine, I am all for
using it.



As for where the clarifying text could be inserted, I see two options:

- A common “Applicability Statement” section (there is no such section
in the draft)


-
- A dedicated section on relationship between TI-LFA and micro-loops.

 Gyan> I think this option would  be best.  This would fix the existing
gap on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop
are tightly coupled as a overall post convergence solution is it possible
to combine the drafts and issue another WGLC.  (Question for authors)

In any case, I defer to you and the rest of the authors to decide what, if
anything should be done for clarifying the relationship between TI-LFA and
micro-loops.





Regards,

Sasha



*From:* bruno.decra...@orange.com 
*Sent:* Monday, October 23, 2023 3:27 PM
*To:* Alexander Vainshtein 
*Cc:* rtgwg@ietf.org; rtgwg-chairs ;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant <
stewart.bry...@gmail.com>
*Subject:* [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A
simple pathological network fragment



Sasha,



Thanks for the summary and the constructive proposal.

Speaking for myself, this makes sense and I agree.



Ø  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:

o   Micro-loops that appear – or do not appear –on the paths to the
destination that do not pass thru TI-LFA paths



As an editorial comment, depending on where such text would be inserted, I
would propose the following change:

OLD: Micro-loops that appear – or do not appear –

NEW: Micro-loops that appear – or do not appear – as part of the
distributed IGP convergence [RFC5715]



Motivation: some reader could wrongly understand that such micro-loops are
caused by TI-LFA



Thanks,

Regards,

--Bruno



Orange Restricted

*From:* Alexander Vainshtein 
*Sent:* Sunday, October 22, 2023 4:21 PM
*To:* DECRAENE Bruno INNOV/NET ; Stewart
Bryant 
*Cc:* rtgwg@ietf.org; rtgwg-chairs ;
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
*Subject:* RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple
pathological network fragment
*Importance:* High



Bruno, Stewart and all,

I think that most of the things about TI-LFA and micro-loops have been
said already (if in a slightly different context)  and are mainly
self-evident.

However, I share the feeling that somehow the relationship between TI-LFA
and micro-loop avoidance has become somewhat muddled.



Therefore, I would like to suggest adding some text to the TI-LFA draft
that clarifies this relationship, e.g., along the following lines:

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 –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

b.   Micro-loops that appear – or do not appear - when the failed
link is repaired (*aside: the need for this line is based on personal
experience**☹*)

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:

a.   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

b.   The paths used in the micro-loop avoidance procedures typically
cannot be pre-computed.



Ho

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

[Gyan Mishra]

Hi Sasha

Welcome and thank you for all your detailed analysis and engagement on this
thread!

Responses in-line

On Sun, Nov 5, 2023 at 7:56 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Gyan,

Lots of thanks for your email.



I fully agree that TI-LFA draft should be published ASAP. Hopefully the
clarifications proposed by Bruno and myself would suffice for resolving
most of concerns regarding relationship between TI-LFA and micro-loops.

 Gyan> Agreed

I think what also should be added in the update is relationship between
TI-LFA post convergence path and use of minimum number of sids
prefix-sid/node sid, and issue with ECMP nature of prefix sid use in case
of a chain of nodes with cascading delays in convergence times that
requires uloop avoidance list of Adj-sid list in cases where the extended P
space for RLFA physical loop style topology is not converged and requires
tunneling over the chain of nodes. In the case where the post convergence
path is loop free then prefix-sid/node-sid ECMP is not an issue and am good
there.

For the interaction between TI-LFA and uLoop, for example -  TI-LFA applies
 a loop free policy along the post convergence path static sid list at time
T1, so at what time T2 does the uLoop kick in?  uLoop solution does not
have a pre programmed path as it’s built based on near or far side
tunneling post convergence path after the failure has occurred. So the only
time uLoop would kick is with uLoop detection of micro loops in the
topology which I think the uLoop or TI-LFA drafts  do not discuss.  Once
uLoops are found either in P or Q space for the RLFA then a policy with hop
by hop list of Sid’s is created for the SR policy from extended P to Q
space PQ node.  I don’t see either draft mentioning this detailed
interaction and sequence of events from failure to recovery on backup
path.  The key here is with uLoop avoidance as opposed to TI-LFA is that
TI-LFA is “not tunneled” as tunneling is not required as the post
convergence path is assumed to be loop free.  However, if not loop free
within the extended P space with chain of nodes with cascading convergence
delays then some sort of RFC 5715 near of far side tunneling needs to be
implemented to tunnel over all the nodes not converged.  So I think the
critical interaction here with TI-LFA and SR uLoop as opposed to RFC 7490
T-LDP based uLoop is that with when loops exist pre or post convergence
with traditional MPLS you specify a single FRR label and the traffic is
tunneled to the Q space, however with SR prefix/node-sid it’s ECMP, so no
tunneling and that is an issue.

In the uLoop draft figure 1 example it shows the RFC 5715 example of using
far side tunneling.  The reason for far side is by guess it scales better
but I think that far side solution is only applicable for traditional MPLS
where a single FRR label pushed yields a tunnel where with SR-MPLS
prefix/node-sid yields ECMP and thus no tunneling and so AFAIK far side
won’t work with SR-MPLS.  I think you have to use near side tunneling with
list of hop by hop Adj-sid.  I have not tested this in the lab but I don’t
think far side will work with SR when micro loops exist on the post
convergence path in a looped physical topology scenario with a chain of
nodes with convergence delays.  Distributed tunneling is the same as near
side so I think AFAIK due to ECMP issue with SR you have to use near side
tunneling for uLoop avoidance.

> The SR Micro-loop Avoidance draft indeed exists for 7+ years already and
> is quite stable. Unfortunately, stability also includes Section 3 of the
> draft that remains unchanged from 00 to -15 (current) version.
>
Gyan> Section 3, it’s mentioned that the policy is out of scope but I
think it should be in scope as the goal of TI-LFA is local protection which
includes recovery on the P space RLFA post convergence backup path and
uLoop invokes as well recovery along the extended P space to Q space PQ
node that includes all of the chain of cascading delayed convergence
nodes.  So I think that both TI-LFA and uLoop are involved in SR policy
based recovery process and AFAIK should be in scope  used for protected
convergence and recovery along the backup path.

>
> And in any case micro-loop avoidance includes the case of recovering
> links  while TI-LFA only deals with links failures.
>
> This alone looks to me a valid reason not to merge these drafts.
>
>
>
> My 2c,
>
> Sasha
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Friday, November 3, 2023 4:43 AM
> *To:* Alexander Vainshtein 
> *Cc:* bruno.decra...@orange.com;
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs <
> rtgwg-cha...@ietf.org>; rtgwg@ietf.org
> *Subject:* Re: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A
> simple pathological network fragment
>
>
>
> Hi Sasha
>
>
>
> In-line below
>
>
>
> On Thu, Nov 

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

[Alexander Vainshtein]

Gyan,
Lots of thanks for your email.

I fully agree that TI-LFA draft should be published ASAP. Hopefully the 
clarifications proposed by Bruno and myself would suffice for resolving most of 
concerns regarding relationship between TI-LFA and micro-loops.

The SR Micro-loop Avoidance draft indeed exists for 7+ years already and is 
quite stable. Unfortunately, stability also includes Section 3 of the draft 
that remains unchanged from 00 to -15 (current) version.

And in any case micro-loop avoidance includes the case of recovering links  
while TI-LFA only deals with links failures.
This alone looks to me a valid reason not to merge these drafts.

My 2c,
Sasha

From: Gyan Mishra 
Sent: Friday, November 3, 2023 4:43 AM
To: Alexander Vainshtein 
Cc: bruno.decra...@orange.com; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs 
; rtgwg@ietf.org
Subject: Re: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Hi Sasha

In-line below

On Thu, Nov 2, 2023 at 4:01 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Gyan and all,
Inline below.

Regards,
Sasha

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Thursday, November 2, 2023 7:09 AM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>;
 rtgwg-chairs mailto:rtgwg-cha...@ietf.org>>; 
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment


Hi Sasha, Bruno & Stewart

Thank you for going over my OPSDIR review in detail.

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Bruno,
Lots of thanks for a prompt and very encouraging response!

Your version of the text is definitely better than mine, I am all for using it.

As for where the clarifying text could be inserted, I see two options:

• A common “Applicability Statement” section (there is no such section in the 
draft)


•

• A dedicated section on relationship between TI-LFA and micro-loops.
Gyan> I think this option would  be best.  This would fix the existing gap 
on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop are 
tightly coupled as a overall post convergence solution is it possible to 
combine the drafts and issue another WGLC.  (Question for authors)
  [[Sasha]] Given the current state of the SR Micro-Loop Avoidance 
draft<https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>
 (still an individual submission at -15 version) I doubt merging TI-LFA and 
micro-loop avoidance is a good idea.
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-L

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

[Gyan Mishra]

Hi Sasha

In-line below

On Thu, Nov 2, 2023 at 4:01 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Gyan and all,
>
> *Inline below*.
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Thursday, November 2, 2023 7:09 AM
> *To:* Alexander Vainshtein 
> *Cc:* bruno.decra...@orange.com;
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs <
> rtgwg-cha...@ietf.org>; rtgwg@ietf.org
> *Subject:* [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A
> simple pathological network fragment
>
>
>
>
>
> Hi Sasha, Bruno & Stewart
>
>
>
> Thank you for going over my OPSDIR review in detail.
>
>
>
> I am good with the latest updated verbiage that Bruno had given.
>
>
>
> Comments in-line
>
>
>
> On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein <
> alexander.vainsht...@rbbn.com> wrote:
>
> Bruno,
>
> Lots of thanks for a prompt and very encouraging response!
>
>
>
> Your version of the text is definitely better than mine, I am all for
> using it.
>
>
>
> As for where the clarifying text could be inserted, I see two options:
>
> · A common “Applicability Statement” section (there is no such section in
> the draft)
>
>
>
> ·
>
> · A dedicated section on relationship between TI-LFA and micro-loops.
>
> Gyan> I think this option would  be best.  This would fix the existing
> gap on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop
> are tightly coupled as a overall post convergence solution is it possible
> to combine the drafts and issue another WGLC.  (Question for authors)
>
>   *[[Sasha]] Given the current state of the SR Micro-Loop
> Avoidance draft
> <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>
> (still an individual submission at -15 version) I doubt merging TI-LFA and
> micro-loop avoidance is a good idea.*
>
> 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

In any case, I defer to you and the rest of the authors to decide what, if
> anything should be done for clarifying the relationship between TI-LFA and
> micro-loops.
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* bruno.decra...@orange.com 
> *Sent:* Monday, October 23, 2023 3:27 PM
> *To:* Alexander Vainshtein 
> *Cc:* rtgwg@ietf.org; rtgwg-chairs ;
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant <
> stewart.bry...@gmail.com>
> *Subject:* [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A
> simple pathological network fra

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

[Alexander Vainshtein]

Gyan and all,
Inline below.

Regards,
Sasha

From: Gyan Mishra 
Sent: Thursday, November 2, 2023 7:09 AM
To: Alexander Vainshtein 
Cc: bruno.decra...@orange.com; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; rtgwg-chairs 
; rtgwg@ietf.org
Subject: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment


Hi Sasha, Bruno & Stewart

Thank you for going over my OPSDIR review in detail.

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Bruno,
Lots of thanks for a prompt and very encouraging response!

Your version of the text is definitely better than mine, I am all for using it.

As for where the clarifying text could be inserted, I see two options:

· A common “Applicability Statement” section (there is no such section in the 
draft)


·

· A dedicated section on relationship between TI-LFA and micro-loops.
Gyan> I think this option would  be best.  This would fix the existing gap 
on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop are 
tightly coupled as a overall post convergence solution is it possible to 
combine the drafts and issue another WGLC.  (Question for authors)
  [[Sasha]] Given the current state of the SR Micro-Loop Avoidance 
draft<https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>
 (still an individual submission at -15 version) I doubt merging TI-LFA and 
micro-loop avoidance is a good idea.
In any case, I defer to you and the rest of the authors to decide what, if 
anything should be done for clarifying the relationship between TI-LFA and 
micro-loops.


Regards,
Sasha

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Monday, October 23, 2023 3:27 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs 
mailto:rtgwg-cha...@ietf.org>>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>;
 Stewart Bryant mailto:stewart.bry...@gmail.com>>
Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Sasha,

Thanks for the summary and the constructive proposal.
Speaking for myself, this makes sense and I agree.


>  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:

o   Micro-loops that appear – or do not appear –on the paths to the destination 
that do not pass thru TI-LFA paths

As an editorial comment, depending on where such text would be inserted, I 
would propose the following change:
OLD: Micro-loops that appear – or do not appear –
NEW: Micro-loops that appear – or do not appear – as part of the distributed 
IGP convergence [RFC5715]

Motivation: some reader could wrongly understand that such micro-loops are 
caused by TI-LFA

Thanks,
Regards,
--Bruno


Orange Restricted
From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Sunday, October 22, 2023 4:21 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Stewart Bryant 
mailto:stewart.bry...@gmail.com>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs 
mailto:rtgwg-cha...@ietf.org>>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>
Subject: RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment
Importance: High

Bruno, Stewart and all,
I think that most of the things about TI-LFA and micro-loops have been said 
already (if in a slightly different context)  and are mainly self-evident.
However, I share the feeling that somehow the relationship between TI-LFA and 
micro-loop avoidance has become somewhat muddled.

Therefore, I would like to suggest adding some text to the TI-LFA draft that 
clarifies this relationship, e.g., along the following lines:

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 –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

b.   Micro-loops that appear – or do not appear - when the failed li

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

[Alexander Vainshtein]

Stewart and all,
Please see some comments inline below.

Regards,
Sasha

From: Stewart Bryant 
Sent: Thursday, November 2, 2023 9:30 AM
To: Gyan Mishra 
Cc: Stewart Bryant ; Alexander Vainshtein 
; rtgwg@ietf.org; rtgwg-chairs 
; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Subject: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Let me ask a fundamental question.

The whole point of Ti-LFA as sold to the community was that repairing along the 
post convergence path as opposed to repairing along a convenient temporary path 
avoided micro loops.
[[Sasha]] To the best of my understanding, repairing along the post-convergence 
path prevents micro-loops on these paths due to distributed IGP convergence – 
as long as traffic follows these paths.  It does not – and, obviously, cannot, 
have any impact on micro-loops happening elsewhere due to distributed IGP 
convergence – neither prevents micro-loops that would form without TI-LFA, nor 
introduces any new ones.
The repair path constraint and subsequent segment optimisations add complexity 
to the calculation of the path.

Are we are now saying that micro loops can form elsewhere and as a consequence 
we need a micro loop avoidance strategy?
[[Sasha]] TI-LFA, same as any other form of LFA that I am aware of, handles 
just link/node failures.  Micro-loops can happen – and, from my experience, 
frequently DO happen – during repair of a failed link/node.  IMHO and FWIW this 
alone justifies the need for the micro-loop avoiding strategy/solution.

If so the fundamental premise behind TiLFA is broken and the repair can simply 
become: use SR to expeditiously route the packets into Q space and run a micro 
loop avoidance strategy. This approach removes the complexity of constraining 
the repair to the post convergence path. [[Sasha]] Please see my previous 
comment about TI-LFA paths being micro-loop avoidant because they are 
post-convergence paths.  In other words, one possible micro-loop avoidance 
strategy is usage of post-convergence paths in the transient period – and this, 
in a nutshell, is what the SR Micro-Loop Avoidance 
draft<https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>
 is about (no offence intended).

Of course an implementor could cheat and just used the simplified strategy I 
describe above and almost certainly very few operators would notice because:

1) In many cases the two paths would be congruent

2) The transient is short and quite difficult to instrument

3) Unless there was some security reason or traffic management reason for the 
path constraint few would care.

I will look at the proposed differences later, but this sounds like it should 
be a topic for discussion in RTGWG before the text is finalised and sent the 
RFC editor.
[[Sasha]] The RTGWG agenda at 
IETF-118<https://datatracker.ietf.org/meeting/118/materials/agenda-118-rtgwg-02>
 seems tightly packed already. I wonder if a side meeting for such a discussion 
could be set in a way that allows online participation?

- Stewart


On 2 Nov 2023, at 05:09, Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


Hi Sasha, Bruno & Stewart

Thank you for going over my OPSDIR review in detail.

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>> wrote:
Bruno,
Lots of thanks for a prompt and very encouraging response!

Your version of the text is definitely better than mine, I am all for using it.

As for where the clarifying text could be inserted, I see two options:

·   A common “Applicability Statement” section (there is no such section in 
the draft)


·

·   A dedicated section on relationship between TI-LFA and micro-loops.
Gyan> I think this option would  be best.  This would fix the existing gap 
on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop are 
tightly coupled as a overall post convergence solution is it possible to 
combine the drafts and issue another WGLC.  (Question for authors)
In any case, I defer to you and the rest of the authors to decide what, if 
anything should be done for clarifying the relationship between TI-LFA and 
micro-loops.


Regards,
Sasha

From: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com> 
mailto:bruno.decra...@orange.com>>
Sent: Monday, October 23, 2023 3:27 PM
To: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs 
mailto:rtgwg-cha...@ietf.org>>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>;
 Stewart Bryant mailto:stewart.bry...@gmail.com>>
Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Sasha,

Thanks for the summary and the constructive

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

[Stewart Bryant]

Let me ask a fundamental question.

The whole point of Ti-LFA as sold to the community was that repairing along the 
post convergence path as opposed to repairing along a convenient temporary path 
avoided micro loops. The repair path constraint and subsequent segment 
optimisations add complexity to the calculation of the path.

Are we are now saying that micro loops can form elsewhere and as a consequence 
we need a micro loop avoidance strategy?

If so the fundamental premise behind TiLFA is broken and the repair can simply 
become: use SR to expeditiously route the packets into Q space and run a micro 
loop avoidance strategy. This approach removes the complexity of constraining 
the repair to the post convergence path.

Of course an implementor could cheat and just used the simplified strategy I 
describe above and almost certainly very few operators would notice because:

1) In many cases the two paths would be congruent

2) The transient is short and quite difficult to instrument

3) Unless there was some security reason or traffic management reason for the 
path constraint few would care.

I will look at the proposed differences later, but this sounds like it should 
be a topic for discussion in RTGWG before the text is finalised and sent the 
RFC editor.

- Stewart

> On 2 Nov 2023, at 05:09, Gyan Mishra  wrote:
> 
> 
> Hi Sasha, Bruno & Stewart 
> 
> Thank you for going over my OPSDIR review in detail.
> 
> I am good with the latest updated verbiage that Bruno had given.
> 
> Comments in-line 
> 
> On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein 
> mailto:alexander.vainsht...@rbbn.com>> wrote:
>> Bruno,
>> 
>> Lots of thanks for a prompt and very encouraging response!
>> 
>>  
>> 
>> Your version of the text is definitely better than mine, I am all for using 
>> it.
>> 
>>  
>> 
>> As for where the clarifying text could be inserted, I see two options:
>> 
>> A common “Applicability Statement” section (there is no such section in the 
>> draft)
>
>> A dedicated section on relationship between TI-LFA and micro-loops.
>> Gyan> I think this option would  be best.  This would fix the existing 
>> gap on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop 
>> are tightly coupled as a overall post convergence solution is it possible to 
>> combine the drafts and issue another WGLC.  (Question for authors)
>> 
>> In any case, I defer to you and the rest of the authors to decide what, if 
>> anything should be done for clarifying the relationship between TI-LFA and 
>> micro-loops.
>> 
>>  
>> 
>>  
>> 
>> Regards,
>> 
>> Sasha
>> 
>>  
>> 
>> From: bruno.decra...@orange.com <mailto:bruno.decra...@orange.com> 
>> mailto:bruno.decra...@orange.com>> 
>> Sent: Monday, October 23, 2023 3:27 PM
>> To: Alexander Vainshtein > <mailto:alexander.vainsht...@rbbn.com>>
>> Cc: rtgwg@ietf.org <mailto:rtgwg@ietf.org>; rtgwg-chairs 
>> mailto:rtgwg-cha...@ietf.org>>; 
>> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org 
>> <mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>; Stewart Bryant 
>> mailto:stewart.bry...@gmail.com>>
>> Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
>> pathological network fragment
>> 
>>  
>> 
>> Sasha,
>> 
>>  
>> 
>> Thanks for the summary and the constructive proposal.
>> 
>> Speaking for myself, this makes sense and I agree.
>> 
>>  
>> 
>> Ø  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:
>> 
>> o   Micro-loops that appear – or do not appear –on the paths to the 
>> destination that do not pass thru TI-LFA paths
>> 
>>  
>> 
>> As an editorial comment, depending on where such text would be inserted, I 
>> would propose the following change:
>> 
>> OLD: Micro-loops that appear – or do not appear –
>> 
>> NEW: Micro-loops that appear – or do not appear – as part of the distributed 
>> IGP convergence [RFC5715]
>> 
>>  
>> 
>> Motivation: some reader could wrongly understand that such micro-loops are 
>> caused by TI-LFA
>> 
>>  
>> 
>> Thanks,
>> 
>> Regards,
>> 
>> --Bruno
>> 
>>  
>> 
>> Orange Restricted
>> From: Alexander Vainshtein > <mailto:alexander.vainsht...@rbbn.com>> 
>> Sent: Sunday, October 22, 2023 4:21 PM
>> To: DECRAENE Bruno INNOV/NET > <mailto:brun

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

[Gyan Mishra]

Hi Sasha, Bruno & Stewart

Thank you for going over my OPSDIR review in detail.

I am good with the latest updated verbiage that Bruno had given.

Comments in-line

On Mon, Oct 23, 2023 at 8:41 AM Alexander Vainshtein <
alexander.vainsht...@rbbn.com> wrote:

> Bruno,
>
> Lots of thanks for a prompt and very encouraging response!
>
>
>
> Your version of the text is definitely better than mine, I am all for
> using it.
>
>
>
> As for where the clarifying text could be inserted, I see two options:
>
>- A common “Applicability Statement” section (there is no such section
>in the draft)
>
>

>
>-
>- A dedicated section on relationship between TI-LFA and micro-loops.
>
> Gyan> I think this option would  be best.  This would fix the existing
> gap on uLoop.  I did mention but not sure if possible- as TI-LFA and uLoop
> are tightly coupled as a overall post convergence solution is it possible
> to combine the drafts and issue another WGLC.  (Question for authors)
>
> In any case, I defer to you and the rest of the authors to decide what, if
> anything should be done for clarifying the relationship between TI-LFA and
> micro-loops.
>
>
>
>
>
> Regards,
>
> Sasha
>
>
>
> *From:* bruno.decra...@orange.com 
> *Sent:* Monday, October 23, 2023 3:27 PM
> *To:* Alexander Vainshtein 
> *Cc:* rtgwg@ietf.org; rtgwg-chairs ;
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant <
> stewart.bry...@gmail.com>
> *Subject:* [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A
> simple pathological network fragment
>
>
>
> Sasha,
>
>
>
> Thanks for the summary and the constructive proposal.
>
> Speaking for myself, this makes sense and I agree.
>
>
>
> Ø  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:
>
> o   Micro-loops that appear – or do not appear –on the paths to the
> destination that do not pass thru TI-LFA paths
>
>
>
> As an editorial comment, depending on where such text would be inserted, I
> would propose the following change:
>
> OLD: Micro-loops that appear – or do not appear –
>
> NEW: Micro-loops that appear – or do not appear – as part of the
> distributed IGP convergence [RFC5715]
>
>
>
> Motivation: some reader could wrongly understand that such micro-loops are
> caused by TI-LFA
>
>
>
> Thanks,
>
> Regards,
>
> --Bruno
>
>
>
> Orange Restricted
>
> *From:* Alexander Vainshtein 
> *Sent:* Sunday, October 22, 2023 4:21 PM
> *To:* DECRAENE Bruno INNOV/NET ; Stewart
> Bryant 
> *Cc:* rtgwg@ietf.org; rtgwg-chairs ;
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
> *Subject:* RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple
> pathological network fragment
> *Importance:* High
>
>
>
> Bruno, Stewart and all,
>
> I think that most of the things about TI-LFA and micro-loops have been
> said already (if in a slightly different context)  and are mainly
> self-evident.
>
> However, I share the feeling that somehow the relationship between TI-LFA
> and micro-loop avoidance has become somewhat muddled.
>
>
>
> Therefore, I would like to suggest adding some text to the TI-LFA draft
> that clarifies this relationship, e.g., along the following lines:
>
> 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 –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
>
> b.   Micro-loops that appear – or do not appear - when the failed
> link is repaired (*aside: the need for this line is based on personal
> experience**☹*)
>
> 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 

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[Alexander Vainshtein]

Bruno,
Lots of thanks for a prompt and very encouraging response!

Your version of the text is definitely better than mine, I am all for using it.

As for where the clarifying text could be inserted, I see two options:

  *   A common “Applicability Statement” section (there is no such section in 
the draft)
  *   A dedicated section on relationship between TI-LFA and micro-loops.

In any case, I defer to you and the rest of the authors to decide what, if 
anything should be done for clarifying the relationship between TI-LFA and 
micro-loops.


Regards,
Sasha

From: bruno.decra...@orange.com 
Sent: Monday, October 23, 2023 3:27 PM
To: Alexander Vainshtein 
Cc: rtgwg@ietf.org; rtgwg-chairs ; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org; Stewart Bryant 

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

Sasha,

Thanks for the summary and the constructive proposal.
Speaking for myself, this makes sense and I agree.


Ø  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:

o   Micro-loops that appear – or do not appear –on the paths to the destination 
that do not pass thru TI-LFA paths

As an editorial comment, depending on where such text would be inserted, I 
would propose the following change:
OLD: Micro-loops that appear – or do not appear –
NEW: Micro-loops that appear – or do not appear – as part of the distributed 
IGP convergence [RFC5715]

Motivation: some reader could wrongly understand that such micro-loops are 
caused by TI-LFA

Thanks,
Regards,
--Bruno


Orange Restricted
From: Alexander Vainshtein 
mailto:alexander.vainsht...@rbbn.com>>
Sent: Sunday, October 22, 2023 4:21 PM
To: DECRAENE Bruno INNOV/NET 
mailto:bruno.decra...@orange.com>>; Stewart Bryant 
mailto:stewart.bry...@gmail.com>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs 
mailto:rtgwg-cha...@ietf.org>>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>
Subject: RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment
Importance: High

Bruno, Stewart and all,
I think that most of the things about TI-LFA and micro-loops have been said 
already (if in a slightly different context)  and are mainly self-evident.
However, I share the feeling that somehow the relationship between TI-LFA and 
micro-loop avoidance has become somewhat muddled.

Therefore, I would like to suggest adding some text to the TI-LFA draft that 
clarifies this relationship, e.g., along the following lines:

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 –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

b.   Micro-loops that appear – or do not appear - when the failed link is 
repaired (aside: the need for this line is based on personal experience☹)

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:

a.   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

b.   The paths used in the micro-loop avoidance procedures typically cannot 
be pre-computed.

Hopefully these notes would be useful.

Regards,
Sasha

From: rtgwg mailto:rtgwg-boun...@ietf.org>> On Behalf 
Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, October 19, 2023 7:34 PM
To: Stewart Bryant mailto:stewart.br

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

Sasha,

Thanks for the summary and the constructive proposal.
Speaking for myself, this makes sense and I agree.


  *   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 –on the paths to the 
destination that do not pass thru TI-LFA paths

As an editorial comment, depending on where such text would be inserted, I 
would propose the following change:
OLD: Micro-loops that appear – or do not appear –
NEW: Micro-loops that appear – or do not appear – as part of the distributed 
IGP convergence [RFC5715]

Motivation: some reader could wrongly understand that such micro-loops are 
caused by TI-LFA

Thanks,
Regards,
--Bruno


Orange Restricted
From: Alexander Vainshtein 
Sent: Sunday, October 22, 2023 4:21 PM
To: DECRAENE Bruno INNOV/NET ; Stewart Bryant 

Cc: rtgwg@ietf.org; rtgwg-chairs ; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Subject: RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment
Importance: High

Bruno, Stewart and all,
I think that most of the things about TI-LFA and micro-loops have been said 
already (if in a slightly different context)  and are mainly self-evident.
However, I share the feeling that somehow the relationship between TI-LFA and 
micro-loop avoidance has become somewhat muddled.

Therefore, I would like to suggest adding some text to the TI-LFA draft that 
clarifies this relationship, e.g., along the following lines:

  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 –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

b.   Micro-loops that appear – or do not appear - when the failed link is 
repaired (aside: the need for this line is based on personal experience☹)

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:

a.   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

b.   The paths used in the micro-loop avoidance procedures typically cannot 
be pre-computed.

Hopefully these notes would be useful.

Regards,
Sasha

From: rtgwg mailto:rtgwg-boun...@ietf.org>> On Behalf 
Of bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>
Sent: Thursday, October 19, 2023 7:34 PM
To: Stewart Bryant mailto:stewart.bry...@gmail.com>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; rtgwg-chairs 
mailto:rtgwg-cha...@ietf.org>>; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org<mailto:draft-ietf-rtgwg-segment-routing-ti-...@ietf.org>
Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Hi Stewart,

I agree with you on the technical points, so the first part of your email up to 
“So I think”.

But I don’t quite follow why you want to mix IGP Convergence issues with this 
Fast ReRoute Solution.

To quote RFC 5714 « IP Fast Reroute Framework”


In order to reduce packet disruption times to a duration commensurate
   with the failure detection times, two mechanisms may be required:

   a.  A mechanism for the router(s) adjacent to the failure to rapidly
   invoke a repair path, which is unaffected by any subsequent re-
   convergence.

   b.  In topologies that are susceptible to micro-loops, a micro-loop
   control mechanism may be required 
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>].

   Performing the first task without the second may result in the repair
   path being st

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[Alexander Vainshtein]

Bruno, Stewart and all,
I think that most of the things about TI-LFA and micro-loops have been said 
already (if in a slightly different context)  and are mainly self-evident.
However, I share the feeling that somehow the relationship between TI-LFA and 
micro-loop avoidance has become somewhat muddled.

Therefore, I would like to suggest adding some text to the TI-LFA draft that 
clarifies this relationship, e.g., along the following lines:

  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:
 *   Micro-loops that appear – or do not appear –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

 *   Micro-loops that appear – or do not appear - when the failed link is 
repaired (aside: the need for this line is based on personal experience☹)
  1.  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
  2.  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).
  3.  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.

Hopefully these notes would be useful.

Regards,
Sasha

From: rtgwg  On Behalf Of bruno.decra...@orange.com
Sent: Thursday, October 19, 2023 7:34 PM
To: Stewart Bryant 
Cc: rtgwg@ietf.org; rtgwg-chairs ; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Subject: [EXTERNAL] RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple 
pathological network fragment

Hi Stewart,

I agree with you on the technical points, so the first part of your email up to 
“So I think”.

But I don’t quite follow why you want to mix IGP Convergence issues with this 
Fast ReRoute Solution.

To quote RFC 5714 « IP Fast Reroute Framework”


In order to reduce packet disruption times to a duration commensurate
   with the failure detection times, two mechanisms may be required:

   a.  A mechanism for the router(s) adjacent to the failure to rapidly
   invoke a repair path, which is unaffected by any subsequent re-
   convergence.

   b.  In topologies that are susceptible to micro-loops, a micro-loop
   control mechanism may be required 
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>].

   Performing the first task without the second may result in the repair
   path being starved of traffic and hence being redundant.



https://datatracker.ietf.org/doc/html/rfc5714#section-4<https://datatracker.ietf.org/doc/html/rfc5714#section-4>



I would assume that you agree with the above (as you are an author of this RFC 
and my guess would be that you wrote that text)



My point is that there are two different mechanisms involved, in two different 
time periods:

-Fast ReRoute (“a”): this is the scope of 
draft-ietf-rtgwg-segment-routing-ti-lfa

o   Timing: from detection time , to start of the IGP convergence

-IGP Micro-loop avoidance (“b”)

o   Timing: from start of IGP convergence to end of IGP convergence

The scope of draft-ietf-rtgwg-segment-routing-ti-lfa is FRR / “a”. IGP 
micro-loop is out of scope. Other documents are proposing solutions for this. 
(and for those Micro-loop documents, FRR is similarly out of scope).

Personally I agree with you that both mechanisms are needed. But I think that 
this is already highlighted in RFC 5714, and that this is no different than RFC 
7490 (RLFA). Therefore, I don’t see why the outcome/text should be different. 
Hence my proposition to reuse the text from RFC 7490 (RLFA). I find it 
adequate. You wrote it so probably find it adequate.


On a side note, RFC5715, that you also wrote, seems to already cover what you 
are asking for. Quoting the abstract, it

  provides a summary o

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

Hi Stewart,

I agree with you on the technical points, so the first part of your email up to 
"So I think".

But I don't quite follow why you want to mix IGP Convergence issues with this 
Fast ReRoute Solution.

To quote RFC 5714 < IP Fast Reroute Framework"


In order to reduce packet disruption times to a duration commensurate
   with the failure detection times, two mechanisms may be required:

   a.  A mechanism for the router(s) adjacent to the failure to rapidly
   invoke a repair path, which is unaffected by any subsequent re-
   convergence.

   b.  In topologies that are susceptible to micro-loops, a micro-loop
   control mechanism may be required 
[RFC5715<https://datatracker.ietf.org/doc/html/rfc5715>].

   Performing the first task without the second may result in the repair
   path being starved of traffic and hence being redundant.



https://datatracker.ietf.org/doc/html/rfc5714#section-4



I would assume that you agree with the above (as you are an author of this RFC 
and my guess would be that you wrote that text)



My point is that there are two different mechanisms involved, in two different 
time periods:

-   Fast ReRoute ("a"): this is the scope of 
draft-ietf-rtgwg-segment-routing-ti-lfa

oTiming: from detection time , to start of the IGP convergence

-   IGP Micro-loop avoidance ("b")

oTiming: from start of IGP convergence to end of IGP convergence

The scope of draft-ietf-rtgwg-segment-routing-ti-lfa is FRR / "a". IGP 
micro-loop is out of scope. Other documents are proposing solutions for this. 
(and for those Micro-loop documents, FRR is similarly out of scope).

Personally I agree with you that both mechanisms are needed. But I think that 
this is already highlighted in RFC 5714, and that this is no different than RFC 
7490 (RLFA). Therefore, I don't see why the outcome/text should be different. 
Hence my proposition to reuse the text from RFC 7490 (RLFA). I find it 
adequate. You wrote it so probably find it adequate.


On a side note, RFC5715, that you also wrote, seems to already cover what you 
are asking for. Quoting the abstract, it

  provides a summary of the causes and consequences of
   micro-loops and enables the reader to form a judgement on whether
   micro-looping is an issue that needs to be addressed in specific
   networks.

Note that this RFC5715 is already cited in the proposed text.

PS: If you were ready to wrote a 5715bis, I would support this.

Best regards,
--Bruno



Orange Restricted
From: Stewart Bryant 
Sent: Tuesday, October 17, 2023 1:48 PM
To: DECRAENE Bruno INNOV/NET 
Cc: Stewart Bryant ; rtgwg@ietf.org; rtgwg-chairs 
; draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Subject: Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment

Hi Bruno

I was thinking about this some more. It is something that was recognised in the 
early days, but somewhat swept aside.

The case that Gyan bought up was an ECMP case, but I fear that the case is more 
common and I think we should characterise it as part of the text rather that 
giving the impression it is unusual.

I think the problem occurs whenever there are two or more nodes between the 
point of packet entry and the failure.

CE1 - R1 - R2 - R3 - R4 -/- R5 - CE2
  | |
  R6 - R7 - R8 - R9 - R10

The normal path CE1-CE2 is via R2

When R4-R5 fails it is trivial to see how the repair works with R7 as the entry 
into Q space.

However unless R1, R2,  R3 converge in that order there will be microloops for 
traffic entering via any of those three nodes.

So I think we can say that unless the PLR is only receiving traffic to be 
protected directly or from its immediate neighbour it is not guaranteed that 
there  will not be micro loops that are not addressable by the propose strategy 
of aligning the repair path with the post convergence path.

Now thinking about the text you have below, I think we need to write in in 
terms of - Unless the operator is certain that no micro loops will form over 
any path the protected traffic will traverse between entry to the network and 
arrival at the PLR a micro loop avoidance method MUST be deployed. Of course I 
think that it would be helpful to the operator community for the text to 
provide some guidance on how to ascertain whether there is a danger of the 
formation of micro loops.

I would note that the long chains of nodes show in the example above were 
probably not present in the test topologies which as I remember were all 
national scale provider networks, but unless we provide guidance otherwise 
Ti-LFA could reasonably be deployed in edge networks and in the case of cell 
systems these are often ring topologies.

So I think we need to agree (as a WG) on the constrains that we are prepared to 
specify in the text and the degree of warning we need to provide to the 
operator community and then we can polish the text b

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

[Stewart Bryant]

Hi Bruno

I was thinking about this some more. It is something that was recognised in the 
early days, but somewhat swept aside.

The case that Gyan bought up was an ECMP case, but I fear that the case is more 
common and I think we should characterise it as part of the text rather that 
giving the impression it is unusual.

I think the problem occurs whenever there are two or more nodes between the 
point of packet entry and the failure.

CE1 - R1 - R2 - R3 - R4 -/- R5 - CE2
  | |
  R6 - R7 - R8 - R9 — R10

The normal path CE1-CE2 is via R2

When R4-R5 fails it is trivial to see how the repair works with R7 as the entry 
into Q space.

However unless R1, R2,  R3 converge in that order there will be microloops for 
traffic entering via any of those three nodes.

So I think we can say that unless the PLR is only receiving traffic to be 
protected directly or from its immediate neighbour it is not guaranteed that 
there  will not be micro loops that are not addressable by the propose strategy 
of aligning the repair path with the post convergence path.

Now thinking about the text you have below, I think we need to write in in 
terms of - Unless the operator is certain that no micro loops will form over 
any path the protected traffic will traverse between entry to the network and 
arrival at the PLR a micro loop avoidance method MUST be deployed. Of course I 
think that it would be helpful to the operator community for the text to 
provide some guidance on how to ascertain whether there is a danger of the 
formation of micro loops.

I would note that the long chains of nodes show in the example above were 
probably not present in the test topologies which as I remember were all 
national scale provider networks, but unless we provide guidance otherwise 
Ti-LFA could reasonably be deployed in edge networks and in the case of cell 
systems these are often ring topologies.

So I think we need to agree (as a WG) on the constrains that we are prepared to 
specify in the text and the degree of warning we need to provide to the 
operator community and then we can polish the text below.

Best regards

Stewart




> On 16 Oct 2023, at 17:25, bruno.decra...@orange.com wrote:
> 
> Hi Stewart,
>  
> Please see inline
>  
>  
> Orange Restricted
> From: Stewart Bryant  >
> Sent: Monday, October 16, 2023 2:08 PM
> To: rtgwg@ietf.org ; rtgwg-chairs 
> mailto:rtgwg-cha...@ietf.org>>; 
> draft-ietf-rtgwg-segment-routing-ti-...@ietf.org 
> 
> Cc: Stewart Bryant  >
> Subject: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
> network fragment
>  
> During the operations directorate early review of 
> draft-ietf-rtgwg-segment-routing-ti-lfa 
> Gyan Mishra points to a simple pathological network fragment that I think 
> deserves wider discussion.
>  
> https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25/
>  
> I am not aware of any response to the RTGWG by the draft authors concerning 
> the review comment and I cannot see obvious new text addressing this concern.
> 
> The fragment is as follows
> 
> CE1 –R1- R2-/-R3-CE2
>  | |
>  R4 – R5 -R6
> 
> In the pre converged network R4 is ECMP CE2 via R5 (cost 4) and via R1 (cost 
> also 4).
> 
> We can easily build a TI-LFA repair path from R2 under link failure to CE2 
> (so long as we remember that R4 is an ECMP path to CE2), but the problem 
> occurs during convergence. If R1 converges before R4, R4 may ECMP packets 
> addressed to CE2 back to R1 in a micro loop. Meanwhile since no packets for 
> R3 are reaching R2 the Ti-LFA repair is not doing anything useful. 
> 
> The Ti-LFA text leads the reader to conclude that it is a loop-free solution, 
> but gives no guidance on how to determine when this assumption breaks down. 
> There is an informational reference to 
> draft-bashandy-rtgwg-segment-routing-uloop, but this short individual draft 
> does little in the way of helping the reader determine when  loop avoidance 
> strategy needs to be deployed and the loop-free approach it describes does 
> not seem to be fully developed.
>  
> I am worried that proceeding with the Ti-LFA draft without noting that there 
> is a real risk that simple network fragments can micoloop, and providing a 
> fully formed mitigation strategy is a disservice to the operator community 
> given the industry interest in Ti-LDA and the insidious nature of unexpected 
> micro loop network transients, I am wondering what the view of the working 
> group is on how to proceed.
>  
> One approach would be for the Ti-LFA draft to incorporate detailed guidance 
> on how to determine the risk of a micro loop in a specific operator network, 
> and to provide specific mitigation advice. Another approach would be to  
> reference a developed loop avoidance 

RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment

[bruno . decraene]

Hi Stewart,

Please see inline



Orange Restricted
From: Stewart Bryant 
Sent: Monday, October 16, 2023 2:08 PM
To: rtgwg@ietf.org; rtgwg-chairs ; 
draft-ietf-rtgwg-segment-routing-ti-...@ietf.org
Cc: Stewart Bryant 
Subject: draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological 
network fragment

During the operations directorate early review of 
draft-ietf-rtgwg-segment-routing-ti-lfa
Gyan Mishra points to a simple pathological network fragment that I think 
deserves wider discussion.

https://datatracker.ietf.org/doc/review-ietf-rtgwg-segment-routing-ti-lfa-11-opsdir-early-mishra-2023-08-25/

I am not aware of any response to the RTGWG by the draft authors concerning the 
review comment and I cannot see obvious new text addressing this concern.

The fragment is as follows

CE1 -R1- R2-/-R3-CE2
 | |
 R4 - R5 -R6

In the pre converged network R4 is ECMP CE2 via R5 (cost 4) and via R1 (cost 
also 4).

We can easily build a TI-LFA repair path from R2 under link failure to CE2 (so 
long as we remember that R4 is an ECMP path to CE2), but the problem occurs 
during convergence. If R1 converges before R4, R4 may ECMP packets addressed to 
CE2 back to R1 in a micro loop. Meanwhile since no packets for R3 are reaching 
R2 the Ti-LFA repair is not doing anything useful.

The Ti-LFA text leads the reader to conclude that it is a loop-free solution, 
but gives no guidance on how to determine when this assumption breaks down. 
There is an informational reference to
draft-bashandy-rtgwg-segment-routing-uloop, but this short individual draft 
does little in the way of helping the reader determine when  loop avoidance 
strategy needs to be deployed and the loop-free approach it describes does not 
seem to be fully developed.

I am worried that proceeding with the Ti-LFA draft without noting that there is 
a real risk that simple network fragments can micoloop, and providing a fully 
formed mitigation strategy is a disservice to the operator community given the 
industry interest in Ti-LDA and the insidious nature of unexpected micro loop 
network transients, I am wondering what the view of the working group is on how 
to proceed.

One approach would be for the Ti-LFA draft to incorporate detailed guidance on 
how to determine the risk of a micro loop in a specific operator network, and 
to provide specific mitigation advice. Another approach would be to  reference 
a developed loop avoidance strategy and recommending its preemptive deployment. 
Another approach would be to make draft-bashandy-rtgwg-segment-routing-uloop a 
normative reference and tie the fate of the two drafts. Another approach would 
be to elaborate on the risks and their manifestations but declare it a 
currently unsolved problem. I am sure there are other options that the WG may 
formulate.

What is the opinion of the working group on how we should proceed with 
draft-ietf-rtgwg-segment-routing-ti-lfa when considering the possible formation 
of micro loops?

FRR takes place between the failure (detection) and the IGP reconvergence. 
Those are two consecutive steps that the WG has so far addressed with different 
solutions and documents.
That's not new and that's not specific to TI-LFA. E.g., that's applicable to 
RLFA.

Would the below text, taken verbatim from RFC 7490 (RLFA), work for you? Or 
would you say that the text is not good enough?

"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], or

   
[ULOOP-DELAY], 
should be implemented."

https://datatracker.ietf.org/doc/html/rfc7490#section-10

Of course, we could update the list of informative references.
E.g., by adding another informative reference to 
draft-bashandy-rtgwg-segment-routing-uloop and by removing informative 
references to [RFC6976] and [ULOOP-DELAY] which are probably outdated.

--Bruno


- 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