Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
Ahmed Bashandy <abashandy.ietf@gmail.com> Wed, 08 November 2023 16:04 UTC
Return-Path: <abashandy.ietf@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B942EC14F73F; Wed, 8 Nov 2023 08:04:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0gNGBBjlqHj; Wed, 8 Nov 2023 08:04:14 -0800 (PST)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62144C14CF1C; Wed, 8 Nov 2023 08:04:12 -0800 (PST)
Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-40859dee28cso53308955e9.0; Wed, 08 Nov 2023 08:04:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699459451; x=1700064251; darn=ietf.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=NQMs1Co8Zzuy6U1HSY0X4uSJwvhJ8tFb0xZFUQpHxEk=; b=EJGjZzXJwmQQ6MIhY4v//YwRgPXDnGwWpSfQi9vQNLsnVNvkmylgriEfSzD29TRClE HIy2PZcbRJ9K/WkURGyU+ibYBIGXDdzn3rr+mtJMFOK16V8krzZEvQlHMoyAjlxCTFZ5 3BpZTdHMI4+kUVGIWuQV/qlkYz/I4R/hMAOf2RuVqtmy1PjUUJYQaMqKYOd1bWn5N8Hf //mjI0ts0WnNzoDh/3U5P6Z9nb56S63rXNLRXFSN6f7SsJdbSA/cTnZMvJuHXDRRY/IC DTg+w49LRNxhMIvVkGIUVTCkL7+IZPBKR2jw72IHAIkhXnCKd9vIBUMOe3uIJsv5c8Gj XluA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699459451; x=1700064251; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=NQMs1Co8Zzuy6U1HSY0X4uSJwvhJ8tFb0xZFUQpHxEk=; b=nsSVM7/3SB2imshsZX8lm1VCVIi01MbCCpWwKXGVgcUCOc5qTqXid/CCFoRl+iV+bc G2apxkYkCKSRBQfxcNGTLtkZR6FPs67j7mQAt5z330cRwkSalWBovL9TiQXSfnK+NhOb d0+gNQZafiqmoGCmv+mFcEgxyGUA7Nb/kZPy08Y+l8DXxjlrKj7ZvjZoogjAHYXSwfUj HE9ki6BPQoVThbnseiMKshb6PRieHb79EotxqDt44So2Z7WGBFw8FhiG/DhNIYQTW0+P Aijic8HK22Bos7b1gyK8Qj3P+lMrzUzVHMto/wK44aL5NkdYW3NTqJWu0iiwrR1w3wSl AnDQ==
X-Gm-Message-State: AOJu0YyZ/J0dQB+pqIDJ9IX/YHSwIMY8o2GWV7oZ+tle/yVldoJSi0gd TXljWEcEHQitu+vJQsll5i3EtEaV3aM=
X-Google-Smtp-Source: AGHT+IG9TrV28HYChL0eiH3h3xwFNocAoQmk2ZI0PsienM77kf1W/rnuZuXBGxQFx57OJMm1THltfA==
X-Received: by 2002:a5d:64ac:0:b0:32f:7ae2:4165 with SMTP id m12-20020a5d64ac000000b0032f7ae24165mr2372690wrp.9.1699459330800; Wed, 08 Nov 2023 08:02:10 -0800 (PST)
Received: from [192.168.1.120] ([197.53.194.182]) by smtp.gmail.com with ESMTPSA id m13-20020a5d4a0d000000b00327b5ca093dsm5250439wrq.117.2023.11.08.08.02.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Nov 2023 08:02:10 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------15HRjOCcta0WN6rK6sfL9S6p"
Message-ID: <235df8c1-b92f-d078-a711-6fee40c64aee@gmail.com>
Date: Wed, 08 Nov 2023 08:02:08 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Subject: Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-ti-lfa : A simple pathological network fragment
Content-Language: en-US
To: Yingzhen Qu <yingzhen.ietf@gmail.com>, Stewart Bryant <stewart.bryant@gmail.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>, "draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org" <draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org>, rtgwg-chairs <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
References: <9908D9F3-45C6-497D-B3BF-84D8A68A5013@gmail.com> <PH0PR03MB63004F32F9AF282ECDB78637F6D9A@PH0PR03MB6300.namprd03.prod.outlook.com> <AS2PR02MB88393EC50B913A5F8C3AB5E2F0D8A@AS2PR02MB8839.eurprd02.prod.outlook.com> <PH0PR03MB6300D9A7F9DC3E2E864EF11EF6D8A@PH0PR03MB6300.namprd03.prod.outlook.com> <CABNhwV30uhLOo52WHAv6YS4Wg0k9gDbkrs1ANuGPPdLzc1=dsw@mail.gmail.com> <6A2E595E-A7E6-4976-ACC9-E75402AD99E2@gmail.com> <PH0PR03MB63005F751BF04E8D5BEC982FF6A6A@PH0PR03MB6300.namprd03.prod.outlook.com> <A5218ED2-479C-48B5-8AC8-DA6B247D6665@gmail.com> <PH0PR03MB63000BC8F43B90B0CA1A1543F6A6A@PH0PR03MB6300.namprd03.prod.outlook.com> <E02A044F-4431-4559-97A8-C6B810DD7E4D@gmail.com> <AF2B1C41-55F6-4E78-AA4B-0AE7F573820B@gmail.com> <PH0PR03MB63002291B0F1F5514875018EF6A6A@PH0PR03MB6300.namprd03.prod.outlook.com> <2A85DD24-612D-472D-907D-1D90C88A95AD@gmail.com> <CABY-gOMVMb+TWLoKBdurn7jL=xF6APeVhEoSzSbH5CGnvmpLHw@mail.gmail.com>
From: Ahmed Bashandy <abashandy.ietf@gmail.com>
In-Reply-To: <CABY-gOMVMb+TWLoKBdurn7jL=xF6APeVhEoSzSbH5CGnvmpLHw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/Yupfre8ASUJntbBnR6c1U00Seno>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Nov 2023 16:04:18 -0000
I still don't understand the issue that needs to be resolved Stewart, It is obvious that you are insisting of pushing uloop avoidance down the throat of the ti-lfa even though it is clearly out of scope and you have not done it yourself in the tweo RFCs thast you 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 > <stewart.bryant@gmail.com> wrote: > > Sasha, please see inline > >> On 2 Nov 2023, at 14:12, Alexander Vainshtein >> <Alexander.Vainshtein@rbbn.com> 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 <stewart.bryant@gmail.com> >> *Sent:*Thursday, November 2, 2023 1:29 PM >> *To:*Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> >> *Cc:*Stewart Bryant <stewart.bryant@gmail.com>;rtgwg@ietf.org; >> rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org; >> Gyan Mishra <hayabusagsm@gmail.com> >> *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 >> <stewart.bryant@gmail.com> wrote: >> >> >> On 2 Nov 2023, at 08:56, Alexander Vainshtein >> <Alexander.Vainshtein@rbbn.com> 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 <stewart.bryant@gmail.com> >> *Sent:*Thursday, November 2, 2023 10:15 AM >> *To:*Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> >> *Cc:*Stewart Bryant >> <stewart.bryant@gmail.com>;rtgwg@ietf.org; rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org; >> Gyan Mishra <hayabusagsm@gmail.com> >> *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 >> <Alexander.Vainshtein@rbbn.com> wrote: >> Stewart and all, >> Please see some comments*/inline below/*. >> Regards, >> Sasha >> *From:*Stewart Bryant <stewart.bryant@gmail.com> >> *Sent:*Thursday, November 2, 2023 9:30 AM >> *To:*Gyan Mishra <hayabusagsm@gmail.com> >> *Cc:*Stewart Bryant <stewart.bryant@gmail.com>; >> Alexander Vainshtein >> <Alexander.Vainshtein@rbbn.com>;rtgwg@ietf.org; >> rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@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 >> 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 >> <hayabusagsm@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 <Alexander.Vainshtein@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.decraene@orange.com<bruno.decraene@orange.com> >> *Sent:*Monday, October 23, 2023 3:27 PM >> *To:*Alexander Vainshtein >> <Alexander.Vainshtein@rbbn.com> >> *Cc:*rtgwg@ietf.org; rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org; >> Stewart Bryant <stewart.bryant@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: >> >> 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 >> <Alexander.Vainshtein@rbbn.com> >> *Sent:*Sunday, October 22, 2023 4:21 PM >> *To:*DECRAENE Bruno INNOV/NET >> <bruno.decraene@orange.com>; Stewart Bryant >> <stewart.bryant@gmail.com> >> *Cc:*rtgwg@ietf.org; rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@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 <rtgwg-bounces@ietf.org>*On >> Behalf Of*bruno.decraene@orange.com >> *Sent:*Thursday, October 19, 2023 7:34 PM >> *To:*Stewart Bryant <stewart.bryant@gmail.com> >> *Cc:*rtgwg@ietf.org; rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@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 >> >> >> >> 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 <stewart.bryant@gmail.com> >> *Sent:*Tuesday, October 17, 2023 1:48 PM >> *To:*DECRAENE Bruno INNOV/NET >> <bruno.decraene@orange.com> >> *Cc:*Stewart Bryant >> <stewart.bryant@gmail.com>;rtgwg@ietf.org; >> rtgwg-chairs >> <rtgwg-chairs@ietf.org>;draft-ietf-rtgwg-segment-routing-ti-lfa@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 below. >> Best regards >> Stewart >> >> On 16 Oct 2023, at >> 17:25,bruno.decraene@orange.comwrote: >> Hi Stewart, >> Please see inline >> Orange Restricted >> *From:*Stewart Bryant >> <stewart.bryant@gmail.com >> <mailto:stewart.bryant@gmail.com>> >> *Sent:*Monday, October 16, 2023 2:08 PM >> *To:*rtgwg@ietf.org >> <mailto:rtgwg@ietf.org>; rtgwg-chairs >> <rtgwg-chairs@ietf.org >> <mailto:rtgwg-chairs@ietf.org>>;draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org >> <mailto:draft-ietf-rtgwg-segment-routing-ti-lfa@ietf.org> >> *Cc:*Stewart Bryant >> <stewart.bryant@gmail.com >> <mailto:stewart.bryant@gmail.com>> >> *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/ >> <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 >> <https://datatracker.ietf.org/doc/html/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 >> <https://datatracker.ietf.org/doc/html/rfc5715>], [RFC6976 >> <https://datatracker.ietf.org/doc/html/rfc6976>], or >> >> [ULOOP-DELAY >> <https://datatracker.ietf.org/doc/html/rfc7490#ref-ULOOP-DELAY>], should be implemented.” >> >> https://datatracker.ietf.org/doc/html/rfc7490#section-10 >> <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 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. >> >> ____________________________________________________________________________________________________________ >> >> 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. >> >> *Disclaimer* >> >> This e-mail together with any attachments may >> contain information of Ribbon Communications >> Inc. and its Affiliates that is confidential >> and/or proprietary for the sole use of the >> intended recipient. Any review, disclosure, >> reliance or distribution by others or >> forwarding without express permission is >> strictly prohibited. If you are not the >> intended recipient, please notify the sender >> immediately and then delete all copies, >> including any attachments. >> >> ____________________________________________________________________________________________________________ >> >> 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 >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg
- draft-ietf-rtgwg-segment-routing-ti-lfa : A simpl… Stewart Bryant
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Stewart Bryant
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Alexander Vainshtein
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Gyan Mishra
- RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Alexander Vainshtein
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Yingzhen Qu
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Gyan Mishra
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Alexander Vainshtein
- Re: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Gyan Mishra
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Yingzhen Qu
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Ahmed Bashandy
- Re: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Gyan Mishra
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Yingzhen Qu
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Ahmed Bashandy
- RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Alexander Vainshtein
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Voyer, Daniel
- draft-bashandy-rtgwg-segment-routing-uloop bruno.decraene
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Ahmed Bashandy
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Yingzhen Qu
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- RE: [EXTERNAL] Re: draft-ietf-rtgwg-segment-routi… Alexander Vainshtein
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Alexander Vainshtein
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Voyer, Daniel
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Stewart Bryant
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Alexander Vainshtein
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Alexander Vainshtein
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Alexander Vainshtein
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Ahmed Bashandy
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Voyer, Daniel
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Gyan Mishra
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Stewart Bryant
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Stewart Bryant
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Ahmed Bashandy
- RE: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… bruno.decraene
- Re: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Stewart Bryant
- Re: draft-ietf-rtgwg-segment-routing-ti-lfa : A s… Ahmed Bashandy
- RE: [EXTERNAL] draft-ietf-rtgwg-segment-routing-t… Alexander Vainshtein