Hi Peter, I do not think we should divert the focus. It is about efficiency in packing information.
If some important info is required to pass as "necessary evil", then it should. Actually, I am looking forward to applying similar method for other metric or ASLA, proposed by someone, and not necessary by me. And I have seen some drafts are addressing this kind of issues. e.g. For FA200 and FA201, most link metrics are sharing the same values, but only 5% difference in order to achieve some desired behavior. In this case, we should find a way to pack it efficiently. Rgds Louis -----Original Message----- From: Peter Psenak <[email protected]> Sent: Friday, April 14, 2023 3:32 PM To: Louis Chan <[email protected]>; linchangwang <[email protected]>; 程伟强 <[email protected]>; Les Ginsberg (ginsbe <[email protected]>; Acee Lindem <[email protected]> Cc: lsr <[email protected]>; Krzysztof Szarkowicz <[email protected]> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm [External Email. Be cautious of content] Louis, On 14/04/2023 07:38, Louis Chan wrote: > Hi Peter, > > For Adj-sid and additional TE requirement, I am not sure what you refer to. > TE requirement or metric requirement? If it is metric related, we have ASLA > draft to address some TE related problem. > (To me, to reduce ASLA advertisement is required too.) > > What TE problem are you referring to? Could you give an example to illustrate > you concern? there are many TE attributes flooded for TE purposes, e.g., reserved/unreserved bandwidth (per pool), SRLGs, affinities, ... You are picking Ajd-SID, but that is not the only thing that is advertised per link. You may have many SRLGs, many affinities, etc. Peter > > Rgds > Louis > > -----Original Message----- > From: Peter Psenak <[email protected]> > Sent: Thursday, April 13, 2023 5:09 PM > To: Louis Chan <[email protected]>; linchangwang > <[email protected]>; 程伟强 <[email protected]>; Les > Ginsberg (ginsbe <[email protected]>; Acee Lindem > <[email protected]> > Cc: lsr <[email protected]>; Krzysztof Szarkowicz <[email protected]> > Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset forFlex-Algorithm > > [External Email. Be cautious of content] > > > Loius, > > there are many reasons why we need to advertise additional data for adjacency > - TE being a major one. You are trying to optimize the Adj-SID only, which is > not the major contributor anyway. The problem is not specific to Adj-SID. > > In terms of convergence, if you are worried about the flooding speed, there > is a draft in progress: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet > f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo9 > HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$ > > thanks, > Peter > > > > On 13/04/2023 10:52, Louis Chan wrote: >> Hi Peter/all, >> >> Here I do a simple analysis on this scaling issue. >> >> 1. Assume a network with these parameters >> - 20 x Flex-algo >> - 2 x core nodes with 1,000 links >> - network diameter with 5 hops >> >> 2. Just check out the additional advertisement size from core nodes >> following ChangWang example. >> >> For 1 core node, >> n x 20 x 1000 >> MPLS-SR：If n = 10 bytes, it is 200K bytes per core node >> >> With 2 core nodes, it is 400KB in total >> >> LSP num: 400KB/1500 = 267 lsps, at least >> >> 3. About the delivery/flooding rate, from >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie >> t >> f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo >> 9 HTCDcsgefE_pSNK-2bIfNoekducPbd5X3kQ5eMiRk98Jb_PYYg$ >>>>> >> 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 >> <--- 1000 adj links >> in a minimum of 1000 LSP updates. At typical LSP flooding rates used >> <--- imply 1000 LSP updates >> today (33 LSPs/second), it would take 30+ seconds simply to send the >> <--- 33lsp/s >> 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. >> <--- at least double >> <<< >> >> 267/33 = 8.1 sec >> >> >> With a network diameter of 5, the additional time for delivering the >> consistent LSDB to all remote nodes = >> m x 8.1 sec, where 1 < m < 5 due to inefficiency or implementation issue >> >> It is likely 16+ sec, according to the above description in that draft. >> >> If using offset solution, it is around 0.008sec x 2 = 0.016sec in >> additional. This number is small. >> >> Additional of 16+ sec is significant in global convergence time. >> >> 4. This model/example does not include nodes from second layer, which also >> has 2 x 1,000 adj-sid in the reverse direction. The total number would be >> estimated bigger than 30+ sec. >> >> Should this be improved? >> >> 5. Flooding could be in all directions. Larger size of advertisement could >> delay some important update in busy period. i.e. smaller size in >> advertisement is better. >> And I assume this draft with offset would also reduce the refresh >> requirement. >> >> Rgds >> Louis >> >> -----Original Message----- >> From: Peter Psenak <[email protected]> >> Sent: Wednesday, April 12, 2023 11:26 PM >> To: linchangwang <[email protected]>; 程伟强 >> <[email protected]>; Louis Chan <[email protected]>; Les >> Ginsberg (ginsbe <[email protected]>; Acee Lindem >> <[email protected]> >> Cc: lsr <[email protected]>; Krzysztof Szarkowicz >> <[email protected]> >> Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising >> Offset forFlex-Algorithm >> >> [External Email. Be cautious of content] >> >> >> Hi Changwang, >> >> please see inline ##PP3: >> >> On 12/04/2023 16:46, linchangwang wrote: >>> Hi Peter, >>> >>> >>> Please see inline [changwang lin]. >>> >>>> 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. >>> >>> [changwang lin] >>> This problem exists in actual operator networking, it can be calculated >>> based on an actual network as follows: >>> One network with 200 nodes >>> One node with 20 interfaces >>> One interface with 32 flex algos Each interface is assigned two >>> types of end. x, one PSP and one non PSP, with each end. x occupying >>> 30 bytes An nbr tlv with basic bandwidth, EAG, and interface address >>> is approximately 140 bytes Number of LSPs in the entire network: 140 >>> * 20 * 32 * 200/1497=12000 LSPs >>> >>> The performance of IGP has always been affected by the size of the >>> entire network's LSDB, and even if the periodic flooding time is reduced, >>> there will still be convergence issues. >> >> ##PP3 >> I don't see any relationship between the convergence and the fact that you >> have to advertise 20 ADJ-SIDs per link. If there is one, it's an >> implementation problem. >> >> >>> >>>> >>>> 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. >>> [changwang lin] >>> In the actual deployment of MPLS-SR and SRv6 networks, as the number >>> of flex algos and interfaces increases, the space occupied by adj-sids >>> becomes larger and larger. >>> This is the actual problem when deploying flex algos. >> >> ##PP3 >> I don't see any protocol problem. >> >> >>> >>>> 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. >>> >>> [changwang lin] >>> In actual deployment, a flex algo corresponds to the SLA >>> requirements of a service, such as different bandwidth guarantees, >>> 128 flex algos can correspond to 128 service requirements. >>> When the flex algo specification increases, the corresponding number of >>> LSPs rapidly increases, making it impossible to deploy large flex algo >>> applications. >>> And the mechanism of this draft can greatly improve the space utilization >>> of LSP.. >> >> ##PP3 >> I appreciate your effort, but I don't believe the proposed compression is >> needed, nor that it addresses the problem you have. >> >> The amount of data being flooded per adjacency may potentially be large and >> Adj-SIDs only represent a fraction of it - even with 32 Adj-SIDs per link >> you are not hitting any protocol limitation. >> >> thanks, >> Peter >> >> >>> >>> thanks, >>> Changwang lin >>> >>> >>> >>>> thanks, >>>> Peter >>> >>>> >>>> >>>> thanks, >>>> Changwang lin >>>> >>>> >>>> -----Original Message----- >>>> From: Lsr [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 >>>>> - >>>>> c >>>>> heng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrt >>>>> c j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ >>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf >>>>> t >>>>> - >>>>> cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMr >>>>> t c jGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ > >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Weiqiang Cheng >>>>> >>>>> >>>>> >>>>> ----邮件原文---- >>>>> *发件人：*Louis Chan <[email protected]> >>>>> *收件 >>>>> 人：*"Les Ginsberg (ginsberg)" <[email protected]>,Acee Lindem >>>>> <[email protected]> >>>>> *抄 送: >>>>> *lsr <[email protected]>,Krzysztof Szarkowicz >>>>> <[email protected]>,Weiqiang Cheng <[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]> >>>>> *Sent:* Tuesday, April 11, 2023 11:03 PM >>>>> *To:* Louis Chan <[email protected]>; Acee Lindem >>>>> <[email protected]> >>>>> *Cc:* lsr <[email protected]>; Krzysztof Szarkowicz >>>>> <[email protected]>; Weiqiang Cheng >>>>> <[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]>> >>>>> >>>>> > Sent: Monday, April 10, 2023 11:01 PM >>>>> >>>>> > To: Les Ginsberg (ginsberg) <[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 >>>>> >>>>> > >>>>> >>>>> > Hi Les, >>>>> >>>>> > >>>>> >>>>> > Thanks for your questions. Please see inline [lc] below. >>>>> >>>>> > >>>>> >>>>> > /Louis >>>>> >>>>> > >>>>> >>>>> > -----Original Message----- >>>>> >>>>> > From: Les Ginsberg (ginsberg) <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> > Sent: Saturday, April 8, 2023 7:34 AM >>>>> >>>>> > To: Acee Lindem <[email protected] >>>>> <mailto:[email protected]>>; Louis Chan <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> > Cc: lsr <[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/1 >>>>> 1 >>>>> 6 >>>>> /materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!EX4RtSVg7I0j >>>>> O >>>>> 4 >>>>> M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1knGgpMXww$ >>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1 >>>>> 1 >>>>> 6 >>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa >>>>> O >>>>> - >>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye >>>>> w >>>>> G >>>>> B-BleOfrYpSjfI$> >>>>> >>>>> > igp-adv-offset-01 >>>>> >>>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/1 >>>>> 1 >>>>> 6 >>>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMa >>>>> O >>>>> - >>>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79ye >>>>> w >>>>> G >>>>> B-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!EX4RtSVg7I0jO4M9ZMrtc >>>>> j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$ >>>>> >>>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draf >>>>> t >>>>> - >>>>> ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtc >>>>> j G l2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$ > >>>>> (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, 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 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 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 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]>> >>>>> On Behalf Of Acee Lindem >>>>> >>>>> > > Sent: Friday, April 7, 2023 11:43 AM >>>>> >>>>> > > To: Louis Chan <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> > > Cc: lsr <[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]> >>>>> >>>>> > > >>>>> >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>> l >>>>> s >>>>> r_ >>>>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ >>>>> l >>>>> s >>>>> r_> >>>>> >>>>> > > _;!!NEt6yMaO-gk!B9ufrV6k- >>>>> >>>>> > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F >>>>> >>>>> > > EoixpkxsfMnbqwbR0bpHgoS9E$ >>>>> >>>>> > >>>>> >>>>> > Juniper Business Use Only >>>>> >>>>> Juniper Business Use Only >>>>> >>>>> >>>>> Juniper Business Use Only >>>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>> s >>>> r >>>> __;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_p >>>> A >>>> b >>>> 8cfeVdGYX_3gOEDi1kljo7ufGA$ >>>> ------------------------------------------------------------------- >>>> - >>>> - >>>> ---------------------------------------------------------------- >>>> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 >>>> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 >>>> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 >>>> 邮件！ >>>> 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! >>>> >>> >>> >> >> >> Juniper Business Use Only >> > > > Juniper Business Use Only > Juniper Business Use Only _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
