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. **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. 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. 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. 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. 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, it39s 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 don39t think we need this, since all the interface constraints need to be satisfied for an interface to used in a given flex algorithm, I don39t 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 shouldn39t 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]
