Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm
Christian Hopps <chopps@chopps.org> Tue, 18 April 2023 09:32 UTC
Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B15C16B5CB for <lsr@ietfa.amsl.com>; Tue, 18 Apr 2023 02:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 vW76UFUKoXx3 for <lsr@ietfa.amsl.com>; Tue, 18 Apr 2023 02:32:38 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6B1C16B5C9 for <lsr@ietf.org>; Tue, 18 Apr 2023 02:32:38 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (172-222-091-149.res.spectrum.com [172.222.91.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6F5E77D123; Tue, 18 Apr 2023 09:32:37 +0000 (UTC)
References: <2afe643787bb4f6-00031.Richmail.00003020195207731471@chinamobile.com> <17e10c23-bc33-f184-8ace-bdeb65f18626@cisco.com> <m2edoiznvf.fsf@ja.int.chopps.org> <CH0PR05MB10273CF53712A00359118916EDB9D9@CH0PR05MB10273.namprd05.prod.outlook.com> <m2354xzggy.fsf@ja.int.chopps.org>
User-agent: mu4e 1.8.14; emacs 28.2
From: Christian Hopps <chopps@chopps.org>
To: Louis Chan <louisc@juniper.net>
Cc: Christian Hopps <chopps@chopps.org>, Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org>, Liyan Gong <gongliyan@chinamobile.com>, Ketan Talaulikar <ketant.ietf@gmail.com>, Krzysztof Szarkowicz <kszarkowicz@juniper.net>, Robert Raszuk <robert@raszuk.net>, linchangwang <linchangwang.04414@h3c.com>, Acee Lindem <acee.ietf@gmail.com>, 程伟强 <chengweiqiang@chinamobile.com>, "Les Ginsberg(ginsbe" <ginsberg@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
Date: Tue, 18 Apr 2023 05:31:36 -0400
In-reply-to: <m2354xzggy.fsf@ja.int.chopps.org>
Message-ID: <m2y1mpy1qj.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/PVhK_FspwpnfEn5nv1wx_OqB6oE>
Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2023 09:32:42 -0000
Sorry forgot to add this was "as wg-member". Thanks, Chris. [as wg-member] Christian Hopps <chopps@chopps.org> writes: > Louis Chan <louisc@juniper.net> writes: > >> Hi Christian, >> >> Three comments on flooding enhancement >> >> - It is discussed in IS-IS domain. How about OSPF? >> - The proposed offset solution works for both. > > If OSPF needs improvement here then that is what we should be working to fix. > >> - I believe that the convergence and stability is limited by the weakness node >> in the network, especially in transit node position. The flooding might help the >> high-end node with better control plane, but it might not help the weakest node >> with limited control plane resource. > > Operators with 1000s of routers and routers with 1000s of interfaces don't > create flooding choke-points, and especially don't then drop crappy routers in > said choke-points. We should not modify our routing protocols to support such > poor network design. > > Thanks, > Chris. > >> - The proposed method is not changing the concept on protocol, e.g. using SRGB (especially in different range) plus index is indeed, by nature, similar to offset approach. >> >> Rgds >> louis >> >> -----Original Message----- >> From: Christian Hopps <chopps@chopps.org> >> Sent: Monday, April 17, 2023 8:25 PM >> To: Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> >> Cc: Liyan Gong <gongliyan@chinamobile.com>; Louis Chan <louisc@juniper.net>; >> Ketan Talaulikar <ketant.ietf@gmail.com>; Krzysztof Szarkowicz >> <kszarkowicz@juniper.net>; Robert Raszuk <robert@raszuk.net>; linchangwang >> <linchangwang.04414@h3c.com>; Acee Lindem <acee.ietf@gmail.com>; 程伟强 >> <chengweiqiang@chinamobile.com>; Les Ginsberg(ginsbe <ginsberg@cisco.com>; >> lsr@ietf.org >> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm >> >> [External Email. Be cautious of content] >> >> >> Peter Psenak <ppsenak=40cisco.com@dmarc.ietf.org> writes: >> >>> Liyan, >>> >>> On 13/04/2023 06:50, Liyan Gong wrote: >>>> Hi All， >>>> Thanks for your discussion, here are some informations to help understanding >>>> better. >>>> 1. About the application scenario, please refer to the following draft. >>>> >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$ >>>> >> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$ >>> >>>> Flex-Algo can be associated with the level-1 network slice which provides >>>> dynamic programming topology. >>>> The number of Flex-Algos is the same as the number of the level-1 network >>>> slices. Maybe it can reach dozens. >>>> 2. About the performance impact, Maybe we can think of it as advertising >>>> massive routes through multi-pair neighbors in IGP domain. >>>> Since the advertising and flooding process occupy a lot of router resources, >>>> Network changes can not be converged in time. >>>> This will result in wrong traffic forwarding. That is why there is limitation >>>> on the number of routes in IGP domain. >>>> According to the anaysis by Changwang in the following email, SIDs take up a >>>> big part. >>>> We think it is better if Flex-Algo can be scaled up by optimizing the SIDs >>>> format without changing the IGP basic mechanism. >>> >>> I find the above claim incorrect and misleading. Network convergence is not the >>> function of the a amount of data advertised per adjacency. >> >> Well if we restrict ourselves to the claim that more data adds to convergence >> time, then that isn't incorrect. It takes longer to flood more data, and the >> data must be flooded for convergence, so transitive property here.. more data >> implies longer convergence time -- unless some other part of convergence is >> decoupled from flooding and takes even longer than flooding takes, but I don't >> think that's the case. >> >> We've been working on improving flooding speed/efficiency for just this reason. >> >> However, the misleading part is maybe true; put differently there's something >> being left out here. The only reason we are flooding large amounts of data is if >> large amounts of data changed, this is not really going to happen very often >> (e.g., when you have a partition repair event, or a new router comes online and >> just happens to have a ton of data to flood for itself). >> >> One could argue that these somewhat uncommon events can (and should) be handled >> just fine by the flooding improvements we are working on. Why invent application >> specific protocol changes when we can address the problem with a generic >> solution that works for all applications? >> >> Thanks, >> Chris. >> >>> >>> thanks, >>> Peter >>> >>> >>> >>>> Best Regards, >>>> Liyan >>>> ----邮件原文---- >>>> *发件人：*Louis Chan <louisc=40juniper.net@dmarc.ietf.org> >>>> *收件人：*Ketan Talaulikar <ketant.ietf@gmail.com> >>>> *抄 送: >>>> >>> *Krzysztof Szarkowicz <kszarkowicz@juniper.net>,Robert Raszuk >> <robert@raszuk.net>,linchangwang <linchangwang.04414@h3c.com>,Acee Lindem >> <acee.ietf@gmail.com>,Peter Psenak <ppsenak@cisco.com>," >>> 程伟强 >>> " <chengweiqiang@chinamobile.com>,"Les Ginsberg(ginsbe" <ginsberg@cisco.com>,lsr <lsr@ietf.org> >>>> *发送时间：*2023-04-13 12:31:12 >>>> *主题：*Re: [Lsr] IETF- >>>> 116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm >>>> Hi Ketan, >>>> Just a short response. >>>> If you remember ATM days, there are VP shaping/policing and VC >>>> shaping/policing. It can solve quite complicated QOS problem. >>>> Here we are not doing the costly ATM again. >>>> With kind of hierarchical QOS readily available in ASIC today, it >>>> potentially solves some complex multipoint to multipoint QOS problem. >>>> But first, it requires labeling the packet, like VCI and VPI. >>>> I am going to stop here because it would be too much to discuss. >>>> Rgds >>>> Louis >>>> *From:* Ketan Talaulikar <ketant.ietf@gmail.com> >>>> *Sent:* Thursday, April 13, 2023 12:02 PM >>>> *To:* Louis Chan <louisc@juniper.net> >>>> *Cc:* Krzysztof Szarkowicz <kszarkowicz@juniper.net>; Robert Raszuk >>>> <robert@raszuk.net>; linchangwang <linchangwang.04414@h3c.com>; Acee >>>> Lindem <acee.ietf@gmail.com>; Peter Psenak <ppsenak@cisco.com>; 程伟 >>>> 强 <chengweiqiang@chinamobile.com>; Les Ginsberg (ginsbe >>>> <ginsberg@cisco.com>; lsr <lsr@ietf.org> >>>> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising >>>> Offset forFlex-Algorithm >>>> *[External Email. Be cautious of content]* >>>> Hi Louis, >>>> First we need to ascertain if it is necessary before we get things >>>> flooded into IGPs. Then we can get to the evaluation of whether or >>>> how "evil" it is. >>>> The VLAN analogy seems incorrect to me and a debate on that may be >>>> orthogonal to this topic. I'll wait for the "necessity" to be first >>>> described before taking a bite at this PIZZA ;-) >>>> Once again, thanks for your work on this document. >>>> Thanks, >>>> Ketan >>>> On Thu, Apr 13, 2023 at 9:15AM Louis Chan <louisc@juniper.net >>>> <mailto:louisc@juniper.net>> wrote: >>>> Hi Ketan, >>>> First, I like “PIZZA” more than “VFA”, and at least it is closer >>>> to “real” and tasty instead of “virtual” and boring. :) >>>> For VFA, it is just a further identification method. History has >>>> VLAN first introduced in ethernet. People might think it was >>>> already enough in that period. But later, market asked for >>>> stacked vlan, and find its application. >>>> Having VFA/PIZZA might give more possibilities for future usage. >>>> It is only ~30B advertisement per VFA per node, and it would not >>>> be a big harm. And there is no further header overhead (or cell >>>> tax) in forwarding plane, and make it easy of vendor interop. >>>> This is more important. >>>> I have no intention to swamp IGP with control plane kind of >>>> info, like QOS profile. My view is to leave IGP as slim as >>>> possible for quick reaction to network changes. >>>> If it is a necessary evil, it should be minimum. My take would >>>> be getting minimum but useful enough info into FAD. In this >>>> case, the advertisement size is small, with ease of management. >>>> That is what I refer to “good to have” info in previous email. >>>> Rgds >>>> Louis >>>> *From:* Ketan Talaulikar <ketant.ietf@gmail.com >>>> <mailto:ketant.ietf@gmail.com>> >>>> *Sent:* Thursday, April 13, 2023 12:06 AM >>>> *To:* Krzysztof Szarkowicz <kszarkowicz@juniper.net >>>> <mailto:kszarkowicz@juniper.net>> >>>> *Cc:* Robert Raszuk <robert@raszuk.net >>>> <mailto:robert@raszuk.net>>; linchangwang >>>> <linchangwang.04414@h3c.com >>>> <mailto:linchangwang.04414@h3c.com>>; Acee Lindem >>>> <acee.ietf@gmail.com <mailto:acee.ietf@gmail.com>>; Peter >>>> Psenak <ppsenak@cisco.com <mailto:ppsenak@cisco.com>>; 程伟强 >>>> <chengweiqiang@chinamobile.com >>>> <mailto:chengweiqiang@chinamobile.com>>; Louis Chan >>>> <louisc@juniper.net <mailto:louisc@juniper.net>>; Les Ginsberg >>>> (ginsbe <ginsberg@cisco.com <mailto:ginsberg@cisco.com>>; lsr >>>> <lsr@ietf.org <mailto:lsr@ietf.org>> >>>> *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for >>>> Advertising Offset forFlex-Algorithm >>>> *[External Email. Be cautious of content]* >>>> Hi Krzysztof, >>>> I got the impression that the use-case/need for these VFA SIDs >>>> in the first place was to carry some indication in the packet >>>> for local treatment at each hop (e.g,, bandwidth profile or QoS >>>> treatment?) in the data path since the forwarding is based on >>>> FlexAlgo. >>>> If not, then I am not sure that I follow the use-case or >>>> motivation for VFA (or pizza ;-) as Louis calls it) in the first >>>> place. >>>> Thanks, >>>> Ketan >>>> On Wed, Apr 12, 2023 at 9:28PM Krzysztof Szarkowicz >>>> <kszarkowicz@juniper.net <mailto:kszarkowicz@juniper.net>> wrote: >>>> Hi Ketan, >>>> I agree with you. The draft doesn’t propose to carry >>>> ’service bandwidth profile’ parameters in the IGP. >>>> The draft is dealing only with label/SID >>>> assignment/generation and distribution. >>>> Thanks, >>>> Krzysztof >>>> On 2023 -Apr-12, at 17:49, Ketan Talaulikar >>>> <ketant.ietf@gmail.com <mailto:ketant.ietf@gmail.com>> >>>> wrote: >>>> *[External Email. Be cautious of content]* >>>> Hi Krzysztof, >>>> A further question is if it is necessary to carry this >>>> "service bandwidth profile" information in the IGPs in >>>> the first place. Why not indicate this just in the >>>> packet? Wouldn't that be a better way to help scale >>>> IGPs by not introducing this into IGPs in the first >>>> place? ;-) >>>> One such simple solution is proposed by >>>> >>> >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc53EY1fY$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-decraene-mpls-slid-encoded-entropy-label-id/__;!!NEt6yMaO-gk!DxCsNxydz3b_s_iNl0j_6pyHLD1_vLYmeqwZbd_OBYdhfs3BBaQ8bIXbBsB-4Yigax-NkpPUA1EmCDwYmDNrSqU0Lg$> >>>> Thanks, >>>> Ketan >>>> On Wed, Apr 12, 2023 at 9:13PM Krzysztof Szarkowicz >>>> <kszarkowicz=40juniper.net@dmarc.ietf.org >>>> <mailto:40juniper.net@dmarc.ietf.org>> wrote: >>>> Hi, >>>> It is the question, if we could for example have >>>> more than 20 (e.g. 200), for 200 different service >>>> bandwidth guarantees (but having only one - or >>>> handful - SPF calculation domains, where one SPF >>>> calculation domain is one ‘legacy’ flex-algo ). The >>>> challenge is with SPP calculations, once the number >>>> of flex-algos goes high. >>>> Thanks, >>>> Krzysztof >>>> On 2023 -Apr-12, at 17:13, Robert Raszuk >>>> <robert@raszuk.net <mailto:robert@raszuk.net>> >>>> wrote: >>>> *[External Email. Be cautious of content]* >>>> Ok you can use 20 flex algos today with no >>>> extension. Is going to another level of nesting >>>> really necessary ? >>>> On Wed, Apr 12, 2023 at 4:52PM linchangwang >>>> <linchangwang.04414@h3c.com >>>> <mailto:linchangwang.04414@h3c.com>> wrote: >>>> Hi Acee >>>> An operator's backbone network is divided >>>> into different flex algorithms planes >>>> according to different SLA requirements of >>>> users. >>>> A flex algo represents a service >>>> requirement, such as bandwidth requirements. >>>> 20 flex algorithms represent 20 different >>>> service bandwidth guarantees, corresponding >>>> to different resource requirements. >>>> Thanks, >>>> Changwang lin >>>> *From:*Acee Lindem >>>> [mailto:acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com>] >>>> *Sent:* Wednesday, April 12, 2023 10:12 PM >>>> *To:* Peter Psenak >>>> *Cc:* linchangwang (RD); 程伟强; Louis Chan; >>>> Les Ginsberg (ginsbe; lsr; Krzysztof Szarkowicz >>>> *Subject:* Re: [Lsr] IETF-116 LSR - IGP >>>> extensions for Advertising Offset >>>> forFlex-Algorithm >>>> Hi Weiqiang, >>>> I’m also curious as to how you are using 20 >>>> different flex algorithms. Is this just a >>>> hypothetical scenario >>>> to illustrate the mathematics or do you have >>>> an actual use case? >>>> On Apr 12, 2023, at 09:31, Peter Psenak >>>> <ppsenak@cisco.com >>>> <mailto:ppsenak@cisco.com>> wrote: >>>> Changwang, >>>> please see inline (##PP2): >>>> On 12/04/2023 15:13, linchangwang wrote: >>>> Hi Peter >>>> Please see inline [changwang lin]. >>>> We've met the same problem when applying >>>> Flex Algo in SRv6 network. >>>> what problem exactly, can you please >>>> describe it? >>>> [changwang lin] >>>> Advertisement size of per Flex-Algo Adj-SID >>>> in the network >>>> Related to F(# of node, # of FA, # of links) >>>> For a node with 1,000 links and 20 Flex-Algo >>>> n x 20 x 1000 >>>> MPLS-SR：If n = 10 bytes, it is 200K bytes >>>> SRv6： If n = 24 bytes, it is 400K+ bytes >>>> If 500 nodes: >>>> MPLS-SR：it is 200K*500 = 100000k bytes >>>> SRv6： it is 400K+ * 500 = 200000k bytes >>>> If interface mtu=1500, lsp length = 1497 >>>> LSPs num: >>>> MPLS-SR：10000k bytes/1497 = 66800 lsps >>>> SRv6： 20000k bytes/1497 = 160320 lsps >>>> The number of LSPs is too large, and IS-IS >>>> needs to periodically refresh LSPs, >>>> resulting in a decrease in ISIS performance >>>> and unstable network operation. >>>> ##PP2 >>>> above is hardly a realistic estimation. >>>> In a network with 1k nodes, not every node >>>> will have 1k links. >>>> Advertising large number of LSPs is not >>>> caused by Adj-SIDs. >>>> With TE enabled the amount of data flooded >>>> per link is larger than advertisement of the >>>> 20 Adj-SID. The problem you are highlighting >>>> is not specific to Adj-SIDs, it's generic. >>>> LSP refresh time can be set to 18 hours and >>>> any reasonable implementation does not >>>> refresh all LSPs at the same time. >>>> So we need to optimize on the control >>>> surface to save LSP space. >>>> ##PP2 >>>> with all the respect, I don't agree. The >>>> problem as you described it does not exist. >>>> Through the optimization notification >>>> mechanism mentioned in these two documents, >>>> we have greatly saved LSP space for IS-IS >>>> and improved the performance of IS-IS flex >>>> algo in large-scale networking. >>>> At the same time, through the VFA mechanism, >>>> in other non flex algo application scenarios, >>>> such as network slicing scenarios, the LSP >>>> space of IS-IS can also be saved >>>> ##PP2 >>>> it seems to me you are trying to fix the >>>> implementation problem with the protocol >>>> changes, which is never a good idea. >>>> thanks, >>>> Peter >>>> thanks, >>>> Changwang lin >>>> -----Original Message----- >>>> From: Lsr [mailto:lsr-bounces@ietf.org >>>> <mailto:lsr-bounces@ietf.org>] On Behalf Of >>>> Peter Psenak >>>> Sent: Wednesday, April 12, 2023 7:10 PM >>>> To: 程伟强; Louis Chan; Les Ginsberg >>>> (ginsbe; Acee Lindem >>>> Cc: lsr; Krzysztof Szarkowicz >>>> Subject: Re: [Lsr] IETF-116 LSR - IGP >>>> extensions for Advertising Offset >>>> forFlex-Algorithm >>>> Weiqiang, >>>> please see inline (##PP): >>>> On 12/04/2023 12:05, 程伟强wrote: >>>> Hi Louis and Les, >>>> My two cents from operator perspective. >>>> We've met the same problem when applying >>>> Flex Algo in SRv6 network. >>>> what problem exactly, can you please >>>> describe it? >>>> [changwang lin] >>>> Advertisement size of per Flex-Algo Adj-SID >>>> in the network >>>> Related to F(# of node, # of FA, # of links) >>>> For a node with 1,000 links and 20 Flex-Algo >>>> n x 20 x 1000 >>>> MPLS-SR：If n = 10 bytes, it is 200K bytes >>>> SRv6： If n = 24 bytes, it is 400K+ bytes >>>> If 500 nodes: >>>> MPLS-SR：it is 200K*500 = 100000k bytes >>>> SRv6： it is 400K+ * 500 = 200000k bytes >>>> If interface mtu=1500, lsp length = 1497 >>>> LSP num: >>>> MPLS-SR：10000k bytes/1497 = 66800 lsps >>>> SRv6： 20000k bytes/1497 = 160320 lsps >>>> The number of LSPs is too large, and IS-IS >>>> needs to periodically refresh LSPs, >>>> resulting in a decrease in ISIS performance >>>> and unstable network operation. >>>> So we need to optimize on the control >>>> surface to save LSP space. >>>> Through the optimization notification >>>> mechanism mentioned in these two documents, >>>> we have greatly saved LSP space for IS-IS >>>> and improved the performance of IS-IS flex >>>> algo in large-scale networking. >>>> At the same time, through the VFA mechanism, >>>> in other non flex algo application scenarios, >>>> such as network slicing scenarios, the LSP >>>> space of IS-IS can also be saved >>>> As the number of slices and the scale of the >>>> network increases, the >>>> convergence issue which is caused by SIDs >>>> advertising and flooding >>>> becomes more and more serious. >>>> Due to the problem, it is impossible to >>>> apply Flex-Algo in the large >>>> network, such as the network with more than >>>> 1000 routers. >>>> flex-algo has been successfully deployed in >>>> a networks that have more >>>> that 1k nodes. >>>> Maybe you want deploy the flex-algo for >>>> something that it was not >>>> designed for. >>>> I believe Louis'draft provides a good idea >>>> to resolve this problem. >>>> Similar solution for SRv6 SIDs is described >>>> in another draft. >>>> Again, what problem exactly? >>>> From what I see the drafts tries to pack >>>> algo SIDs to save space in >>>> LSP. I don't see how it helps to to deploy >>>> flex-algo in a large scale >>>> network. >>>> thanks, >>>> Peter >>>> About the SIDs assignment, I think it is >>>> better to have a scheduled >>>> assignment than a random assignment as Les >>>> mentioned. >>>> [1] >>>> >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcBb9rYg8$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUND7v7my7$> >>>> >> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcBb9rYg8$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUND7v7my7$>> >>>> Thanks, >>>> Weiqiang Cheng >>>> ----邮件原文---- >>>> *发件人：*Louis Chan >>>> <louisc=40juniper.net@dmarc.ietf.org >>>> <mailto:40juniper.net@dmarc.ietf.org>> >>>> *收件 >>>> 人：*"Les Ginsberg (ginsberg)" >>>> <ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com>>,Acee Lindem >>>> <acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com>> >>>> *抄 送: >>>> *lsr <lsr@ietf.org >>>> <mailto:lsr@ietf.org>>,Krzysztof Szarkowicz >>>> <kszarkowicz@juniper.net >>>> <mailto:kszarkowicz@juniper.net>>,Weiqiang >>>> Cheng <chengweiqiang@chinamobile.com >>>> <mailto:chengweiqiang@chinamobile.com>> >>>> *发送时间：*2023-04-12 10:45:56 >>>> *主题：*Re: [Lsr] IETF- >>>> 116 LSR - IGP extensions for >>>> Advertising Offset forFlex-Algorithm >>>> Hi Les, >>>> Thanks for the prompt reply. Please see >>>> inline for clarification [lc2]. >>>> /Louis >>>> *From:* Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com <mailto:ginsberg@cisco.com>> >>>> *Sent:* Tuesday, April 11, 2023 11:03 PM >>>> *To:* Louis Chan <louisc@juniper.net >>>> <mailto:louisc@juniper.net>>; Acee Lindem >>>> <acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com>> >>>> *Cc:* lsr <lsr@ietf.org >>>> <mailto:lsr@ietf.org>>; Krzysztof Szarkowicz >>>> <kszarkowicz@juniper.net >>>> <mailto:kszarkowicz@juniper.net>>; Weiqiang >>>> Cheng >>>> <chengweiqiang@chinamobile.com >>>> <mailto:chengweiqiang@chinamobile.com>> >>>> *Subject:* RE: [Lsr] IETF-116 LSR - IGP >>>> extensions for Advertising >>>> Offset for Flex-Algorithm >>>> *[External Email. Be cautious of content]* >>>> Louis - >>>> Please see inline. >>>> > -----Original Message----- >>>> > From: Louis Chan <louisc@juniper.net >>>> <mailto:louisc@juniper.net> >>>> <mailto:louisc@juniper.net >>>> <mailto:louisc@juniper.net>>> >>>> > Sent: Monday, April 10, 2023 11:01 PM >>>> > To: Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com <mailto:ginsberg@cisco.com> >>>> <mailto:ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com>>>; Acee Lindem >>>> > <acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com> >>>> <mailto:acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com>>> >>>> > Cc: lsr <lsr@ietf.org >>>> <mailto:lsr@ietf.org> <mailto:lsr@ietf.org >>>> <mailto:lsr@ietf.org>>>; Krzysztof >>>> Szarkowicz <kszarkowicz@juniper.net >>>> <mailto:kszarkowicz@juniper.net> >>>> <mailto:kszarkowicz@juniper.net >>>> <mailto:kszarkowicz@juniper.net>>>; >>>> > Weiqiang Cheng >>>> <chengweiqiang@chinamobile.com >>>> <mailto:chengweiqiang@chinamobile.com> >>>> <mailto:chengweiqiang@chinamobile.com >>>> <mailto:chengweiqiang@chinamobile.com>>> >>>> > Subject: RE: [Lsr] IETF-116 LSR - >>>> IGP extensions for Advertising >>>> Offset for >>>> > Flex-Algorithm >>>> > >>>> > Hi Les, >>>> > >>>> > Thanks for your questions. Please >>>> see inline [lc] below. >>>> > >>>> > /Louis >>>> > >>>> > -----Original Message----- >>>> > From: Les Ginsberg (ginsberg) >>>> <ginsberg@cisco.com <mailto:ginsberg@cisco.com> >>>> <mailto:ginsberg@cisco.com >>>> <mailto:ginsberg@cisco.com>>> >>>> > Sent: Saturday, April 8, 2023 7:34 AM >>>> > To: Acee Lindem <acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com> >>>> <mailto:acee.ietf@gmail.com >>>> <mailto:acee.ietf@gmail.com>>>; Louis Chan >>>> <louisc@juniper.net <mailto:louisc@juniper.net> >>>> <mailto:louisc@juniper.net >>>> <mailto:louisc@juniper.net>>> >>>> > Cc: lsr <lsr@ietf.org >>>> <mailto:lsr@ietf.org> <mailto:lsr@ietf.org >>>> <mailto:lsr@ietf.org>>> >>>> > Subject: RE: [Lsr] IETF-116 LSR - >>>> IGP extensions for Advertising >>>> Offset for >>>> > Flex-Algorithm >>>> > >>>> > [External Email. Be cautious of content] >>>> > >>>> > >>>> > OK - since Acee opened the door - >>>> here are some comments from me - >>>> > starting with the most important. >>>> > >>>> > (BTW - I still have limited >>>> enthusiasm for this draft.) >>>> > >>>> > 1)The proposal places some >>>> restrictions on how operators >>>> provision their >>>> > network in terms of assigning SIDs >>>> and reserving space for future >>>> > assignments. >>>> > If operators do not use compatible >>>> assignment schemes, then this >>>> will never >>>> > get deployed. It is therefore not >>>> enough to come with a nice idea >>>> - you must >>>> > have some enthusiasm from the >>>> operator community. >>>> > >>>> > >>>> > [lc] If the operator only wants to >>>> deploy flex-algo, there is no >>>> change in their >>>> > Node-sid numbering scheme. For the >>>> Adj-sid, these are local >>>> labels with local >>>> > significant only, and there is no >>>> need for any special planning >>>> for Adj-sid, >>>> > unless you are suggesting they want >>>> to make fixed assignment of >>>> Adj-sid >>>> > label for each link. Even with >>>> fixed, the proposed draft has >>>> benefit on that. I >>>> > will explain later. >>>> > >>>> [LES:] Let's discuss this in the >>>> context of prefix-sids - the same >>>> applies to adj-sids. >>>> Today (i.e., in the absence of your >>>> proposal) an operator is free to >>>> assign any label within the SRGB for a >>>> given prefix/algo pair so >>>> long as it is not assigned to some >>>> other prefix/algo context. >>>> Your proposal places some new >>>> restrictions. Now, for a given >>>> flex-algo, whenever an operator assigns >>>> a given label for a prefix >>>> in Algo 0 (call it Label-A0), they must >>>> guarantee that >>>> "Label-A0+offset" for an advertised >>>> flex-algo specific offset is >>>> available to be assigned for the >>>> prefix/flex-algo pair - and this >>>> must be true for all prefixes >>>> advertised in algo 0. >>>> This is certainly possible to do, but >>>> is not guaranteed to be the >>>> case in current deployments. >>>> For example - and this is only an >>>> example...today an operator might >>>> utilize a provisioning tool to assign >>>> prefix-sids for all supported >>>> algorithms on all nodes in the network. >>>> To do this, the tool might maintain a >>>> database of assigned labels. >>>> When provisioning a new >>>> node/prefix/algorithm, the logic in the tool >>>> might simply take the next available >>>> label in the database. >>>> The result of this would not be >>>> consistent with the requirements of >>>> your draft. >>>> Which is why I say in order to deploy >>>> the extension you propose, >>>> such an operator would have to modify >>>> its provisioning tool. >>>> [lc2] There might be some >>>> misunderstanding of our proposal. Let me >>>> give some examples. >>>> Case 1: Flex-Algo only >>>> Prefix offset advertisement: “no” >>>> Adj-sid offset advertisement: yes >>>> In slide 8’s example, FA129 is using >>>> label “402001”, and the >>>> advertisement of this label is using >>>> existing methods. >>>> e.g. SRGB = 400000-460000 >>>> FA129: index 2001 (preferred value), or >>>> one can choose 111, 222 >>>> FA130 (new): index 3001 (preferred >>>> value), or 333, 4444 >>>> This does not change how the operator >>>> to assign label for prefix-sid >>>> with their current method. Any >>>> index/label could be used for FA >>>> prefix within SRGB. >>>> The only change is the Adj-sid label >>>> allocation, but this “mostly” >>>> is only “local” to one node. There is >>>> no effect on global label >>>> allocation. >>>> This draft will be compatible to what >>>> operators are doing today. >>>> Case 2: VFA only >>>> Prefix offset advertisement: yes >>>> Adj-sid offset advertisement: yes >>>> I agree, with VFA, there would be >>>> impact to global allocation to >>>> node-sid/prefix-sid. But VFA is a >>>> totally new concept. No one has >>>> deployed that yet. >>>> There is no impact to operators which >>>> stick to deploy only Flex-algo. >>>> Other case: Flex-Algo w/o Adj-sid offset >>>> Continue the example of >>>> Case#1 above >>>> Another FA131 is added, >>>> but no Adj-sid offset is >>>> advertised >>>> The question would be >>>> * >>>> Either allow this configuration, >>>> and FA131 will fallback using >>>> Algo 0’s adj-sid >>>> * >>>> Or, disallow this configuration >>>> I tend to “allow” such configuration >>>> with mix of FA129, FA130 (with >>>> adj-sid offset) and FA131 (w/o adj-sid >>>> offset) >>>> [/lc2] >>>> Could this be done? Sure. >>>> Do operators want to do this? I do not >>>> know. >>>> But since this would be necessary in >>>> order to use your proposed >>>> extension, it is necessary to gauge >>>> operator enthusiasm for making >>>> such changes in order to know whether >>>> there is any point in >>>> proceeding with your proposal. >>>> > In slide 8 of the below presentation >>>> > >>>> >> > https://urldefense.com/v3/__https://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcUTBr9g0$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNBlx2nlh$> >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$>> >>>> > igp-adv-offset-01 >>>> >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$>> >>>> > >>>> > FA129 is a prefix-sid (400201) >>>> allocated by operator, and it can >>>> be any label. >>>> > There is no connection to how >>>> Adj-sid is derived. >>>> > Per Flex-Algo adj-sid assignment is >>>> not affecting network wide label >>>> > assignment from operation >>>> perspective. Each node could have >>>> different local >>>> > block for such adj-sid assignment. >>>> One might need to estimate >>>> total possible >>>> > number of link in one chassis for >>>> such allocation, or it could be >>>> estimated by >>>> > OS software itself. I also mentioned >>>> in the session, if there is >>>> 100 x FA with >>>> > 1000 links (high end), it is only >>>> 100k labels. Is it difficult to >>>> allocate such. >>>> [LES:] Your proposal does not reduce >>>> the number of labels which need >>>> to be "allocated" and installed in >>>> forwarding, it only reduces the >>>> number of bytes used to advertise this >>>> information in LSPs/LSAs. >>>> [lc2] You are correct. >>>> I think, at the same time, it helps >>>> reducing time for global >>>> convergence since the advertisement >>>> size is smaller, especially in >>>> network with long diameter with multi-hops. >>>> Also, in >>>> >> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcSuumcqQ$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNHGf6W4I$> >>>> >> > <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcSuumcqQ$ >>> >> > <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNHGf6W4I$>> >>> (which you participated in) >>>> >>> >>>> As IS-IS is deployed in greater >>>> scale both in the number of nodes in >>>> an area and in the number of >>>> neighbors per node, the impact of the >>>> historic flooding rates becomes >>>> more significant. Consider the >>>> bringup or failure of a node with >>>> 1000 neighbors. This will result >>>> in a minimum of 1000 LSP updates. >>>> At typical LSP flooding rates >>>> used >>>> today (33 LSPs/second), it would >>>> take 30+ seconds simply to send the >>>> updated LSPs to a given neighbor. >>>> Depending on the diameter of the >>>> network, achieving a consistent >>>> LSDB on all nodes in the network >>>> could easily take a minute or more. >>>> <<< >>>> This proposed draft will certainly help. >>>> [/lc2] >>>> > >>>> > So, this is why I do not understand >>>> your question in full. >>>> > >>>> > If the operator plans to use VFA, >>>> that would be a different >>>> discussion. VFA, >>>> > today, does not exist in deployment. >>>> > >>>> [LES:] My comments here have nothing to >>>> do with VFA. >>>> > [/lc] >>>> > >>>> > Have you discussed this idea with >>>> any operators? >>>> > >>>> > [lc] I include Wei-qiang from China >>>> mobile in this thread. He has >>>> shown his >>>> > need on this kind of solution. >>>> Maybe, he could give his >>>> perspective here. [/lc] >>>> > >>>> > If so, what has been their response? >>>> > If they are open to the idea, how >>>> might they migrate from their >>>> existing >>>> > assignment schemes to an assignment >>>> scheme compatible with the >>>> > proposal? >>>> > >>>> > These are questions that need to be >>>> answered before considering >>>> this idea. >>>> > >>>> > [lc] In slide 8, if you see these >>>> label numbers >>>> > >>>> > Prefix-sid: 400001, 402001, 406001, >>>> 407001 >>>> > Adj-sid: 32, 2032, 6032, 7032 >>>> > >>>> > From operator perspective or >>>> troubleshooting perspective, value >>>> xxx001 >>>> > represent the same node, and value >>>> x032 represent the same link. This >>>> > makes things more organized and >>>> easier to understand. >>>> > >>>> > If all are random labels, I do not >>>> see any benefit at all. >>>> > [/lc] >>>> [LES:] I am not commenting on whether >>>> the label assignment scheme >>>> you propose is better or worse than any >>>> other. >>>> I am only pointing out that you are >>>> imposing new restrictions on how >>>> labels are allocated. >>>> As you are not in charge of how >>>> operators provision their networks >>>> (nor am I), it is presumptuous of you >>>> to think that simply because >>>> you think this is a better way to do >>>> things that operators will be >>>> happy to modify their existing networks >>>> to conform to your proposed >>>> restrictions. >>>> This isn’t academia - you need to vet >>>> this with the operator community. >>>> [lc2] Please refer to the examples at >>>> the top. The picture should be >>>> clear by now. There is no restriction >>>> to what is deployed today. [/lc2] >>>> > >>>> > 2)Section 5 Compatibilty >>>> > >>>> > There is no "compatibility" with >>>> legacy nodes - because all nodes >>>> in the >>>> > network have to have a consistent >>>> understanding of what SID is >>>> assigned to a >>>> > given context (for prefixes and >>>> adjacencies) since they might >>>> need to install >>>> > forwarding entries for that context. >>>> > I do not see any point in deploying >>>> this until all nodes support >>>> it. If you did do >>>> > so, you would need to advertise old >>>> and new forms - which does the >>>> > opposite of what you are trying to >>>> achieve. Instead of reducing >>>> LSP space >>>> > used you would increase it. >>>> > >>>> > [lc] If the operator just plans to >>>> use only Flex-Algo, and no >>>> VFA, it should be >>>> > compatible with legacy >>>> implementation. If legacy nodes do not >>>> understand >>>> > adj-sid offset notation, these nodes >>>> could just ignore it. The >>>> forwarding >>>> > plane should work with co-existence >>>> of old and new nodes. Per >>>> flex-algo adj- >>>> > sid is only local significant to one >>>> node. New nodes should >>>> detect whether >>>> > legacy nodes exist in the network >>>> via such new extension >>>> advertisement. >>>> > And new nodes should use only algo 0 >>>> adj-sid from legacy nodes >>>> for any TI- >>>> > LFA. >>>> [LES:] Consider a network of 100 nodes. >>>> Let's say the "left-hand-side" of the >>>> network consist of legacy >>>> nodes who do not understand your new >>>> advertisements. >>>> The "right-hand-side" of the network >>>> consists of upgraded nodes who >>>> support the new advertisements. >>>> Consider nodes PE-LEFT and PE-RIGHT. >>>> PE-RIGHT advertises a prefix-SID of >>>> 1000 for 2.2.2.2/32 >>>> > <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$>, > and an >>>> offset of 1000 for flex-algo 128. >>>> PE-LEFT supports flex-algo 128 and >>>> wants to install a forwarding >>>> entry for 2.2.2.2 for flex-algo 128. >>>> It looks in the LSPs originated by >>>> PE-RIGHT. It does not see any >>>> assigned SID for 2.2.2.2/32 >>>> >>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$> >>> flex-algo 128. >>>> It cannot create a forwarding entry. >>>> And neither can any other node >>>> in the left hand side of the network. >>>> When PE-RIGHT stops advertising the >>>> explicit prefix SID for >>>> 2.2.2.2/32 >>>> >>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$> >>> Algo 128, all legacy nodes are unable to create >>>> forwarding entries for the prefix/algo >>>> tuple. >>>> This isn’t backwards compatible. >>>> In general, you cannot advertise >>>> information legacy nodes require in >>>> a new container that legacy nodes do >>>> not understand and claim that >>>> you are backwards compatible. >>>> [lc2] Please refers to the examples for >>>> clarification. >>>> 1. >>>> For existing Flex-Algo deployment, >>>> it would be compatible. There >>>> is no change in the container >>>> format on how prefix-sid >>>> 2.2.2.2/32 >>>> >>> <https://urldefense.com/v3/__http:/2.2.2.2/32__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNEj8LL78$> >>> in FA128 is advertised. >>>> 1. >>>> For new VFA, it would not be >>>> compatible. But….it does not mean >>>> that we could not have VFA running >>>> in the same network. >>>> There could be procedures to enhance >>>> such. With your example, one >>>> workaround could be: >>>> For VFA 600, PE-RIGHT detects that >>>> PE-LEFT does not participate in >>>> VFA600 (due to no offset advertisement >>>> seen), >>>> * >>>> Either, it spawns new CSPF for >>>> VFA600 instead of sharing FA129’s >>>> result. Bypass PE-LEFT as a result. >>>> * >>>> Or, it uses legacy node FA129 >>>> prefix-sid and adj-sid as >>>> replacement (note: this method >>>> needs more comment) >>>> In either ways, VFA600 could work >>>> without issue even with legacy >>>> nodes co-existence. >>>> After PE-LEFT upgraded, VFA600 would be >>>> using FA129 CSPF result >>>> instead, and save CPU resources in each >>>> node. >>>> Another question: do we need FAD for >>>> VFA600? Currently, no. Not >>>> mandatory. >>>> But it could be considered if “good to >>>> have” parameters are passed >>>> along with FAD. >>>> [/lc2] >>>> > >>>> > I do not see a major problem. Please >>>> give me an example to >>>> illustrate your >>>> > concern if possible. >>>> > >>>> > Of course, we need to do double >>>> check on the claim and possibly lab >>>> > verification to see if the backward >>>> compatibility could be >>>> achieved. It could >>>> > be vendor specific. >>>> > >>>> > [/lc] >>>> > >>>> > >>>> > What does deserve discussion is a >>>> "hitless migration strategy". >>>> When full >>>> > support is available, if you were to >>>> switch to the new scheme, >>>> you would >>>> > want to do so without changing any >>>> existing SIDs as this would avoid >>>> > forwarding disruption. Which means >>>> operators would have to modify >>>> their >>>> > SID assignment scheme in advance of >>>> deploying the new scheme. >>>> > >>>> > [lc] For VFA, there would be issue >>>> for legacy nodes. I agree. In >>>> this case, >>>> > solution could be >>>> > - either have a fallback >>>> plan for newer nodes if >>>> detection of legacy nodes >>>> > exist in the network. E.g. spawn new >>>> CSPF >>>> > - or, totally not to deploy >>>> VFA unless all nodes are >>>> upgraded. >>>> > >>>> > Section 5 is not updated with VFA >>>> inclusion. >>>> [LES:] My comments have nothing to do >>>> with VFA. >>>> Please reconsider them after you have >>>> understood the backwards >>>> compatibility issues. >>>> > >>>> > [/lc] >>>> > >>>> > 3)Virtual Flex Algorithm >>>> > >>>> > You have introduced a new concept >>>> with very little explanation of >>>> what it is >>>> > nor how it can be supported. >>>> > For example, how would we determine >>>> which nodes support a given VFA? >>>> > Since the algorithm value must be >>>> greater than 255, it cannot be >>>> advertised in >>>> > the existing SR Algorithm sub-TLV. >>>> > >>>> > If you are serious about this idea, >>>> please provide a more complete >>>> > discussion. >>>> > >>>> > [lc] We could illustrate application >>>> examples in next >>>> presentation. For >>>> > ethernet, we have port, and then we >>>> have VLAN and stacked vlan. >>>> History >>>> > has some hints on this. >>>> > >>>> [LES:] You are writing a normative >>>> specification. Hoping that all >>>> readers/implementors have the same >>>> "intuition" isn’t sufficient. >>>> Les >>>> > [/lc] >>>> > >>>> > 4)Section 4.3 >>>> > >>>> > "R" and "N" flags are now defined in >>>> prefix attributes sub-TLV >>>> (RFC7794) >>>> > They were originally defined in the >>>> SR sub-TLV because RFC 7794 >>>> did not exist >>>> > at the time. >>>> > The only reason they continue to >>>> exist in RFC 8667 is for backwards >>>> > compatibility with early >>>> implementation of SR-MPLS based on early >>>> drafts of >>>> > what became RFC 8667. >>>> > Please do not introduce them in new >>>> sub-TLVs - there is no need. >>>> > >>>> > [lc] noted with thanks [/lc] >>>> > >>>> > 5)ADJ-SIDs are NOT allocated from >>>> the SRGB as they are local in >>>> scope. >>>> > They MAY be allocated from the SRLB >>>> - or outside either GB range. >>>> > Please correct the document in this >>>> regard. >>>> > >>>> > [lc] noted [/lc] >>>> > >>>> > Les >>>> > >>>> > > -----Original Message----- >>>> > > From: Lsr <lsr-bounces@ietf.org >>>> <mailto:lsr-bounces@ietf.org> >>>> <mailto:lsr-bounces@ietf.org >>>> <mailto:lsr-bounces@ietf.org>>> >>>> On Behalf Of Acee Lindem >>>> > > Sent: Friday, April 7, 2023 11:43 AM >>>> > > To: Louis Chan <louisc@juniper.net >>>> <mailto:louisc@juniper.net> >>>> <mailto:louisc@juniper.net >>>> <mailto:louisc@juniper.net>>> >>>> > > Cc: lsr <lsr@ietf.org >>>> <mailto:lsr@ietf.org> <mailto:lsr@ietf.org >>>> <mailto:lsr@ietf.org>>> >>>> > > Subject: Re: [Lsr] IETF-116 LSR - >>>> IGP extensions for Advertising >>>> > > Offset for Flex-Algorithm >>>> > > >>>> > > Hi Louis, >>>> > > >>>> > > In the interest of initiating >>>> discussion, I would like to >>>> propose the >>>> > > term "Flex Algorithm Traffic Class >>>> (FATC)" for the sub-division of >>>> > > flex-algorithm traffic referred to >>>> in the draft as “Virtual >>>> Flex Algorithm”. >>>> > > >>>> > > Also, in your terminology, you >>>> refer referred to TLVs and >>>> fields with >>>> > > simply “Algorithm” when RFC 9350 >>>> uses “Flex Algorithm”. >>>> > > >>>> > > Thanks, >>>> > > Acee >>>> > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ >>>> > > Lsr mailing list >>>> > > Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> <mailto:Lsr@ietf.org <mailto:Lsr@ietf.org>> >>>> > > >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr_ >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_ >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_>> >>>> > > _;!!NEt6yMaO-gk!B9ufrV6k- >>>> > >>>> c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F >>>> > > EoixpkxsfMnbqwbR0bpHgoS9E$ >>>> > >>>> > Juniper Business Use Only >>>> Juniper Business Use Only >>>> Juniper Business Use Only >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$ >>>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$> >>>> ------------------------------------------------------------------------------------------------------------------------------------- >>>> 本邮件及其附件含有新华三集团的保密信息，仅限 >>>> 于发送给上面地址中列出 >>>> 的个人或群组。禁止任何其他人以任何形式使用 >>>> （包括但不限于全部或部分地泄露、复制、 >>>> 或散发）本邮件中的信息。如果您错收了本邮件， >>>> 请您立即电话或邮件通知发件人并删除本 >>>> 邮件！ >>>> This e-mail and its attachments contain >>>> confidential information from New H3C, which is >>>> intended only for the person or entity whose >>>> address is listed above. Any use of the >>>> information contained herein in any way >>>> (including, but not limited to, total or partial >>>> disclosure, reproduction, or dissemination) >>>> by persons other than the intended >>>> recipient(s) is prohibited. If you receive >>>> this e-mail in error, please notify the sender >>>> by phone or email immediately and delete it! >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$ >>>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$> >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org <mailto:Lsr@ietf.org> >>>> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$ >>>> >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!DxCsNxydz3b_s_iNl0j_6pyHLD1_vLYmeqwZbd_OBYdhfs3BBaQ8bIXbBsB-4Yigax-NkpPUA1EmCDwYmDMh734fjw$> >>>> Juniper Business Use Only >>>> Juniper Business Use Only >>>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_Odwc0u-ahys$ >> >> >> Juniper Business Use Only
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Liyan Gong
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Peter Psenak
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Louis Chan
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Christian Hopps
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Louis Chan
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Christian Hopps
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… Christian Hopps
- Re: [Lsr] IETF-116 LSR - IGP extensions for Adver… linchangwang
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Les Ginsberg (ginsberg)
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Louis Chan
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Louis Chan
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Christian Hopps
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Louis Chan
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Christian Hopps
- Re: [Lsr] IETF-116 LSR - IGP extensions forAdvert… Louis Chan