Hi Weiqiang, I’m also curious as to how you are using 20 different flex algorithms. Is this just a hypothetical scenario to illustrate the mathematics or do you have an actual use case?
> On Apr 12, 2023, at 09:31, Peter Psenak <[email protected]> wrote: > > Changwang, > > please see inline (##PP2): > > > On 12/04/2023 15:13, linchangwang wrote: >> Hi Peter >> Please see inline [changwang lin]. >>> We've met the same problem when applying Flex Algo in SRv6 network. >> what problem exactly, can you please describe it? >> [changwang lin] >> Advertisement size of per Flex-Algo Adj-SID in the network >> Related to F(# of node, # of FA, # of links) >> For a node with 1,000 links and 20 Flex-Algo >> n x 20 x 1000 >> MPLS-SR：If n = 10 bytes, it is 200K bytes >> SRv6： If n = 24 bytes, it is 400K+ bytes >> If 500 nodes: >> MPLS-SR：it is 200K*500 = 100000k bytes >> SRv6： it is 400K+ * 500 = 200000k bytes >> If interface mtu=1500, lsp length = 1497 >> LSPs num: >> MPLS-SR：10000k bytes/1497 = 66800 lsps >> SRv6： 20000k bytes/1497 = 160320 lsps >> The number of LSPs is too large, and IS-IS needs to periodically refresh >> LSPs, >> resulting in a decrease in ISIS performance and unstable network operation. > > ##PP2 > above is hardly a realistic estimation. > > In a network with 1k nodes, not every node will have 1k links. > > Advertising large number of LSPs is not caused by Adj-SIDs. > With TE enabled the amount of data flooded per link is larger than > advertisement of the 20 Adj-SID. The problem you are highlighting is not > specific to Adj-SIDs, it's generic. > > LSP refresh time can be set to 18 hours and any reasonable implementation > does not refresh all LSPs at the same time. > >> So we need to optimize on the control surface to save LSP space. > > ##PP2 > with all the respect, I don't agree. The problem as you described it does not > exist. > >> Through the optimization notification mechanism mentioned in these two >> documents, >> we have greatly saved LSP space for IS-IS and improved the performance of >> IS-IS flex algo in large-scale networking. >> At the same time, through the VFA mechanism, in other non flex algo >> application scenarios, >> such as network slicing scenarios, the LSP space of IS-IS can also be saved > > ##PP2 > it seems to me you are trying to fix the implementation problem with the > protocol changes, which is never a good idea. > > thanks, > Peter > >> thanks, >> Changwang lin >> -----Original Message----- >> From: Lsr [mailto:[email protected]] 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://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/ >>> <https://datatracker.ietf.org/doc/draft-cheng-lsr-isis-srv6-sid-block/> >>> >>> >>> >>> 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://datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116- >>> >>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$> >>> >>> > igp-adv-offset-01 >>> >>> <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/116/materials/slides-116-lsr-03-ietf116-igp-adv-offset-01__;!!NEt6yMaO-gk!Bl7Swe9ql9VT0qGkD6FoZZzTWT2fmIx55eSncdmMgoCJetJ5-80micuqnqk79yewGB-BleOfrYpSjfI$> >>> >>> > >>> >>> > 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://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/ >>> <https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/> >>> (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/lsr_ >>> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr_> >>> >>> > > _;!!NEt6yMaO-gk!B9ufrV6k- >>> >>> > c7mtP9JUiXbrF3NCkZ15_UMLBjV_fnJovfz18M5VkkI2F >>> >>> > > EoixpkxsfMnbqwbR0bpHgoS9E$ >>> >>> > >>> >>> > Juniper Business Use Only >>> >>> Juniper Business Use Only >>> >>> >>> Juniper Business Use Only >>> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> ------------------------------------------------------------------------------------------------------------------------------------- >> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 >> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 >> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 >> 邮件！ >> This e-mail and its attachments contain confidential information from New >> H3C, which is >> intended only for the person or entity whose address is listed above. Any >> use of the >> information contained herein in any way (including, but not limited to, >> total or partial >> disclosure, reproduction, or dissemination) by persons other than the >> intended >> recipient(s) is prohibited. If you receive this e-mail in error, please >> notify the sender >> by phone or email immediately and delete it!
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
