As WG Co-Chair, changing subject. Please continue with this thread. Thanks, Acee
> On Feb 18, 2025, at 4:01 AM, Peter Psenak <[email protected]> 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 <[email protected]> >> 收件人：Liyan Gong <[email protected]>,Acee Lindem >> <[email protected]> >> 抄 送: "Les Ginsberg (ginsbe" <[email protected]>,shraddha >> <[email protected]>,lsr <[email protected]>,draft-ietf-lsr-igp-f >> <[email protected]> >> 发送时间：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 <[email protected]> >> 收件人：Acee Lindem <[email protected]> >> 抄 送: "Les Ginsberg (ginsberg)" <[email protected]>,shraddha >> <[email protected]>,lsr >> <[email protected]>,"[email protected]" >> <[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 >> <[email protected]> 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) <[email protected]> >> 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 >> <[email protected]> >> Sent: Thursday, January 16, >> 2025 11:03 AM >> To: lsr <[email protected]> >> 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]
