Hi Mohamed,
thanks for your comments, please see responses inline (##PP):
On 30/06/2025 14:17, Mohamed Boucadair via Datatracker wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer tohttps://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi Peter, Jakub, and Amit,
Thank you for the effort put into this specification.
I was surprised that the document does not cite "similar" work on revere metric
such as in RFC8500 and RFC9339. I'm not saying this is identical, but there are
similarities that are worth to acknowledge.
##PP
above mention RFCs alter the local IGP metric from the reverse side of
the link. They do that by sending extra data in the protocol Hello
packets that overwrite the locally configured metric on the link.
What we do in this draft is different. We define a new flex-algo
constraint, which is using the link affinities that are set locally on
the link. Nothing is sent from the other side of the link that would
alter any local link properties. Link affinities are advertised in a
traditional way inside the LSA/LSP when the router describe its local
links. The new constraint that we defined uses these affinities. On tpp
of looking at the affinities in the forward direction of the
computation, it is now allowed to look at the link affinities associated
with the backward directions of the computation.
Please find below some points that I think need to be discussed.
# Stability & Lack of Operations Considerations
The activation of the attributes defined in this document may have implications
on the stability of the routine table. However, the document does not discuss
such implications, does not include guards to avoid frequent reverse link
updates, does not provide a guidance about how/when it is safe to make an
update, does not discuss relevant configuration matters.
Worse, the document does only include an example (as part of use case) about
how an operator can decide to trigger such message which relies on a
threshold-based approach:
Section 3:
An operator
might monitor metrics like CRC errors or other input-related faults
at node B and apply thresholds over a defined observation period. If
such a threshold is exceeded, node B may locally assign specific
Extended Administrative Groups to the link in the direction from B to
A.
Absent robust hysteresis, it is risky to use such threshold-based approach as
this may lead to instability. FWIW, draft-ietf-nmop-terminology rightfully
warrant against issues that might be induced by threshold-based schemes:
The use of threshold-driven
Events and States (and the Alerts that they might give rise to) must
be treated with caution to dampen any "flapping" (so that consistent
States may be observed) and to avoid overwhelming management
processes or systems.
##PP
I don't consider RFCs an educational documents, nor implementation
guides. RFCs are written to maintain interoperability.
This draft specifies protocol extensions that add additional constraints
to the flex-algo computation. It does not even add any
new link attribute, it uses an existing one. I don't see why we should
talk about how an existing affinity attribute should be
set, just because we find a new use case for it.
There are many scenarios why an IGP may need to add/remove/modify data
in its protocol packets and if not done correctly
could impact the stability of the network. Standard mechanisms exists in
the IGP protocols to avoid instability caused
by the broken originator, whether it is caused by the poor
implementation or a bug in it.
Please consider adding a discussion to cover these matters. At minimum, a
reminder of the considerations in rfc9350#section-15 should be included.
##PP
this draft extends the RFC9350. It does not alter section 15 in any way.
I do not understand why do you believe we need to mention it here.
I
suggest you also look at rfc8500#section-3.5, rfc9339#section-7, and
rfc9339#section-8 to see to what extent the ops considerations discussed out
there are relevant in this specific context.
##PP
I see no relevance of the above RFCs/sections to what we are specifying
here.
We do not alter any local link property based on something that we
receive from the other side, which is what the above two RFCs do.
# IGP Flex-Algo Path Computation Rules Registry
Unless I’m mistaken, this registry is not specific to this specification.
What is the rationale for adding this registry here?
##PP
This registry is specific to flex-algo technology, that has been defined
in RFC9350.
Section 13 of that RFC specifies the ordered set of rules that MUST be
followed when the algo specific calculation is done.
Additional rules have been added by this drat and also by
draft-ietf-lsr-flex-algo-bw-con. More changes are on the way.
We realized that it would be difficult for people to find the latest set
of rules without the centralized registry that keeps track of all
changes in these rules.
So we created the registry in this draft. Do you see a problem?
How this registry is
intended to be used/maintained?
##PP
the same way as any other registry that uses "“Expert Review”
registration policy.
Why “Expert Review” is picked as policy for
this registry, while all the steps were/are defined in PS documents? Are DEs
allowed to delete/modify/merge/reorder steps? What are the implications on
already specified metrics?
##PP
If you look at all ISIS IANA registries, their registration policy is
"Expert Review". Similarly many registries under "Interior Gateway
Protocol (IGP) Parameters" use the same policy.
I have no issues to change it to SA, but we have been happily using
"Expert Review" with IGP registries for many years and it has worked well.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
# Illustration examples
Consider adding some examples to illustrate the intended use.
##PP
what exactly do you want me to illustrate? Is the use case not clearly
described?
# Sections 4/5: Simplify as the types are already assigned.
OLD:
Type (1 octet): An 8-bit field assigned by IANA to uniquely
identify the ISIS FAERAG Sub-TLV. Value 10 has been assigned by
IANA.
NEW:
Type (1 octet): 10
##PP
done
OLD:
Type (2 octets): A 16-bit field assigned by IANA to uniquely
identify the OSPF FAERAG Sub-TLV. Value 10 has been assigned by
IANA.
NEW:
Type (2 octets): 10
##PP
done
# Section 11.1: Use the correct name of the IANA registry + indicate the
registry group
OLD:
IANA has assigned the following Sub-Sub-TLVs in the "ISIS Sub-Sub-
TLVs for Flexible Algorithm Definition Sub-TLV" registry:
NEW:
IANA has assigned the following Sub-Sub-TLVs in the " IS-IS Sub-Sub-TLVs
for Flexible Algorithm Definition Sub-TLV" registry under “IS-IS TLV
Codepoints”
registry group:
##PP
done
# Section 11.2: Use the correct name of the IANA registry + indicate the
registry group
OLD:
IANA has assigned the following Sub-TLVs in the "OSPF TLVs for
Flexible Algorithm Definition TLV" registry:
NEW:
IANA has assigned the following Sub-TLVs in the " OSPF Flexible
Algorithm Definition TLV Sub-TLVs" registry under “Open Shortest Path First
(OSPF) Parameters”
registry group:
##PP
done
# Section 11.2: nit
OLD: Description: Flexible Algorithm Include-All ReverseAdmin Group
NEW: Description: Flexible Algorithm Include-All Reverse Admin Group
##PP
fixed
thanks,
Peter
Cheers,
Med
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
