Speaking as WG member: Actually, when I thought about this a bit more I concluded that using a constraint would take configuration on more nodes than the node simply not participating in the algorithm.
For the FAD to be changed, every router in the IGP domain advertising the FAD would need to be updated with the node exclusion tag. However, for a node to node to not participate in an algorithm, then only that node's configuration need be changed. Now I know one could come up with various scenarios where there are groups of nodes with a certain tag already configured but it is hard for me to envision the underlying use cases for these. Thanks, Ace > On Feb 19, 2025, at 5:38 AM, Peter Psenak <[email protected]> wrote: > > Liyan, > > On 19/02/2025 11:33, Liyan Gong wrote: >> Hi Acee and Peter, >> >> Thank you so much Acee for changing the subject. >> >> Peter，I'm sorry that I didn't fully understand what you meant. >> >> How can we cease the participation in the Flex-Algo without changing the >> configuration? > nothing stops an implementation to start/stop advertising algo participation > on any event. >> >> In my understanding, Based on the Proposal 1, no matter what event triggers >> it, it ultimately needs to be implemented through the configuration. > no, that is not true. There is no RFC that mandates that. You are free to > change it based on whatever condition you want. > thanks, > Peter >> Could you please elaborate on this in more detail? Thank you again for your >> patience. >> >> >> Best Regards, >> Liyan >> >> >> ----邮件原文---- >> 发件人：Acee Lindem <[email protected]> >> 收件人：Peter Psenak <[email protected]> >> 抄 送: Liyan Gong <[email protected]>,"Les Ginsberg (ginsberg)" >> <[email protected]>,shraddha <[email protected]>,lsr >> <[email protected]>,draft-ietf-lsr-igp-f >> <[email protected]> >> 发送时间：2025-02-18 19:38:01 >> 主题：[Lsr] Utility of "Flexible Algorithms Exclude Node" - >> draft-gong-lsr-flex-algo-exclude-node-00 >> >> As WG Co-Chair, changing subject. Please continue with this thread. >> >> Thanks, >> Acee >> >> > On Feb 18, 2025, at 4:01 AM, Peter Psenak wrote: >> > >> > Hi Liyan, >> > >> > please see inline: >> > >> > On 18/02/2025 09:56, Liyan Gong wrote: >> >> Hi Peter, >> >> >> >> Thank you very much for your response. >> >> I understand your perspective, In fact, I agree with you to a certain >> >> extent. >> >> At first glance, the proposed solution may not appear advantageous in >> >> terms of configuration. >> >> However, its strengths lie more in its simplicity of deployment and >> >> flexibility in adjustments. >> >> For example, regarding the second advantage mentioned in the email >> >> below，**Proposal 2** allows for dynamic adjustment of calculation results >> >> without modifying the configuration. In comparison,would **Proposal 1** >> >> require manual configuration changes to achieve similar flexibility? >> > no, implementation is free to cease the participation in any algo based on >> > any event, it is not restricted to the configuration. >> > thanks, >> > Peter >> >> >> >> Again,I truly appreciate the time you took to share your insights and >> >> hope we can continue this discussion. >> >> >> >> Best Regards, >> >> Liyan >> >> >> >> >> >> ----邮件原文---- >> >> 发件人：Peter Psenak >> >> 收件人：Liyan Gong ,Acee Lindem >> >> 抄 送: "Les Ginsberg (ginsbe" ,shraddha ,lsr ,draft-ietf-lsr-igp-f >> >> 发送时间：2025-02-18 15:50:42 >> >> 主题：Re: [Lsr] Re: Working Group Last Call of "IGP >> >> FlexibleAlgorithmsReverse Affinity >> >> Constraint"-draft-ietf-lsr-igp-flex-algo-reverse-affinity-03 >> >> >> >> Liyan, >> >> >> >> please see inline (##PP): >> >> >> >> On 18/02/2025 04:19, Liyan Gong wrote: >> >> Dear All, >> >> Thank you for raising this question. >> >> Yes,this >> >> draft（https://datatracker.ietf.org/doc/draft-gong-lsr-flex-algo-exclude-node/）was >> >> discussed at the IETF 121 meeting and and there were some >> >> debates. >> >> As a co-author of the draft, I appreciate the opportunity >> >> to clarify and discuss it here. Also，we greatly appreciate any >> >> further feedback or suggestions. >> >> >> >> The draft aims to achieve the exclusion of specific nodes within >> >> a Felx-Algo(FA) by introducing additional constraint calculation >> >> conditions. >> >> >> >> To facilitate the discussion, let me refer to: >> >> - **Proposal 1**: The existing approach where nodes do >> >> not participate in FA settings. >> >> - **Proposal 2**: The proposed solution described in the >> >> draft. >> >> >> >> In my view, the most fundamental difference between the two >> >> lies in the decision-making process: - In **Proposal >> >> 1**, the decision-making is distributed across individual network >> >> devices. >> >> - In **Proposal 2**, the decision-making is centralized >> >> on the device performing the route calculation, while other >> >> devices only need to advertise their attribute information. >> >> ##PP >> >> "Proposal 2" is based on the individual nodes advertising the >> >> admin-tag: >> >> >> >> "If a node >> >> advertises an Admin-Tag value that needs to be excluded, that node >> >> is removed from the Flex-Algo topology." >> >> So it is distributed in a nature. And it is even worse than using >> >> the algo participation. >> >> With algo participation, if you don't want a node to participate, >> >> the node simply does not advertise anything. >> >> With your proposal, the node needs to advertise the algo >> >> participation plus the admin tag to be excluded from the algo. So it >> >> uses two advertisements that together achieve the same outcome as not >> >> sending any of them. >> >> >> >> >> >> >> >> **Proposal 2** offers several advantages: 1. >> >> **Scalability**: It is more friendly to large-scale networks. In >> >> scenarios where multiple nodes need to be excluded, we can >> >> uniformly set the attributes of these nodes and exclude them >> >> based on these attributes. >> >> >> >> ##PP >> >> if you want nodes to be excluded from the algo, you simply do not >> >> configure them to participate. How much simple that can be? >> >> With your proposal, you have to configure them to participate and >> >> then with some extra attribute that they need to advertise to be >> >> excluded. >> >> >> >> 2. **Dynamic Adjustments**: It allows for exclusion >> >> within specific ranges, making it more adaptable to dynamic >> >> network changes. For example, a node can be excluded when its CPU >> >> utilization exceeds 80%, and reincluded once it falls below this >> >> threshold. >> >> ##PP >> >> you can cease participation in algo in any time, based on any >> >> trigger (not that I recommend that), so you are not adding anything >> >> new. >> >> >> >> 3. **Alignment with Admin Tag and FA concept**: Inspired >> >> by the admin tag draft, we chose admin tags as the carrier for >> >> this attribute information, which aligns with the idea of using >> >> admin tags to select route and path. >> >> ##PP >> >> I see absolutely no benefit in "alignment of admin tag and FA >> >> concept" unless you bring any new functionality, which you clearly >> >> don't. >> >> >> >> >> >> Overall, I think **Scheme 2** not only enhances the functionality >> >> of FA but also makes its deployment more flexible, aligning well >> >> with the current FA constraint-based path computation concept. >> >> ##PP >> >> Overall I think that your proposal bring no new functionality. >> >> Contrary, it proposes to achieve the existing functionality with >> >> some extra advertisement, which makes no sense to me. >> >> thanks, >> >> Peter >> >> >> >> Regarding the strict order of FA computation constraints >> >> discussed in the emails, I agree that a registration mechanism is >> >> necessary. This draft also requires such a mechanism, and we will >> >> continue to follow up on IANA updates and revise the draft >> >> accordingly. >> >> >> >> Best Regards, >> >> Liyan >> >> >> >> ----邮件原文---- >> >> 发件人：Peter Psenak >> >> 收件人：Acee Lindem >> >> 抄 送: "Les Ginsberg (ginsberg)" ,shraddha ,lsr >> >> ,"[email protected]" >> >> 发送时间：2025-01-29 16:45:32 >> >> 主题：[Lsr] Re: Working Group Last Call of "IGP Flexible Algorithms >> >> Reverse Affinity Constraint" - >> >> draft-ietf-lsr-igp-flex-algo-reverse-affinity-03 >> >> >> >> Hi Acee, >> >> >> >> On 28/01/2025 20:14, Acee Lindem wrote: >> >> Ok - I guess you can add a registry now >> >> if you want. >> >> I would, it's a clear reference of all rules we have defined at >> >> any point in time. >> >> >> >> We don’t have any WG drafts adding >> >> flex-algo rules but we have >> >> draft-gong-lsr-flex-algo-exclude-node as an individual draft. >> >> I seem to recall discussion as to whether this draft >> >> is necessary since a node could be excluded by not >> >> participating in the flex-algo. >> >> that draft is not needed. >> >> thanks, >> >> Peter >> >> >> >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> On Jan 28, 2025, at 13:58, Peter Psenak >> >> wrote: >> >> >> >> Hi Acee, >> >> >> >> we require strict ordering - it may not >> >> be necessary now, but in the future we >> >> may introduce something that will need >> >> it, so we started to enforce it from day 1. >> >> >> >> thanks, >> >> Peter >> >> >> >> >> >> On 28/01/2025 19:54, Acee Lindem wrote: >> >> Speaking as WG member: >> >> >> >> Hi Les, Peter, Shraddha, >> >> >> >> On Jan 24, 2025, at 10:34 AM, >> >> Les Ginsberg (ginsberg) >> >> wrote: >> >> >> >> I have reviewed the draft and >> >> support moving ahead with >> >> publishing this as an RFC. >> >> >> >> The primary use case is well >> >> described in Section 3 of the >> >> draft. Note this is NOT, as some folks have >> >> mistakenly inferred from the draft >> >> title, aimed at multicast RPF >> >> use cases. >> >> >> >> As regards the evolving set of >> >> rules for flex-algo >> >> calculations, I think the current model of adding >> >> an appendix with the full list >> >> of updated rules is problematic. >> >> We now have three documents >> >> which define rules: >> >> >> >> RFC 9350 >> >> draft-ietf-lsr-flex-algo-bw-con >> >> >> >> draft-ietf-lsr-igp-flex-algo-reverse-affinity >> >> >> >> Each document is accurate based >> >> on the rules defined at the time >> >> of publication. >> >> But as each document is >> >> published - with potentially >> >> more on the way - it becomes difficult to know >> >> which is the "latest". >> >> Readers of one document might >> >> not be aware of the other >> >> documents. >> >> >> >> Perhaps the authors of the two >> >> drafts above could consider >> >> introducing an IANA Registry which has the >> >> ordered list of rules (and appropriate >> >> references for each) so that >> >> there is one source of truth. >> >> Each document would then simply >> >> specify the updates to the IANA >> >> registry. >> >> I don't think we need this, since >> >> all the interface constraints need to >> >> be satisfied for an interface to used >> >> in a given flex algorithm, I don't see that the >> >> ordering of the rules is important. >> >> >> >> Maybe the text in the two flex-algo >> >> drafts which are going to progress >> >> and be published shouldn't imply >> >> strict ordering. >> >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> >> >> >> >> >> >> Les >> >> >> >> -----Original Message----- >> >> From: Acee Lindem >> >> Sent: Thursday, January 16, >> >> 2025 11:03 AM >> >> To: lsr >> >> Cc: >> >> [email protected] >> >> Subject: [Lsr] Working Group >> >> Last Call of "IGP Flexible >> >> Algorithms Reverse >> >> Affinity Constraint" - >> >> >> >> draft-ietf-lsr-igp-flex-algo-reverse-affinity-03 >> >> >> >> LSR WG, >> >> >> >> >> >> This email begins a 3 week >> >> WG Last Call for the >> >> following draft: "IGP Flexible >> >> Algorithms Reverse Affinity >> >> Constraint" - >> >> draft-ietf-lsr-igp-flex-algo-reverse- >> >> affinity-03" >> >> >> >> Please review the document >> >> and indicate your support or >> >> objections by >> >> February 7th, 2025. The >> >> extra week is to account for >> >> the Lunar New Year >> >> holiday. >> >> >> >> Thanks, >> >> Acee >> >> >> >> _______________________________________________ >> >> Lsr mailing list -- >> >> [email protected] >> >> To unsubscribe send an email >> >> to [email protected] >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
