Yes Ahmed and thanks for Yingzhen for correcting my copy/paste – the date is Nov 8th
From: rtgwg <[email protected]> on behalf of Ahmed Bashandy <[email protected]> Date: Tuesday, November 7, 2023 at 10:38 AM To: Yingzhen Qu <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, rtgwg-chairs <[email protected]>, Alexander Vainshtein <[email protected]> Subject: [EXT]Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: Sasha, please see inline On 2 Nov 2023, at 14:12, Alexander Vainshtein <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, November 2, 2023 1:29 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: Stewart Bryant <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; rtgwg-chairs <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Gyan Mishra <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: On 2 Nov 2023, at 08:56, Alexander Vainshtein <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Thursday, November 2, 2023 10:15 AM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: Stewart Bryant <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; rtgwg-chairs <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Gyan Mishra <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: Stewart and all, Please see some comments inline below. Regards, Sasha From: Stewart Bryant <[email protected]<mailto:[email protected]>> Sent: Thursday, November 2, 2023 9:30 AM To: Gyan Mishra <[email protected]<mailto:[email protected]>> Cc: Stewart Bryant <[email protected]<mailto:[email protected]>>; Alexander Vainshtein <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; rtgwg-chairs <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
