Hi,
Thank you for the work on editing the draft.
Pls see inline for responses
Juniper Business Use Only
-----Original Message-----
From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
Sent: 19 August 2025 02:55
To: Shraddha Hegde <shrad...@juniper.net>; William Britto A J
<bwill...@juniper.net>; Rajesh M <mraj...@juniper.net>;
bruno.decra...@orange.com; ppse...@cisco.com; tony...@tony.li
Cc: rfc-edi...@rfc-editor.org; lsr-...@ietf.org; lsr-cha...@ietf.org;
a...@cisco.com; gunter.van_de_ve...@nokia.com; auth48archive@rfc-editor.org
Subject: Re: AUTH48: RFC-to-be 9843 <draft-ietf-lsr-flex-algo-bw-con-22> for
your review
[External Email. Be cautious of content]
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!--[rfced] We removed "A J" from William Britto's name to match use in RFC
9502. If that is not desired, please let us know.
-->
<SH> will let William confirm
2) <!--[rfced] How may we clarify "and require to be standardized"? Please let
us know if option A or option B captures in the intended meaning.
In addition, as this document is being published as a Standards-Track RFC,
please consider whether "proposes" is accurate. Perhaps "introduces" would
work?
Original:
This document proposes standard metric-types which have
specific semantics and require to be standardized.
Perhaps A:
This document proposes standard metric-types that have
specific semantics and require standardization.
Perhaps B:
This document proposes standard metric-types that have
specific semantics and requirements for standardization.
-->
<SH> I prefer A
This document proposes standard metric-types that have
specific semantics and require standardization
3) <!--[rfced] Should the section references be in order for ease of reading as
shown below?
Original:
In Section 4, this document specifies a new bandwidth based metric
type to be used with Flex-Algorithm and other applications.
Section 3 defines additional Flexible Algorithm Definition (FAD)
[RFC9350] constraints that allow the network administrator to
preclude the use of low bandwidth links or high delay links.
Section 4.1 defines...
Perhaps:
Section 3 defines additional FAD [RFC9350] constraints that allow
the network administrator to preclude the use of low bandwidth
links or high delay links. In Section 4, this document specifies
a new bandwidth-based metric type to be used with Flex-Algorithm
and other applications.
Section 4.1 defines...
-->
<SH> ok
4) <!--[rfced] Should "Min Unidirectional delay metric" be "Unidirectional Link
Delay" or "Min/Max Unidirectional Link Delay" per RFCs 8570 and 7471?
Original:
The Traffic Engineering Default Metric is defined in [RFC5305]
and [RFC3630] and the Min Unidirectional delay metric is
defined in [RFC8570] and [RFC7471].
Perhaps:
The Traffic Engineering Default Metric is defined in [RFC5305]
and [RFC3630], and the Min/Max Unidirectional Link Delay is
defined in [RFC8570] and [RFC7471].
-->
<SH> It should be Unidirectional Link Delay
New:
The Traffic Engineering Default Metric is defined in [RFC5305]
and [RFC3630], and the Unidirectional Link Delay is
defined in [RFC8570] and [RFC7471].
5) <!--[rfced] We find "TLV 22/extended link LSA/TE-LSAs" hard to read. How may
we reword this for clarity and to also include the expansion of "LSA"?
Also, should "generic metric sub-TLV" be singular and uppercase for consistency
as shown below?
<SH> Ok with the uppercase
Original:
Implementations MUST support sending and receiving generic metric
sub-TLV in Application Specific Link Attributes (ASLA)encodings as
well as in the TLV 22/extended link LSA/TE-LSAs.
Perhaps:
Implementations MUST support sending and receiving a Generic Metric
sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
well as in TLV 22 and extended Link State Advertisements (LSAs)
and TE-LSAs.
-->
<SH> With slight modification as below
Implementations MUST support sending and receiving a Generic Metric
sub-TLV in Application-Specific Link Attributes (ASLA) encodings as
well as in TLV 22 and Extended Link Opaque Link State Advertisements (LSAs)
[RFC7684]
and TE-LSAs.
6) <!--[rfced] When referring to "TLV 22/222/23/223/141" (or "TLV
22/23/141/222/223"
if updated), should "TLV" be plural (e.g., "TLVs 22/222/23/223/141")?
We note that the plural form is used in the "Sub-TLVs for TLVs 22, 23, 141,
222, and 223" registry.
Original:
f. sub-TLV 16 (Application-Specific Link Attributes (ASLA)) of TLV
22/222/23/223/141 [RFC9479]
g. TLV 25 (L2 Bundle Member Attributes) [RFC8668] Marked as "y(s)"
(shareable among bundle members)
...
One example in the running text (see the document for more instances).
Original:
For a particular metric type, the Generic Metric sub-TLV MUST be advertised
only once for a link when advertised in TLV 22, 222, 23, 223 and 141.
-->
<SH> Pluralisation of TLV to TLVs is ok
7) <!--[rfced] Would it be correct to update "2" to "type 2" as shown below for
clarity?
Original:
a. sub-TLV of TE Link TLV (2) of OSPF TE LSA [RFC3630].
b. sub-TLV of TE Link TLV (2) of OSPFv2 Inter-AS-TE-v2 LSA
[RFC5392].
c. sub-TLV of TE Link TLV (2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].
d. sub-TLV of TE Link TLV (2) of OSPFv3 Inter-AS-TE-v3 LSA
[RFC5392].
Perhaps:
a. sub-TLV of TE Link TLV (type 2) of OSPF TE LSA [RFC3630].
b. sub-TLV of TE Link TLV (type 2) of OSPFv2 Inter-AS-TE-v2 LSA
[RFC5392].
c. sub-TLV of TE Link TLV (type 2) of OSPFv3 Intra-Area-TE-LSA [RFC5329].
d. sub-TLV of TE Link TLV (type 2) of OSPFv3 Inter-AS-TE-v3 LSA
[RFC5392].
-->
<SH> ok
8) <!--[rfced] Please clarify what "this" refers to in the following sentence.
Original:
If the capacity of a link is constant, this can already be achieved
through the use of administrative groups.
-->
<SH> If the capacity of a low bandwidth link is constant, Constraining the
topology to avoid those links can already be achieved through the use of
administrative groups.
9) <!--[rfced] May we update this sentence for clarity as shown below?
Original:
Bandwidth metric is a link attribute and for the advertisement and
processing of this attribute for Flex-algorithm, MUST follow the
section 12 of [RFC9350].
Perhaps:
The Bandwidth Metric is a link attribute, and it MUST follow Section 12
of [RFC9350] for its advertisement and processing during Flex-Algorithm
calculation.
-->
<SH> ok
10) <!--[rfced] We updated this text to make it a complete sentence. There are
two instances in the document. Please let us know if this is not correct.
Original:
Staircase bandwidth threshold and associated metric values.
Current:
Following is the staircase bandwidth threshold and associated metric
values.
-->
<SH> ok
11) <!--[rfced] We note similar text in Sections 4.1.3.1, 4.1.3.2, and 4.1.4.2.
Should any of this text be in paragraph form or bulleted form for consistency?
Original
Section 4.1.3.1:
In case of Interface Group Mode, if
all the parallel links have been advertised with the Bandwidth
Metric, The individual link Bandwidth Metric MUST be used. If only
some links among the parallel links have the Bandwidth Metric
advertisement, the Bandwidth Metric for such links MUST be ignored
and automatic Metric calculation MUST be used to derive link metric.
Section 4.1.3.2:
In case of Interface Group Mode, if all the parallel links have been
advertised with the Bandwidth Metric, The individual link Bandwidth
Metric MUST be used. If only some links among the parallel links
have the Bandwidth Metric advertisement, the Bandwidth Metric for
such links MUST be ignored and automatic Metric calculation MUST be
used to derive link metric.
Section 4.1.4.2:
In the context of Interface Group Mode, the following rules apply to
parallel links:
* If all parallel links have advertised the Bandwidth Metric:
The individual link Bandwidth Metrics MUST be used for each link
during path computation.
* If only some of the parallel links have advertised the Bandwidth
Metric:
- The Bandwidth Metric advertisements for those links MUST be
ignored.
- Automatic metric calculation MUST be used to derive the link
metrics for all parallel links.
-->
<SH> Bulleted form looks more readable. Sec 4.1.3.1 and sec 4.1.3.2 can be
modified to bulleted form
12) <!-- [rfced] Please review whether any of the notes in this document should
be in the <aside> element. It is defined as "a container for content that is
semantically less important or tangential to the content that surrounds it"
(https://urldefense.com/v3/__https://authors.ietf.org/en/rfcxml-vocabulary*aside__;Iw!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aULFhXTJk$
).
-->
<SH> The current form of Notes looks appropriate to me.
13) <!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they may
be made consistent.
Bandwidth metric type vs. bandwidth metric calculation
(Should "bandwidth metric calculation" be "Bandwidth metric calculation"
to match "Bandwidth metric type"?)
<SH> Good to use below consistently
Bandwidth metric type , Bandwidth metric calculation
metric-type vs. metric type
<SH> metric-type
Minimum Bandwidth value vs. Minimum bandwidth advertised
(Are these terms different or should "bandwidth" be uppercase
for consistency?)
<SH> When sub-TV is referred First letter should be capitalised , when the
actual value contained in the sb-TLV is referred, small case should be used.
Exampls:
Old:
If the Maximum Link Bandwidth is lower than the Minimum Link Bandwidth
advertised in the FAEMB sub-TLV,
Maximum Delay constraint vs. Maximum delay advertised
New:
If the maximum link bandwidth is lower than the minimum link bandwidth
advertised in the FAEMB sub-TLV,
I can take a first cut on fixing this in the document. Let me know.
(Are these terms different or should "delay" be uppercase
for consistency?
Min Delay value (used once in this document)
Is this the intended term or should it perhaps be
"Minimum Delay value" or "Min Unidirectional Link Delay
value"?
<SH> the Min Delay is the term used in RFC 7471
b) We updated the document to reflect the forms on the right for consistency.
Please let us know of any objections.
Bandwidth metric -> Bandwidth Metric
bytes-per-second -> bytes per second
Flex-algorithm -> Flex-Algorithm (per RFC 9350) Flex-Algorithm definition ->
Flex Algorithm Definition (per RFC 9350)
Flexible Algorithm Definition Bandwidth Thresholds ->
Flexible Algorithm Definition Bandwidth Threshold (singular)
Generic metric -> Generic Metric (for consistency and per IANA) IGP metric ->
IGP Metric (per RFC 9350 and IANA) ISIS -> IS-IS interface group mode ->
Interface Group Mode L-Flag -> L-flag (per RFC 9350)
layer-2 -> Layer 2
layer-3 -> Layer 3
Max link delay -> Max Link Delay
Min Unidirectional link delay and Minimum Unidirectional Link Delay ->
Min Unidirectional Link Delay (per RFC 9350)
Minimum link bandwidth -> Minimum Link Bandwidth nexthops -> next hops
Reference Bandwidth Field -> Reference Bandwidth field
<SH> OK for all
c) Should "simple mode" be made uppercase to match "Interface Group Mode"
since they are both listed as automatic metric calculation modes?
-->
<SH> OK
14) <!-- [rfced] Abbreviations
a) FYI - We have added expansions for the following abbreviations per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.
Area Border Router (ABR)
Link Aggregation Group (LAG)
Link State Advertisement (LSA)
Link State Protocol Data Unit (LSPDU)
<SH> OK
b) We made the following change to follow use in RFC 9350. Please let us know
of any objections.
Flex-Algorithm Definition (FAD) -> Flexible Algorithm Definition (FAD)
-->
<SH> OK
15) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide
<https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUDCHaRVn$
> and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
<SH> ok
Thank you.
Karen Moore and Sandy Ginoza
RFC Production Center
On Aug 18, 2025, at 2:21 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/08/18
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and approved
by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies available as
listed in the FAQ
(https://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUHT0O_G1$
).
You and you coauthors are responsible for engaging other parties (e.g.,
Contributors or Working Group) as necessary before providing your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP –
https://urldefense.com/v3/__https://trustee.ietf.org/license-info__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUNtLNH4K$
).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUGqmN29i$
>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all the
parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCMDQwLp$
* The archive itself:
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUDhfuJRq$
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit list of
changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem beyond
editorial in nature, e.g., addition of new text, deletion of text, and
technical changes. Information about stream managers can be found in the FAQ.
Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating that
you approve this RFC for publication. Please use ‘REPLY ALL’, as all the
parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.xml__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUNyZupXt$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUBv7V6LA$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.pdf__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUCHPopHH$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843.txt__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUBZrKBWa$
Diff file of the text:
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-diff.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUArKKa_y$
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUEuqnIYn$
(side by side)
Diff of the XML:
https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9843-xmldiff1.html__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUN3Xt-LR$
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9843__;!!NEt6yMaO-gk!GAYtbcKco2W_gMbaVd2Ie5DRUsGCbtqPTGafDtDGY0T86QMqQbuOG1lYMzLeFLFB7o1ofaRPdVELob8aUOE3WnXi$
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 9843 (draft-ietf-lsr-flex-algo-bw-con-22)
Title : IGP Flexible Algorithms: Bandwidth, Delay, Metrics and
Constraints
Author(s) : S. Hegde, W. Britto A J, R. Shetty, B. Decraene, P. Psenak,
T. Li
WG Chair(s) : Acee Lindem, Christian Hopps, Yingzhen Qu
Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
