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]
