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]
