Re: [Lsr] IETF-116 LSR - IGP extensions forAdvertisingOffsetforFlex-Algorithm
Hi Chris, The conversation is about "slow router" in transit position. /Louis -Original Message- From: Christian Hopps Sent: Friday, April 21, 2023 5:08 AM To: Louis Chan Cc: Les Ginsberg (ginsberg) ; Liyan Gong ; Christian Hopps ; Ketan Talaulikar ; Krzysztof Szarkowicz ; Robert Raszuk ; linchangwang ; AceeLindem ; 程伟强 ; lsr@ietf.org; Peter Psenak (ppsenak) Subject: Re: [Lsr] IETF-116 LSR - IGP extensions forAdvertisingOffsetforFlex-Algorithm [External Email. Be cautious of content] Louis Chan writes: > Hi All, > > Here is an email I would like to address multiple comments and issues. > > My comment starts with [lc] > > /Louis > > 1. About the weakest control plane > >>>> From Chris. H > > Operators with 1000s of routers and routers with 1000s of interfaces > don't create flooding choke-points, and especially don't then drop > crappy routers in said choke-points. We should not modify our routing > protocols to support such poor network design. > > <<< > > > > [lc] For a network of 1000+ routers, it is usually NOT a greenfield > deployment. It is likely a brownfield deployment. > > There are reasons that these older generations of routers could not be > replaced easily. One common problem is the legacy interface support, > and the port density of such low speed interfaces. I did not say that operators have no slow/crappy routers. > Have you heard that some operators still ask for 1G/10G support in new > core router? > > Therefore, it requires some method to let these "weaker" control > planes to co-exist, plus rather predictable network stability. I'll > show you how it can be achieved. No it doesn't, since slow routers on the network edge work just fine w/o affecting overall stability or flooding speed of the core. Thanks, Chris. [as wg-member] > [/lc] Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
Hi Peter, Such an answer to my questions does not help much. Today, most control plane has multiple GB of memory. 250KB (or 400KB) is a small portion of that. Then, why we still have seen issues in scaling Flex-Algo in reality? For the flooding enhancement, it might help. The problem would be the weakest control plane in the network. You probably need a network simulation to prove the effectiveness. Do you agree? Then, what is required to enhance in OSPF too? For our proposed solution using offset, it "must" help because it reduces the overall size for either ISIS or OSPF deployment scenario, even applicable to the weakest control plane in the network. For other questions listed below, I expect you could answer directly. It is a mutual respect and also be fair to all of us, as I tried to answer all challenging questions whenever I could. Rgds Louis -Original Message- From: Peter Psenak Sent: Friday, April 14, 2023 10:38 PM To: Louis Chan ; Weiqiang Cheng ; 'Peter Psenak' ; 'linchangwang' ; 'Les Ginsberg (ginsbe' ; 'Acee Lindem' Cc: 'lsr' ; Krzysztof Szarkowicz Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm [External Email. Be cautious of content] Louis, On 14/04/2023 16:26, Louis Chan wrote: > Hi Peter (plus all), > > I do not think emotional statement could help. We should stick to facts and > evidence, and be professional. the fact is that with 9k LSP size and 255 LSPs, where each algo ADJ-SID takes up to 9 bytes, you have enough space to encode 250k of them. Do you need more? RFC7356 gives you the answer. thanks, Peter > > Please calm down, and enjoy your weekend first. We should have a drink when > we meet. > > But there are questions in my mind. I must apologize being a bit blunt in > asking following questions. > > > 1. When you said that > "I know bunch that deployed it and are happy with it. They needed few algos, > which is what I consider the right usage of it." > > do these customers deploy the draft " > draft-ietf-lsr-algorithm-related-adjacency-sid"? > > If no, why would you have conclusion that similar problem as Weiqiang have > seen would not happen with your draft? > > > 2. When Weiqiang and others here points out they have live observation and > analysis about the IGP flooding issues in Flex-Algo, why would you deny this > kind of fact? Could you prove that their claims are wrong? > > 3. Also, I have a simple analysis of 2 core nodes. Could you response to > that? Is the analysis reasonable or not? > > 4. I have asked you a direct question of a real "concern", but not a personal > preference > > " 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." > > Is this a real problem? or Is it just a personal preference statement? > Could you be more specific on the problem that you refer to? > > Rgds > Louis > > -Original Message- > From: Peter Psenak > Sent: Friday, April 14, 2023 7:03 PM > To: Weiqiang Cheng ; 'Peter Psenak' > ; Louis Chan ; > 'linchangwang' ; 'Les Ginsberg (ginsbe' > ; 'Acee Lindem' > Cc: 'lsr' ; Krzysztof Szarkowicz > Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset > forFlex-Algorithm > > [External Email. Be cautious of content] > > > Weiqiang, > > On 14/04/2023 12:28, Weiqiang Cheng wrote: >> Hi Peter, >> As far as I know, Flex Algo is not really deployed by operators by now, >> mainly because of the scalability concerns. > > I know bunch that deployed it and are happy with it. They needed few algos, > which is what I consider the right usage of it. > > thanks, > Peter > >> In fact, the Luois team and our team did not know each other before. >> However, we proposed solutions for MPLS-SR and SRv6 respectively almost at >> the same time. So you can see it is a common problem for those operators who >> want to deploy FA at scale. >> >> As discussion in last few days, my observation is that we've agreed the >> problem is there. >> I think it's a good time to address it now.I suggest that We can discuss >> more on the solutions further, instead of discussing the requirements. >> >> B.R. >> Weiqiang Cheng >> >> >> -邮件原件- >> 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Peter Psenak >> 发送时间: 2023年4月14日 16:51 >> 收件人: Louis Chan; linchangwang; 程伟强; Les Ginsberg (ginsbe; Acee Lindem >> 抄送: lsr; Krzysztof Szarkowicz >> 主题: Re: [Lsr] IETF-116 LSR - IG
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm
Hi Les, Thanks for the comment! We will consider adding these consideration points to later draft including error handling. e.g. sending warning if detection of misconfiguration It the customer decided to "turn off" compatibility mode (fallback to FA prefix/adj-sid), it should be allowed. And it has some risk of traffic blackhole, but likely the network operator could discover that easily via traceroute. The benefit of such approach would be useful in large network upgrade, which could take months to complete. Just another trade-off. This approach allows gradual upgrade of the network portion by portion. This is an important consideration of this draft. Other approach might require forklift upgrade which becomes very difficult in live deployment. It might take years to complete upgrade, which is considered impractical. *A small change in one parameter or single bit. A big change in network rollout.* /Louis -Original Message- From: Les Ginsberg (ginsberg) Sent: Friday, April 14, 2023 11:11 PM To: Louis Chan ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz ; Weiqiang Cheng Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm [External Email. Be cautious of content] Louis - Sorry, one more response from me. Your responses below, especially regarding the use of algorithm specific adj-sids in TI-LFA, I could summarize as saying: "Yes - in a partial deployment scenario - you would not have full functionality e.g., legacy nodes would be unable to determine what the algorithm specific adj-sid is - but that is OK - we can live with partial functionality." What this says to me is that you are not just proposing an alternate encoding - you are also proposing a subset of the existing functionality. This is something which needs to be clearly detailed in the draft. Otherwise, casual readers will think that nothing is lost when the encoding efficiency is used. This isn’t a minor point in my view. Les > -Original Message- > From: Louis Chan > Sent: Thursday, April 13, 2023 11:21 PM > To: Les Ginsberg (ginsberg) ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz > ; Weiqiang Cheng > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset for Flex-Algorithm > > Hi Les, > > Thanks for the questions. Really appreciate that. > Questions are the good way to achieve mutual understanding, and it > gives me a chance to re-think what to do next. > > Please see inline [lc4] > > /louis > > -Original Message- > From: Les Ginsberg (ginsberg) > Sent: Thursday, April 13, 2023 10:49 PM > To: Louis Chan ; Acee Lindem > Cc: lsr ; Krzysztof Szarkowicz > ; Weiqiang Cheng > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset for Flex-Algorithm > > [External Email. Be cautious of content] > > > Louis - > > I think our discussion is wrapping up - thanx for the thoughtful exchange. > I still have limited enthusiasm for the draft - but I understand it better > now. > > As others have mentioned in other emails, the big gap here is > describing the problem to be solved. The draft is too weighted on the > protocol extensions and too light on the need for the extensions. > Please consider this if you intend to put out new versions of the draft. > > A few more directed comments on the mechanics - which I am top posting. > > 1)In regards to adj-sid flags (particularly B and P), it is wrong to > think that only one adj-sid/algo may be allocated for a given interface. > Implementations can (and do) allocate multiple. The use case is easier > to justify for protected/non-protected than persistent/non-persistent > - but I am aware of implementations that support all of the above in parallel. > I think this argues for the elimination of the flags field in the offset > sub-TLVs. > Just inherit whatever is advertised in algo 0. > > [lc4] Just inherit Algo 0 is default method. It might not entertain > all the combinations and people' wishes, but it is a trade-off. > > For "B" bits, I might consider adding a flag to disable per Flex-Algo, > but this will apply to all links within that FA. > > I assume that could be other complications or odd cases to fix, but I > believe, as some of us do here, the overall direction is correct. > e.g. "L" bit > > Anyway, thanks for the reminder. > > [lc4] > > > > 2)It is still wrong to say that adj-sid advertisements only impact the > node which advertises them. > Other nodes in the network use the adj-sid advertisements - > specifically in setting up TI-LFAs. So you cannot deploy the new > advertisements safely with only partial deployment. > > [lc4] I have thought about TI-LFA problem since day one. (18
Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm
Hi Christian, Three comments on flooding enhancement - It is discussed in IS-IS domain. How about OSPF? - The proposed offset solution works for both. - I believe that the convergence and stability is limited by the weakness node in the network, especially in transit node position. The flooding might help the high-end node with better control plane, but it might not help the weakest node with limited control plane resource. - The proposed method is not changing the concept on protocol, e.g. using SRGB (especially in different range) plus index is indeed, by nature, similar to offset approach. Rgds louis -Original Message- From: Christian Hopps Sent: Monday, April 17, 2023 8:25 PM To: Peter Psenak Cc: Liyan Gong ; Louis Chan ; Ketan Talaulikar ; Krzysztof Szarkowicz ; Robert Raszuk ; linchangwang ; Acee Lindem ; 程伟强 ; Les Ginsberg(ginsbe ; lsr@ietf.org Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for AdvertisingOffsetforFlex-Algorithm [External Email. Be cautious of content] Peter Psenak writes: > Liyan, > > On 13/04/2023 06:50, Liyan Gong wrote: >> Hi All， >> Thanks for your discussion, here are some informations to help understanding >> better. >> 1. About the application scenario, please refer to the following draft. >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$ >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-gong-teas-hierarchical-slice-solution/__;!!NEt6yMaO-gk!AxEcAQvB8c6kjtHYqogP7npl-rAelfzfp48NvLOQRpmF5h76yJcdofRfkdfPUSk8Wat_OdwcvhIqyg8$ >> > >> Flex-Algo can be associated with the level-1 network slice which provides >> dynamic programming topology. >> The number of Flex-Algos is the same as the number of the level-1 network >> slices. Maybe it can reach dozens. >> 2. About the performance impact, Maybe we can think of it as advertising >> massive routes through multi-pair neighbors in IGP domain. >> Since the advertising and flooding process occupy a lot of router resources, >> Network changes can not be converged in time. >> This will result in wrong traffic forwarding. That is why there is limitation >> on the number of routes in IGP domain. >> According to the anaysis by Changwang in the following email, SIDs take up a >> big part. >> We think it is better if Flex-Algo can be scaled up by optimizing the SIDs >> format without changing the IGP basic mechanism. > > I find the above claim incorrect and misleading. Network convergence is not > the > function of the a amount of data advertised per adjacency. Well if we restrict ourselves to the claim that more data adds to convergence time, then that isn't incorrect. It takes longer to flood more data, and the data must be flooded for convergence, so transitive property here.. more data implies longer convergence time -- unless some other part of convergence is decoupled from flooding and takes even longer than flooding takes, but I don't think that's the case. We've been working on improving flooding speed/efficiency for just this reason. However, the misleading part is maybe true; put differently there's something being left out here. The only reason we are flooding large amounts of data is if large amounts of data changed, this is not really going to happen very often (e.g., when you have a partition repair event, or a new router comes online and just happens to have a ton of data to flood for itself). One could argue that these somewhat uncommon events can (and should) be handled just fine by the flooding improvements we are working on. Why invent application specific protocol changes when we can address the problem with a generic solution that works for all applications? Thanks, Chris. > > thanks, > Peter > > > >> Best Regards, >> Liyan >> 邮件原文 >> *发件人：*Louis Chan >> *收件人：*Ketan Talaulikar >> *抄 送: >> > *Krzysztof Szarkowicz ,Robert Raszuk > ,linchangwang ,Acee Lindem > ,Peter Psenak ," > 程伟强 > " ,"Les Ginsberg(ginsbe" > ,lsr >> *发送时间：*2023-04-13 12:31:12 >> *主题：*Re: [Lsr] IETF- >> 116 LSR - IGP extensions for Advertising OffsetforFlex-Algorithm >> Hi Ketan, >> Just a short response. >> If you remember ATM days, there are VP shaping/policing and VC >> shaping/policing. It can solve quite complicated QOS problem. >> Here we are not doing the costly ATM again. >> With kind of hierarchical QOS readily available in ASIC today, it >> potentially solves some complex multipoint to multipoint QOS problem. >>
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
Hi Peter (plus all), I do not think emotional statement could help. We should stick to facts and evidence, and be professional. Please calm down, and enjoy your weekend first. We should have a drink when we meet. But there are questions in my mind. I must apologize being a bit blunt in asking following questions. 1. When you said that "I know bunch that deployed it and are happy with it. They needed few algos, which is what I consider the right usage of it." do these customers deploy the draft " draft-ietf-lsr-algorithm-related-adjacency-sid"? If no, why would you have conclusion that similar problem as Weiqiang have seen would not happen with your draft? 2. When Weiqiang and others here points out they have live observation and analysis about the IGP flooding issues in Flex-Algo, why would you deny this kind of fact? Could you prove that their claims are wrong? 3. Also, I have a simple analysis of 2 core nodes. Could you response to that? Is the analysis reasonable or not? 4. I have asked you a direct question of a real "concern", but not a personal preference " 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." Is this a real problem? or Is it just a personal preference statement? Could you be more specific on the problem that you refer to? Rgds Louis -Original Message- From: Peter Psenak Sent: Friday, April 14, 2023 7:03 PM To: Weiqiang Cheng ; 'Peter Psenak' ; Louis Chan ; 'linchangwang' ; 'Les Ginsberg (ginsbe' ; 'Acee Lindem' Cc: 'lsr' ; Krzysztof Szarkowicz Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm [External Email. Be cautious of content] Weiqiang, On 14/04/2023 12:28, Weiqiang Cheng wrote: > Hi Peter, > As far as I know, Flex Algo is not really deployed by operators by now, > mainly because of the scalability concerns. I know bunch that deployed it and are happy with it. They needed few algos, which is what I consider the right usage of it. thanks, Peter > In fact, the Luois team and our team did not know each other before. However, > we proposed solutions for MPLS-SR and SRv6 respectively almost at the same > time. So you can see it is a common problem for those operators who want to > deploy FA at scale. > > As discussion in last few days, my observation is that we've agreed the > problem is there. > I think it's a good time to address it now.I suggest that We can discuss more > on the solutions further, instead of discussing the requirements. > > B.R. > Weiqiang Cheng > > > -邮件原件- > 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Peter Psenak > 发送时间: 2023年4月14日 16:51 > 收件人: Louis Chan; linchangwang; 程伟强; Les Ginsberg (ginsbe; Acee Lindem > 抄送: lsr; Krzysztof Szarkowicz > 主题: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset > forFlex-Algorithm > > Louis, > > On 14/04/2023 10:25, Louis Chan wrote: >> Hi Peter, >> >> I do not think we should divert the focus. It is about efficiency in packing >> information. > > trying to change the way the protocol encodes existing data is > something that we should not do, unless there is a blocking issue that > does not allow protocol to work anymore with existing encoding. You > have not provided evidence of that. All the claims so far have been > around the lines of implementation efficiency and can be addressed by > existing protocol mechanism. > >> >> 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. > > maybe you need a new version of the protocol to do what you propose. > > thanks, > Peter > >> >> Rgds >> Louis >> >> -Original Message- >> From: Peter Psenak >> Sent: Friday, April 14, 2023 3:32 PM >> To: Louis Chan ; linchangwang >> ; 程伟强 ; >> Les Ginsberg (ginsbe ; Acee Lindem >> >> Cc: lsr ; Krzysztof Szarkowicz >> >> 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, Lou
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
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 Sent: Friday, April 14, 2023 3:32 PM To: Louis Chan ; linchangwang ; 程伟强 ; Les Ginsberg (ginsbe ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz 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 > Sent: Thursday, April 13, 2023 5:09 PM > To: Louis Chan ; linchangwang > ; 程伟强 ; Les > Ginsberg (ginsbe ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz > 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. >> >>
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm
Hi Les, Thanks for the questions. Really appreciate that. Questions are the good way to achieve mutual understanding, and it gives me a chance to re-think what to do next. Please see inline [lc4] /louis -Original Message- From: Les Ginsberg (ginsberg) Sent: Thursday, April 13, 2023 10:49 PM To: Louis Chan ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz ; Weiqiang Cheng Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm [External Email. Be cautious of content] Louis - I think our discussion is wrapping up - thanx for the thoughtful exchange. I still have limited enthusiasm for the draft - but I understand it better now. As others have mentioned in other emails, the big gap here is describing the problem to be solved. The draft is too weighted on the protocol extensions and too light on the need for the extensions. Please consider this if you intend to put out new versions of the draft. A few more directed comments on the mechanics - which I am top posting. 1)In regards to adj-sid flags (particularly B and P), it is wrong to think that only one adj-sid/algo may be allocated for a given interface. Implementations can (and do) allocate multiple. The use case is easier to justify for protected/non-protected than persistent/non-persistent - but I am aware of implementations that support all of the above in parallel. I think this argues for the elimination of the flags field in the offset sub-TLVs. Just inherit whatever is advertised in algo 0. [lc4] Just inherit Algo 0 is default method. It might not entertain all the combinations and people' wishes, but it is a trade-off. For "B" bits, I might consider adding a flag to disable per Flex-Algo, but this will apply to all links within that FA. I assume that could be other complications or odd cases to fix, but I believe, as some of us do here, the overall direction is correct. e.g. "L" bit Anyway, thanks for the reminder. [lc4] 2)It is still wrong to say that adj-sid advertisements only impact the node which advertises them. Other nodes in the network use the adj-sid advertisements - specifically in setting up TI-LFAs. So you cannot deploy the new advertisements safely with only partial deployment. [lc4] I have thought about TI-LFA problem since day one. (18 months ago) I/We tend to make "fallback" mechanism mandatory, and on by default. In previous PE-LEFT/PE-RIGHT example, if PE-RIGHT is configured with VFA600 (FA129 based) finds another node PE-LEFT (old) only support FA129, - In PE-RIGHT, after calculation of TI-LFA with FA129, VFA600 shares the result and it is also required to pass through PE-LEFT as hop - PE-RIGHT will install TI-LFA based on PE-LEFT FA129's prefix-sid/adj-sid, as fallback. It is a backward compatibility mode which would avoid traffic blackhole. It is not perfect, but it solves 2 issues - transition period before all nodes are upgraded - misconfiguration which might cause traffic blackhole [lc4] 3)You seem to make the assumption that the entire range of MPLS labels (1M) is available for allocation. That is not my experience. Platforms often have limited support. So the assumption that you can sparsely assign label ranges in anticipation of future expansion of scale may not be safe. Maybe the nodes that will need to support such scale will support the full label range - but I am not sure that is a safe assumption. In any case it is a requirement that ought to be called out. [lc4] I understand that. I was asked a similar question due to multiple vendors co-existence in the same network. It requires us to agree on the same SRGB range. But here we are handling industry standard. We should not address specific vendor and specific chipset limitation, unless it is a well known problem across industry. For 20 FA and 300 links, the size of Adj-sid block is only 6k. Rather, I have more worries on the FIB capacity on chipsets, when the network is huge. [/lc4] Thanx again for the useful discussion. [lc4] Same. Thanks for you input. [/lc4] Les > -----Original Message- > From: Louis Chan > Sent: Wednesday, April 12, 2023 8:45 PM > To: Les Ginsberg (ginsberg) ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz > ; Weiqiang Cheng > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset for Flex-Algorithm > > Hi Les, > > Thanks. Please see inline [lc3] > > /Louis > > From: Les Ginsberg (ginsberg) > Sent: Wednesday, April 12, 2023 11:49 PM > To: Louis Chan ; Acee Lindem > Cc: lsr ; Krzysztof Szarkowicz > ; Weiqiang Cheng > > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset for Flex-Algorithm > > [External Email. Be cautious of content] > > Louis – > > I am having increasing difficulty in correlating what you say in this > thread and what is actually
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
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? Rgds Louis -Original Message- From: Peter Psenak Sent: Thursday, April 13, 2023 5:09 PM To: Louis Chan ; linchangwang ; 程伟强 ; Les Ginsberg (ginsbe ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz 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-ietf-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo9HTCDcsgefE_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-iet > f-lsr-isis-fast-flooding/__;!!NEt6yMaO-gk!B1_2-Ht7ugsG_Wz7Ii0QGroMZyo9 > 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 > Sent: Wednesday, April 12, 2023 11:26 PM > To: linchangwang ; 程伟强 > ; Louis Chan ; Les > Ginsberg (ginsbe ; Acee Lindem > > Cc: lsr ; Krzysztof Szarkowicz > 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
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
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 Sent: Thursday, April 13, 2023 6:04 PM To: Peter Psenak ; Louis Chan ; 程伟强 ; Les Ginsberg (ginsbe ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz 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 1interface 1 interface 2 Vfa1---vfa1vfa1vfa1 Vfa2---vfa2 vfa2vfa2 Vfa3---vfa3 vfa3vfa3 Vfa4- -vfa4 vfa4vfa4 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:ppse...@cisco.com] 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
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
Hi Peter, There are practical numbers and theoretical numbers. It does not mean the current practical number is always unchanged over years. In some cases, these numbers could be used up, like 4K VLAN tag. One should not post a strict limit what another one should not use. CPU power and ASIC performance are improving year over year, and it is not impossible to run multiple Flex-Algo in the same network. Those "metric" for each Flex-Algo might be different to what we have today. It could a formula based on various parameters. Rgds Louis -Original Message- From: Peter Psenak Sent: Thursday, April 13, 2023 4:35 PM To: Louis Chan ; Ketan Talaulikar Cc: Krzysztof Szarkowicz ; Robert Raszuk ; linchangwang ; Acee Lindem ; 程伟强 ; Les Ginsberg (ginsbe ; lsr Subject: Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm [External Email. Be cautious of content] Louis, On 13/04/2023 10:13, Louis Chan wrote: > Hi Ketan, > > You asked a good question. > > The following comment is NOT for you. Don’t get me wrong. > > For Flex-Algo, the number is running from 128-255, i.e. max 128 > Flex-Algo in total > > But now, if we say, even 20 FA, is too many, then why 128-255 is > allocated in the first place? > > Why not limited to 32 FA or lower day one in standard? > > We should have a scalable solution to address at least 128 FA running > concurrently in the network. the fact that protocol allows you to run 128, does not mean running that much is a good idea. I would say if you need more than dozen, you are doing something wrong. Similarly, you can run up to 4k MTs in ISIS. Would you run that much in your network? Unlikely. Claiming that we need to change protocol encoding to support 4k MTs is similarly flawed as claiming we need to change it to support 128 algos. thanks, Peter > > Rgds > > Louis > > *From:* Ketan Talaulikar > *Sent:* Thursday, April 13, 2023 1:44 PM > *To:* Louis Chan > *Cc:* Krzysztof Szarkowicz ; Robert Raszuk > ; linchangwang ; Acee > Lindem ; Peter Psenak ; 程伟强 > ; Les Ginsberg (ginsbe > ; lsr > *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset forFlex-Algorithm > > *[External Email. Be cautious of content]* > > Hi Louis, > > One last bit from my side as well ... > > You are correct that this topic is too wide to discuss on this thread. > Also, I sense that you perhaps have the use-case and applicability in > your mind. Could I request you to consider putting that into the draft > so we could understand the motivation? > > Right now, I see on this thread that perhaps your original motivation > for this draft is being mixed up with running a large number of > FlexAlgos in the network. > > Thanks, > > Ketan > > On Thu, Apr 13, 2023 at 10:01 AM Louis Chan <mailto:lou...@juniper.net>> wrote: > > Hi Ketan, > > Just a short response. > > If you remember ATM days, there are VP shaping/policing and VC > shaping/policing. It can solve quite complicated QOS problem. > > Here we are not doing the costly ATM again. > > With kind of hierarchical QOS readily available in ASIC today, it > potentially solves some complex multipoint to multipoint QOS problem. > > But first, it requires labeling the packet, like VCI and VPI. > > I am going to stop here because it would be too much to discuss. > > Rgds > > Louis > > *From:* Ketan Talaulikar <mailto:ketant.i...@gmail.com>> > *Sent:* Thursday, April 13, 2023 12:02 PM > *To:* Louis Chan mailto:lou...@juniper.net>> > *Cc:* Krzysztof Szarkowicz <mailto:kszarkow...@juniper.net>>; Robert Raszuk <mailto:rob...@raszuk.net>>; linchangwang > mailto:linchangwang.04...@h3c.com>>; > Acee Lindem mailto:acee.i...@gmail.com>>; > Peter Psenak mailto:ppse...@cisco.com>>; 程伟强 > <mailto:chengweiqi...@chinamobile.com>>; Les Ginsberg (ginsbe > mailto:ginsb...@cisco.com>>; lsr <mailto:lsr@ietf.org>> > *Subject:* Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising > Offset forFlex-Algorithm > > *[External Email. Be cautious of content]* > > Hi Louis, > > First we need to ascertain if it is necessary before we get things > flooded into IGPs. Then we can get to the evaluation of whether or > how "evil" it is. > > The VLAN analogy seems incorrect to me and a debate on that may be > orthogonal to this topic. I'll wait for the "necessity" to be first > described before taking a bite at this PIZZA ;-) > > Once again, thanks for your work on this document. > &g
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset forFlex-Algorithm
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://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ >>> 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 Sent: Wednesday, April 12, 2023 11:26 PM To: linchangwang ; 程伟强 ; Louis Chan ; Les Ginsberg (ginsbe ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz 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 = 10k bytes >> SRv6： it is 400K+ * 500 = 20k bytes >> If interface mtu=1500, lsp length = 1497 >>LSPs num: >> MPLS-SR：1k bytes/1497 = 66800 lsps >> SRv6： 2k 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 > Num
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm
Hi Les, Thanks. Please see inline [lc3] /Louis From: Les Ginsberg (ginsberg) Sent: Wednesday, April 12, 2023 11:49 PM To: Louis Chan ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz ; Weiqiang Cheng Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm [External Email. Be cautious of content] Louis – I am having increasing difficulty in correlating what you say in this thread and what is actually written in the draft. Please see responses inline. Look for LES2: From: Louis Chan <mailto:lou...@juniper.net> Sent: Tuesday, April 11, 2023 7:46 PM To: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; Acee Lindem <mailto:acee.i...@gmail.com> Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz <mailto:kszarkow...@juniper.net>; Weiqiang Cheng <mailto:chengweiqi...@chinamobile.com> Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm Hi Les, Thanks for the prompt reply. Please see inline for clarification [lc2]. /Louis From: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com> Sent: Tuesday, April 11, 2023 11:03 PM To: Louis Chan <mailto:lou...@juniper.net>; Acee Lindem <mailto:acee.i...@gmail.com> Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz <mailto:kszarkow...@juniper.net>; Weiqiang Cheng <mailto:chengweiqi...@chinamobile.com> Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm [External Email. Be cautious of content] Louis - Please see inline. > -Original Message- > From: Louis Chan <mailto:lou...@juniper.net> > Sent: Monday, April 10, 2023 11:01 PM > To: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com>; Acee Lindem > <mailto:acee.i...@gmail.com> > Cc: lsr <mailto:lsr@ietf.org>; Krzysztof Szarkowicz > <mailto:kszarkow...@juniper.net>; > Weiqiang Cheng <mailto:chengweiqi...@chinamobile.com> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > Hi Les, > > Thanks for your questions. Please see inline [lc] below. > > /Louis > > -Original Message----- > From: Les Ginsberg (ginsberg) <mailto:ginsb...@cisco.com> > Sent: Saturday, April 8, 2023 7:34 AM > To: Acee Lindem <mailto:acee.i...@gmail.com>; Louis Chan > <mailto:lou...@juniper.net> > Cc: lsr <mailto:lsr@ietf.org> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > [External Email. Be cautious of content] > > > OK - since Acee opened the door - here are some comments from me - > starting with the most important. > > (BTW - I still have limited enthusiasm for this draft.) > > 1)The proposal places some restrictions on how operators provision their > network in terms of assigning SIDs and reserving space for future > assignments. > If operators do not use compatible assignment schemes, then this will never > get deployed. It is therefore not enough to come with a nice idea - you must > have some enthusiasm from the operator community. > > > [lc] If the operator only wants to deploy flex-algo, there is no change in > their > Node-sid numbering scheme. For the Adj-sid, these are local labels with local > significant only, and there is no need for any special planning for Adj-sid, > unless you are suggesting they want to make fixed assignment of Adj-sid > label for each link. Even with fixed, the proposed draft has benefit on that. > I > will explain later. > [LES:] Let's discuss this in the context of prefix-sids - the same applies to adj-sids. Today (i.e., in the absence of your proposal) an operator is free to assign any label within the SRGB for a given prefix/algo pair so long as it is not assigned to some other prefix/algo context. Your proposal places some new restrictions. Now, for a given flex-algo, whenever an operator assigns a given label for a prefix in Algo 0 (call it Label-A0), they must guarantee that "Label-A0+offset" for an advertised flex-algo specific offset is available to be assigned for the prefix/flex-algo pair - and this must be true for all prefixes advertised in algo 0. This is certainly possible to do, but is not guaranteed to be the case in current deployments. For example - and this is only an example...today an operator might utilize a provisioning tool to assign prefix-sids for all supported algorithms on all nodes in the network. To do this, the tool might maintain a database of assigned labels. When provisioning a new node/prefix/algorithm, the logic in the tool might simply take the next available label in the database. The result of this would not be consistent with the requirements of your draft. Which is why I say in order to deploy the extension you propose, such an ope
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm
Hi Les, Thanks for the prompt reply. Please see inline for clarification [lc2]. /Louis From: Les Ginsberg (ginsberg) Sent: Tuesday, April 11, 2023 11:03 PM To: Louis Chan ; Acee Lindem Cc: lsr ; Krzysztof Szarkowicz ; Weiqiang Cheng 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 mailto:lou...@juniper.net>> > Sent: Monday, April 10, 2023 11:01 PM > To: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>>; > Acee Lindem > mailto:acee.i...@gmail.com>> > Cc: lsr mailto:lsr@ietf.org>>; Krzysztof Szarkowicz > mailto:kszarkow...@juniper.net>>; > Weiqiang Cheng > mailto:chengweiqi...@chinamobile.com>> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > Hi Les, > > Thanks for your questions. Please see inline [lc] below. > > /Louis > > -Original Message- > From: Les Ginsberg (ginsberg) mailto:ginsb...@cisco.com>> > Sent: Saturday, April 8, 2023 7:34 AM > To: Acee Lindem mailto:acee.i...@gmail.com>>; Louis Chan > mailto:lou...@juniper.net>> > Cc: lsr mailto:lsr@ietf.org>> > Subject: RE: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for > Flex-Algorithm > > [External Email. Be cautious of content] > > > OK - since Acee opened the door - here are some comments from me - > starting with the most important. > > (BTW - I still have limited enthusiasm for this draft.) > > 1)The proposal places some restrictions on how operators provision their > network in terms of assigning SIDs and reserving space for future > assignments. > If operators do not use compatible assignment schemes, then this will never > get deployed. It is therefore not enough to come with a nice idea - you must > have some enthusiasm from the operator community. > > > [lc] If the operator only wants to deploy flex-algo, there is no change in > their > Node-sid numbering scheme. For the Adj-sid, these are local labels with local > significant only, and there is no need for any special planning for Adj-sid, > unless you are suggesting they want to make fixed assignment of Adj-sid > label for each link. Even with fixed, the proposed draft has benefit on that. > I > will explain later. > [LES:] Let's discuss this in the context of prefix-sids - the same applies to adj-sids. Today (i.e., in the absence of your proposal) an operator is free to assign any label within the SRGB for a given prefix/algo pair so long as it is not assigned to some other prefix/algo context. Your proposal places some new restrictions. Now, for a given flex-algo, whenever an operator assigns a given label for a prefix in Algo 0 (call it Label-A0), they must guarantee that "Label-A0+offset" for an advertised flex-algo specific offset is available to be assigned for the prefix/flex-algo pair - and this must be true for all prefixes advertised in algo 0. This is certainly possible to do, but is not guaranteed to be the case in current deployments. For example - and this is only an example...today an operator might utilize a provisioning tool to assign prefix-sids for all supported algorithms on all nodes in the network. To do this, the tool might maintain a database of assigned labels. When provisioning a new node/prefix/algorithm, the logic in the tool might simply take the next available label in the database. The result of this would not be consistent with the requirements of your draft. Which is why I say in order to deploy the extension you propose, such an operator would have to modify its provisioning tool. [lc2] There might be some misunderstanding of our proposal. Let me give some examples. Case 1: Flex-Algo only Prefix offset advertisement: “no” Adj-sid offset advertisement: yes In slide 8’s example, FA129 is using label “402001”, and the advertisement of this label is using existing methods. e.g. SRGB = 40-46 FA129: index 2001 (preferred value), or one can choose 111, 222 FA130 (new): index 3001 (preferred value), or 333, 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
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) Sent: Saturday, April 8, 2023 7:34 AM To: Acee Lindem ; Louis Chan Cc: lsr 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. In slide 8 of the below presentation https://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01 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. 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. [/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: 41, 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] 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. 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.
Re: [Lsr] IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm
Hi Acee, Thanks for the suggestion. The name ""Flex Algorithm Traffic Class (FATC)" looks acceptable to me. However, whatever name I/We pick, there would be disagreement. That is normal. Before a better name is finalized, we could call it nickname “Pizza” if the term, VFA, is not considered comfortable to some of you. We can use these terms interchangeably. And we will make some change in later draft. The base Algo could be 128-255 or 0. Algo 0 is not included in the -02 draft. With the inclusion of Algo 0, there could be some impact to the re-naming of the term. Rgds Louis -Original Message- From: Acee Lindem Sent: Saturday, April 8, 2023 2:43 AM To: Louis Chan Cc: lsr Subject: Re: IETF-116 LSR - IGP extensions for Advertising Offset for Flex-Algorithm [External Email. Be cautious of content] 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 Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] [lsr] draft-chan-lsr-igp-adv-offset
Hi, We have submitted a draft on a topic "IGP extensions for Advertising Offset for Flex-Algorithm" https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/ Basically, it provides a very efficient method to announce per Flex-Algo Adj-SID. The size of announcement of Adj-SID is independent of number of links in the router, which makes it very compact. And this provides a predictable way for a node to deduct the required Flex-Algo Adj-SID for the remote node. Rgds Louis Juniper Business Use Only ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
