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

[Ahmed Bashandy <[e-mail]>]

17:00-18:00 Prague time, correct?

Ahmed


On 11/7/23 1:33 AM, Yingzhen Qu wrote:
> Wednesday (11/8) 17:00-18:00, Location: Palmovka 1/2
> Webex Link:
> https://ietf.webex.com/meet/sidemeetingietf2
>
> On Tue, Nov 7, 2023 at 1:30 AM Ahmed Bashandy 
> <[e-mail]> wrote:
>
>     I looked through the various replies and I was not able to find
>     the time slot or the webex link
>
>     But I am assuming it will be shortly after Session I on Wednesday.
>     This way we do not miss Session II, or at least only miss the
>     first few minutes
>
>
>     Ahmed
>
>
>     On 11/7/23 12:42 AM, Yingzhen Qu wrote:
>>     Hi Ahmed,
>>
>>     We'll have webex link, so it's about your availability.
>>
>>     Thanks,
>>     Yingzhen
>>
>>     On Tue, Nov 7, 2023 at 12:33 AM Ahmed Bashandy
>>     <[e-mail]> wrote:
>>
>>         I had to convert my attendance to remote due to family issues
>>         late last week. So I am not onsite
>>
>>
>>         Ahmed
>>
>>
>>         On 11/2/23 9:34 AM, Yingzhen Qu wrote:
>>>         Hi,
>>>
>>>         The ti-lfa draft has not done WGLC yet, and we should
>>>         definitely try to resolve this issue.
>>>
>>>         I just checked the IETF 118 attendees list, and it seems not
>>>         everyone will be onsite. I'd suggest continuing the
>>>         discussion using this thread, and we can schedule either a
>>>         side meeting during 118 or an Interim meeting on this topic
>>>         after 118. Authors from both the ti-lfa and sr-uloop,
>>>         Stewart, Sasha, and Gyan should be there.
>>>
>>>         Please reply with your thoughts or email the chairs directly.
>>>
>>>         Thanks,
>>>         Yingzhen
>>>
>>>         On Thu, Nov 2, 2023 at 8:45 AM Stewart Bryant
>>>         <[e-mail]> wrote:
>>>
>>>             Sasha, please see inline
>>>
>>>>             On 2 Nov 2023, at 14:12, Alexander Vainshtein
>>>>             <[e-mail]> wrote:
>>>>
>>>>             Stewart and all,
>>>>             I think I understand now the difference betweenSection
>>>>             6.2 of RFC 5715
>>>>             <https://www.rfc-editor.org/rfc/rfc5715#section-6.2>and
>>>>             theSR Micro-Loop Avoidance
>>>>             <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>draft
>>>>             – or, rather, common expectations from this draft.
>>>>             RFC 5715 has been published in 2010. With the tunneling
>>>>             techniques available at that time in the industry I
>>>>             suspect that “tunnels whose path is not affected by the
>>>>             topology change”  in this section have been implicitly
>>>>             presumed to be RSVP-TE tunnels – simply because no
>>>>             other tunneling technology was available at that time
>>>>             (I do not think that source routing in IP has been
>>>>             seriously considered).
>>>
>>>             Nearside tunnelling does not need RSVP. Any ingress that
>>>             will use the PLR to deliver a packet via the failed link
>>>             will always be able to reach the PLR since it is on the
>>>             nearside of the failure, so all you need to do is to
>>>             push a label that is associated with the PLR router and
>>>             the packet will get to the PLR where it will be popped
>>>             to reveal the label associated with an entity reachable
>>>             via the failed link which them triggers a repair action
>>>             on that packet. I cannot remember if we wrote that down,
>>>             but as I remember we considered it obvious at the time.
>>>             This needs no signalling beyond the normal normal IGP
>>>             and MPLS LDP.
>>>
>>>
>>>>             The context of the SR Micro-Loop Avoidance draft is
>>>>             Segment Routing, and RSVP-TE is, most probably, out of
>>>>             scope. With SR, the tunnels that are not affected by
>>>>             topology changes are implemented as contiguous lists of
>>>>             unprotected Adj-SIDs – but forwarding HW is quite
>>>>             limited regarding the length of such lists. Therefore,
>>>>             the common expectation from the SR Micro-Loop avoidance
>>>>              (as well from TI-:FA) is that that it uses tunnels
>>>>             whose paths are not affected by the topology
>>>>             change*/and that are implementing using a reasonably
>>>>             short lists of Node SIDs and Adj-SIDs/*.
>>>
>>>             For link failure with loop free support you never need
>>>             more that two labels: one to get you to the edge of P
>>>             space, and if the P mode is not a PQ node, a second
>>>             table to get you into Q space.
>>>
>>>             A router already has the label t reach the P router, and
>>>             pre the work on SR we proposed to use TLDP, but now you
>>>             would use an SR label.
>>>
>>>             So you only ever need one label at ingress and you
>>>             already have that. You need at most two labels at the
>>>             PLR, one normal label that you already have and one
>>>             adjacency label that you could have got from T-LDP but
>>>             which you more conveniently get from the SR system.
>>>
>>>             This is much simpler than the TiLFA approach and just works.
>>>
>>>>             Section 6 of the TI-LFA draft describes how such paths
>>>>             can be computed in the case of a single link failure,
>>>>             and the constrain of post-convergence is one way to
>>>>             guarantee that they are not affected by topology changes.
>>>>             SR Micro-Loop Avoidance draft, for the last 7 years,
>>>>             repeats the promise to define approaches for computing
>>>>             such paths in Section 3 which remains unchanged from
>>>>             the -00 version and until this day.
>>>>
>>>>             I admit that I am not aware of another way to guarantee
>>>>             that the path that is implemented as a sequence of SISD
>>>>             and includes Node SIDs would not be affected by the
>>>>             topology change.
>>>>             What do you think?
>>>
>>>             I think we are making a simple problem much harder than
>>>             it needs to be.
>>>
>>>             Best regards
>>>
>>>             Stewart
>>>
>>>>             Regards,
>>>>             Sasha
>>>>             Regards,
>>>>             Sasha
>>>>             *From:*Stewart Bryant <[e-mail]>
>>>>             *Sent:*Thursday, November 2, 2023 1:29 PM
>>>>             *To:*Alexander Vainshtein <[e-mail]>
>>>>             *Cc:*Stewart Bryant
>>>>             <[e-mail]>;[e-mail]; rtgwg-chairs
>>>>             <[e-mail]>;[e-mail];
>>>>             Gyan Mishra <[e-mail]>
>>>>             *Subject:*Re: [EXTERNAL]
>>>>             draft-ietf-rtgwg-segment-routing-ti-lfa : A simple
>>>>             pathological network fragment
>>>>             I just want to correct something
>>>>             You do not of course need to tunnel if the packets only
>>>>             go though nodes that are shielded from the knowledge
>>>>             that the link has failed and thus ego not reconverge. A
>>>>             method such as RFC5715 section 6.7 - Ordered FIB update
>>>>             - does not require a tunnel because it causes the Q
>>>>             space to gradually expand and P space to gradually
>>>>             contract until the PLR is subsumed into Q space.
>>>>             - Stewart
>>>>
>>>>
>>>>                 On 2 Nov 2023, at 11:20, Stewart Bryant
>>>>                 <[e-mail]> wrote:
>>>>
>>>>
>>>>                     On 2 Nov 2023, at 08:56, Alexander Vainshtein
>>>>                     <[e-mail]> wrote:
>>>>                     Stewart and all,
>>>>                     I have looked upRFC5715 Section 6.2
>>>>                     <https://www.rfc-editor.org/rfc/rfc5715#section-6.2>and
>>>>                     I agree that it is similar to theSR Micro-Loop
>>>>                     Avoidance
>>>>                     <https://datatracker.ietf.org/doc/html/draft-bashandy-rtgwg-segment-routing-uloop-15>draft.
>>>>                     Specifically, explicitly mentions usage of
>>>>                      “tunnels whose path is not affected by the
>>>>                     topology change” which is quite close IMHO to
>>>>                     what the SR Micro-Loop avoidance draft is about
>>>>                     and quite close to post-convergence paths used
>>>>                     in TI-LFA.
>>>>                     At the same time there are some differences.
>>>>                     Specifically, RFC mentions “a new
>>>>                     "loop-prevention" routing message” being issued
>>>>                     by the router adjacent to failure. No such
>>>>                     message is required in the SR Micro-Loop
>>>>                     Avoidance draft.
>>>>
>>>>                 There are two ways of looking at this - new as in
>>>>                 of a new type - and new as in a new message is issued.
>>>>                 What ever you do you need a message to trigger loop
>>>>                 prevention otherwise nodes remote from the failure
>>>>                 will not know that it is needed. This could be done
>>>>                 in one of two ways, either a bespoke fast flooded
>>>>                 message, or you can trigger it from the routing LSP
>>>>                 that will be issued by the PLR. It is not clear how
>>>>                 fast the LSP flooding message will reach the all
>>>>                 the nodes in P space.
>>>>                 Either way you need a message to trigger loop
>>>>                 prevention.
>>>>
>>>>                     I also think that the proposal, in the case of
>>>>                     a link failure, to tunnel traffic to the
>>>>                     nearest node adjacent to failure, is
>>>>                     problematic. (Of course, the SR Micro-Loop
>>>>                     Avoidance draft does not provide any approach
>>>>                     for computing micro-loop avoiding paths with
>>>>                     limited depth of added label stacks at all, it
>>>>                     just repeats the promise to provide reference
>>>>                     approaches starting from version -00 and until
>>>>                     now).
>>>>
>>>>                 There are of course multiple ways of avoiding loops
>>>>                 called up in RFC5715, but all of them require that
>>>>                 all packets arriving at any ingress in the network
>>>>                 that would originally go to the PLR either go
>>>>                 direct to Q space or continue in P space to the PLR
>>>>                 are repaired. If they are going to the PLR they
>>>>                 need to be tunnelled where for the purposes of this
>>>>                 discussion encapsulating in an SR packet is
>>>>                 considered to be a tunnel.
>>>>                 Anyway you did not comment on my point that if we
>>>>                 need loop free anyway the congruence of the PLR
>>>>                 path to the PQ node is no longer a hard requirement.
>>>>                 Best regards
>>>>                 Stewart
>>>>
>>>>
>>>>                     My 2c,
>>>>                     Sasha
>>>>                     *From:*Stewart Bryant <[e-mail]>
>>>>                     *Sent:*Thursday, November 2, 2023 10:15 AM
>>>>                     *To:*Alexander Vainshtein
>>>>                     <[e-mail]>
>>>>                     *Cc:*Stewart Bryant
>>>>                     <[e-mail]>;[e-mail];
>>>>                     rtgwg-chairs
>>>>                     <[e-mail]>;[e-mail];
>>>>                     Gyan Mishra <[e-mail]>
>>>>                     *Subject:*Re: [EXTERNAL]
>>>>                     draft-ietf-rtgwg-segment-routing-ti-lfa : A
>>>>                     simple pathological network fragment
>>>>                     As far as I can see SR Microloop avoidance is
>>>>                     RFC5715 Section 6.2 nearside tunnelling.
>>>>                     That works unconditionally regardless of the
>>>>                     Ti-LFA constraints.
>>>>                     My point is that as soon as you recognise the
>>>>                     need to introduce one of the RFC5715 micro loop
>>>>                     avoidance methods you admit that TiLFA does not
>>>>                     unconditionally address micro loops and thus
>>>>                     the TiLFA repair topology constraint is no
>>>>                     longer REQUIRED. An implementor may chose to do
>>>>                     it, but it becomes OPTIONAL.
>>>>                     I think that this needs a discussion chaired by
>>>>                     the RTGWG chairs either during IETF 118 or at a
>>>>                     side meeting or at an online interim.
>>>>                     Stewart
>>>>
>>>>
>>>>
>>>>                         On 2 Nov 2023, at 07:55, Alexander
>>>>                         Vainshtein <[e-mail]>
>>>>                         wrote:
>>>>                         Stewart and all,
>>>>                         Please see some comments*/inline below/*.
>>>>                         Regards,
>>>>                         Sasha
>>>>                         *From:*Stewart Bryant
>>>>                         <[e-mail]>
>>>>                         *Sent:*Thursday, November 2, 2023 9:30 AM
>>>>                         *To:*Gyan Mishra <[e-mail]>
>>>>                         *Cc:*Stewart Bryant
>>>>                         <[e-mail]>; Alexander
>>>>                         Vainshtein
>>>>                         <[e-mail]>;[e-mail];
>>>>                         rtgwg-chairs
>>>>                         <[e-mail]>;[e-mail]
>>>>                         *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 theSR 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]] TheRTGWG 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
>>>>                             <[e-mail]> 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
>>>>                             <[e-mail]> 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
>>>>