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

[Yingzhen Qu <[e-mail]>]

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 between Section 6.2 of RFC 5715
>>> <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and the SR
>>> 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 up RFC5715 Section 6.2
>>> <https://www.rfc-editor.org/rfc/rfc5715#section-6.2> and I agree that
>>> it is similar to the SR 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 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 <[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
>>>
>>>