Hi, > On 2023 -Apr-12, at 17:48, Peter Psenak <[email protected]> wrote: > > [External Email. Be cautious of content] > > > Krzysztof, > > On 12/04/2023 17:41, Krzysztof Szarkowicz 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. > > if you need 200, you are doing something that the flex-algo was not > designed for.
[Krzysztof] Hence the proposed extensions. > > thanks, > Peter >> >> Thanks, >> Krzysztof >> >> >>> On 2023 -Apr-12, at 17:13, Robert Raszuk <[email protected] >>> <mailto:[email protected]>> 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:52 PM linchangwang >>> <[email protected] <mailto:[email protected]>> 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:[email protected] >>> <mailto:[email protected]>] >>> *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 <[email protected] >>> <mailto:[email protected]>> 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:[email protected] >>> <mailto:[email protected]>] 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!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLud7_hgPG$ >>> >>> <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!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLud7_hgPG$ >>> >>> <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 <[email protected] >>> <mailto:[email protected]>> >>> *收件 >>> 人：*"Les Ginsberg (ginsberg)" <[email protected] >>> <mailto:[email protected]>>,Acee Lindem <[email protected] >>> <mailto:[email protected]>> >>> *抄 送: >>> *lsr <[email protected] <mailto:[email protected]>>,Krzysztof >>> Szarkowicz <[email protected] >>> <mailto:[email protected]>>,Weiqiang Cheng >>> <[email protected] >>> <mailto:[email protected]>> >>> *发送时间：*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) <[email protected] >>> <mailto:[email protected]>> >>> *Sent:* Tuesday, April 11, 2023 11:03 PM >>> *To:* Louis Chan <[email protected] >>> <mailto:[email protected]>>; Acee Lindem <[email protected] >>> <mailto:[email protected]>> >>> *Cc:* lsr <[email protected] <mailto:[email protected]>>; Krzysztof >>> Szarkowicz >>> <[email protected] <mailto:[email protected]>>; >>> Weiqiang Cheng >>> <[email protected] >>> <mailto:[email protected]>> >>> *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 <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >>> > Sent: Monday, April 10, 2023 11:01 PM >>> >>> > To: Les Ginsberg (ginsberg) <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; Acee >>> Lindem >>> >>> > <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> > Cc: lsr <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; Krzysztof >>> Szarkowicz <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>>; >>> >>> > Weiqiang Cheng <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >>> > 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) <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> > Sent: Saturday, April 8, 2023 7:34 AM >>> >>> > To: Acee Lindem <[email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>>; >>> Louis Chan <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> > Cc: lsr <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> > 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!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLuU5U5z5u$ >>> >>> <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!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLuaxQnPEu$ >>> >>> <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!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLuaxQnPEu$ >>> >>> <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 <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> On Behalf Of Acee Lindem >>> >>> > > Sent: Friday, April 7, 2023 11:43 AM >>> >>> > > To: Louis Chan <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> >>> >>> > > Cc: lsr <[email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> >>> > > 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 >>> >>> > > [email protected] <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>> >>> > > >>> 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 >>> [email protected] <mailto:[email protected]> >>> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLuY-B3ggG$ >>> >>> <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 >>> [email protected] <mailto:[email protected]> >>> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FM_MkqhLkdNEGVdKyxKlnrra010g32y-qn_vw0NIILGYaTOh3oyXBA-ynDqWN1lzswoDPhn8hTkLuY-B3ggG$ >>> >>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!GCoxXhuL7ryqRodFUI2f-GPQa1_Vjs9WLIB_XJtQUiKVcm6Yrxqx5p-_PmGOQFNseVacNf7mx4QUNLUwWHuZ$> >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
