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]
