Hi ChangWang, For #2, your interpretation is quite close.
Re-visit slide 8. For QOS, local adj-sid are interpreted based on range 2xxx - FA129 related 6xxx - VFA600 related 7xxx - VFA601 related The current node, just examine the top label, could do policing at ingress, and pass it to the right queue at egress interface. Without Flex-Algo, the working mechanism for VFA/Pizza is the same. /Louis -----Original Message----- From: linchangwang <[email protected]> Sent: Thursday, April 13, 2023 6:04 PM To: Peter Psenak <[email protected]>; Louis Chan <[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] Hi Peter , I don't agree that adj sid is not a major contributor. Specifically, we can look at the following two scenarios: 1) flex-algo scenarios: When deploying SR-TE or SRv6 TE, only ADJ-SID on this interface will increase with the number of flex algos increased, so we need to optimize this advertise. 2) without flex-algo scenarios: In scenarios where flex algo is not deployed, the space of LSP can also be greatly reduced through the VFA mechanism. I think one usage scenario for VFA is as follows: DUT1------------------------------DUT2-------------------------------------------------DUT3 Interface 1 interface 1 interface 2 Vfa1-------------------vfa1------------vfa1------------------------------------vfa1 Vfa2-------------------vfa2------------ vfa2------------------------------------vfa2 Vfa3-------------------vfa3------------ vfa3------------------------------------vfa3 Vfa4----------------- -vfa4------------ vfa4------------------------------------vfa4 Vfa: maybe cpu-queue on interface, assign one ADJ-SID to one VFA1 Each label or srv6 end.x sid corresponds to a queue, and VFAR labels are arranged in the sr policy to achieve SR-TE traffic scheduling So , this draft with offset would reduce the refresh requirement. Regards, Changwang -----Original Message----- From: Peter Psenak [mailto:[email protected]] Sent: Thursday, April 13, 2023 5:09 PM To: Louis Chan; linchangwang (RD); 程伟强; Les Ginsberg (ginsbe; Acee Lindem Cc: lsr; Krzysztof Szarkowicz Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm 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-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!Czo2RBiwF_5gMcXG53UyV8Wkh4fKLEl_Sfv1uSpVhhltc1dqF_gl6Hk3u6XedMpZUKPytJDEQVGMrnJx6wW3cbHsfw$ 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-iet > f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!Czo2RBiwF_5gMcXG53UyV8Wkh4fK > LEl_Sfv1uSpVhhltc1dqF_gl6Hk3u6XedMpZUKPytJDEQVGMrnJx6wW3cbHsfw$ >>>> > 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!EX4RtSVg7I0jO4M9ZMrtc >>>> j Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kmvLCcctw$ >>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft >>>> - >>>> cheng-lsr-isis-srv6-sid-block/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrt >>>> 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/11 >>>> 6 >>>> /materials/slides-116-lsr-03-ietf116-__;!!NEt6yMaO-gk!EX4RtSVg7I0jO >>>> 4 M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1knGgpMXww$ >>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/11 >>>> 6 >>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO >>>> - >>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yew >>>> G >>>> B-BleOfrYpSjfI$> >>>> >>>> > igp-adv-offset-01 >>>> >>>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/11 >>>> 6 >>>> /materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO >>>> - >>>> gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yew >>>> 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!EX4RtSVg7I0jO4M9ZMrtcj >>>> Gl2sqxcDIFHFZRnk4pocYHUxv9_pAb8cfeVdGYX_3gOEDi1kl_1f1RjQ$ >>>> >>>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft >>>> - >>>> ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcj >>>> 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/ls >>> r >>> __;!!NEt6yMaO-gk!EX4RtSVg7I0jO4M9ZMrtcjGl2sqxcDIFHFZRnk4pocYHUxv9_pA >>> 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 _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
