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?
Again,I truly appreciate the time you took to share your insights and hope we
can continue this discussion.
Best Regards,
Liyan
----邮件原文----发件人：Peter Psenak <ppse...@cisco.com>收件人：Liyan Gong
<gongli...@chinamobile.com>,Acee Lindem <acee.i...@gmail.com>抄 送: "Les
Ginsberg (ginsbe" <ginsb...@cisco.com>,shraddha <shrad...@juniper.net>,lsr
<lsr@ietf.org>,draft-ietf-lsr-igp-f
<draft-ietf-lsr-igp-flex-algo-reverse-affinity....@ietf.org>发送时间：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 don39t 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
don39t.
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 <ppsenak=40cisco....@dmarc.ietf.org>
收件人：Acee Lindem <acee.i...@gmail.com> 抄 送: "Les Ginsberg
(ginsberg)" <ginsb...@cisco.com>,shraddha <shrad...@juniper.net>,lsr
<lsr@ietf.org>,"draft-ietf-lsr-igp-flex-algo-reverse-affinity....@ietf.org"
<draft-ietf-lsr-igp-flex-algo-reverse-affinity....@ietf.org>
发送时间：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
<ppse...@cisco.com> 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) <ginsb...@cisco.com>
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 <acee.i...@gmail.com>
Sent: Thursday, January 16, 2025 11:03
AM To: lsr <lsr@ietf.org>
Cc:
draft-ietf-lsr-igp-flex-algo-reverse-affinity....@ietf.org
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 -- lsr@ietf.org
To unsubscribe send an email to
lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
