Med –
I don’t think the status of a future draft (Experimental or Standards track)
needs to be considered here.
The post of mine that expressed my POV most clearly was this one:
https://mailarchive.ietf.org/arch/msg/lsr/b6fu-hFgqK0zssXQwH6c0E_MHWU/
There I tried to clarify what my real concern was – which had to do with being
able to do early allocation.
As Peter has stated – and the latest changes to the draft clearly express – is
that updates to the rules are always made in a backwards compatible manner.
Whether a new rule is associated with an Experimental draft or a Standards
track draft does not matter.
I think we are in a good place here and nothing further is needed in the draft
– hope this helps address your remaining concern.
Les
From: Peter Psenak <[email protected]>
Sent: Friday, August 1, 2025 7:48 AM
To: [email protected]; The IESG <[email protected]>; Les Ginsberg
(ginsberg) <[email protected]>
Cc: [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT)
Med,
please see inline:
On 01/08/2025 16:18,
[email protected]<mailto:[email protected]> wrote:
Re-,
The experimental thing was brought in the discussion by members of the WG in
this thread [1], especially this part:
“For example, it is at least conceivable that an experimental use of flex-algo
may be defined in the future and it would be useful to be able to incorporate
any new rules in a way that avoids interoperability issues. ”, which is
actually not allowed per the statement you made yourself.
ok, now I understand.
The way the new rules are introduced for flex-algo computation is always
backward compatible, no matter whether they are experimental or standard. Any
new rule requires to be signaled in the FAD (flex-algo definition) and all
participating routers need to support it.
Les only used "experimental" as an example if no new standard rules are defined
in the future, but that experimental part was not significant at all.
I don't believe we need to say anything on that regard in the draft.
I let Les to confirm above for your, so that you are ensured that I did not
misinterpreted his comment.
thanks,
Peter
Setting the expectation of the WG for this seems like a point to agree on and
recorded in the spec/registry.
That’s said, and as mentioned in my previous message, I leave it to you and
Gunter to decide what to do here (including, ignoring the comment).
Cheers,
Med
[1] https://mailarchive.ietf.org/arch/msg/lsr/w9FDWozmR0NZhfzmGGWhIUeLf3g/
De : Peter Psenak <[email protected]><mailto:[email protected]>
Envoyé : vendredi 1 août 2025 14:50
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>; The IESG
<[email protected]><mailto:[email protected]>
Cc :
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT)
Hi Med,
On 01/08/2025 11:55,
[email protected]<mailto:[email protected]> wrote:
Re-,
Thanks, Peter. Will update my ballot right now.
thanks!
Will leave it to you and Gunter about how to track:
1. Adding draft-ietf-lsr-flex-algo-bw-con to the update list, once published
as RFC
2. Indicating that “experimental algos/attributes are not related to the
calculation rules defined in this registry.”
honestly I don't really understand the above. Why is the above necessary?
The new registry is not specifying any new algorithms, so "experimental
algos" is completely unrelated.
And I'm not sure what attributes are meant either, as this registry is
not specifying any attributes.
Can you please clarify?
thanks,
Peter
1.
The first point can be addressed as a note to the RFC Editor. Having a note in
the registry would make sense for the second point.
Cheers,
Med
De : Peter Psenak <[email protected]><mailto:[email protected]>
Envoyé : vendredi 1 août 2025 11:47
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>; The IESG
<[email protected]><mailto:[email protected]>
Cc :
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT)
Hi Med,
please see inline (##PP):
On 01/08/2025 10:48,
[email protected]<mailto:[email protected]> wrote:
Hi Peter, all,
Thank you for the follow-up. I checked 07/10 diff right now. I like where we
are heading with these changes.
I think the only pending point is this one:
“
[Med] Thanks for clarifying. The implication is that we need to discuss whether
we update RFC9350 and draft-ietf-lsr-flex-algo-bw-con so that the selection
steps are now authoritatively offloaded to the registry.
##PP2
sure, I make this document to update RFC9530
“
Can we then make that change, please? Thanks.
##PP
posted version 11 that has the update for the 9350. Will add the
draft-ietf-lsr-flex-algo-bw-con once it's published as RFC.
Also, I remember that Les mentioned that the WG wanted to cover Experimental
attributes/algos there as well. I think explicitly tagging these as such in the
registry would be useful. However, I leave it to decide if you to make the
change or not :-)
##PP
experimental algos/attributes are not related to the calculation rules defined
in this registry.
thanks,
Peter
Cheers,
Med
De : Peter Psenak <[email protected]><mailto:[email protected]>
Envoyé : lundi 14 juillet 2025 11:16
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>; The IESG
<[email protected]><mailto:[email protected]>
Cc :
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT)
Hi Med,
please see inline (##PP2):
On 08/07/2025 12:11,
[email protected]<mailto:[email protected]> wrote:
Hi Peter,
Thank you for the follow-up.
Please see inline.
Cheers,
Med
De : Peter Psenak
<[email protected]><mailto:[email protected]>
Envoyé : mardi 1 juillet 2025 16:36
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]><mailto:[email protected]>; The IESG
<[email protected]><mailto:[email protected]>
Cc :
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Objet : Re: Mohamed Boucadair's Discuss on
draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with DISCUSS and COMMENT)
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 to
https://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.
[Med] Sure. The underlying mechanics differ and, as indicated in my comment I
agree that these are not the same. Having some text to position the present
work vs these RFCs would be helpful. I won’t insist on making any change here
as that was a meta comment :-)
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.
[Med] but…safe to use as well. Impact on stability is important for this case.
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.
[Med] Would it harm if you remind these “standard” guards?
##PP2
I can add a simple statement about the stability aspect, but I would rather
avoid providing any specific solutions on how to achieve it, as that is not
what this document tries to standardize.
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.
[Med] As we are extending 9350, we need to check that the ops provisions
defined there are altered or not. If there is no implications, let’s say so
explicitly. Thanks.
##PP2
not sure I got it, do you want to say that "this document does not alter
section 15 of RFC9350 "? Are we going to say that for every section of RFC9350
that is not updated?
The document already explicitly says which section it updates:
"The following procedures augment the rules defined in Section 13 of
[RFC9350<https://www.rfc-editor.org/info/rfc9350>] by introducing additional
constraints based on Administrative Groups (AGs) associated with the reverse
direction of a link."
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.
[Med] ACK
# 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?
[Med] Thanks for clarifying. The implication is that we need to discuss whether
we update RFC9350 and draft-ietf-lsr-flex-algo-bw-con so that the selection
steps are now authoritatively offloaded to the registry.
##PP2
sure, I make this document to update RFC9530
How this registry is
intended to be used/maintained?
##PP
the same way as any other registry that uses "“Expert Review” registration
policy.
[Med] :-) My question is more on the practicalities: for example, do we allow
DEs to reorder of steps, merge steps, insert a step between existing ones,
delete steps, altern a step, etc.
##PP2
we can only do what is backward compatible. We will provide the "guidance"
based on the discussion you have had with Les on this thread.
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.
[Med] Given the implications on already existing implementations, I think
Standard Actions makes sense here.
----------------------------------------------------------------------
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?
[Med] What I had in mind is an illustrative example with some few routers to
show how the procedure is put into effect to ensure path symmetry. Thanks.
##PP2
There is no need for path symmetry here. I still do not understand your ask
here.
thanks,
Peter
# 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
[Med] Thanks
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
[Med] ACK
# 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
[Med] ACK
# 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
[Med] ACK
# Section 11.2: nit
OLD: Description: Flexible Algorithm Include-All ReverseAdmin Group
NEW: Description: Flexible Algorithm Include-All Reverse Admin Group
##PP
fixed
[Med] Thanks.
thanks,
Peter
Cheers,
Med
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
