Louis, I must be missing something obvious ...
Consider the SR-MPLS case and 5 nodes on which I need specific PHB. Does this mean that each packet requires at least *10 labels* on the stack imposed on ingress ? Many thx, R. On Thu, Apr 13, 2023 at 3:35 PM Louis Chan <louisc= [email protected]> wrote: > 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 >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
