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.
-->
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.
-->
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...
-->
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].
-->
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?
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.
-->
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.
-->
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].
-->
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.
-->
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.
-->
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.
-->
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.
-->
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://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
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"?)
metric-type vs. metric type
Minimum Bandwidth value vs. Minimum bandwidth advertised
(Are these terms different or should "bandwidth" be uppercase
for consistency?)
Maximum Delay constraint vs. Maximum delay advertised
(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"?
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
c) Should "simple mode" be made uppercase to match "Interface Group Mode"
since they are both listed as automatic metric calculation modes?
-->
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)
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)
-->
15) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
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.
-->
Thank you.
Karen Moore and Sandy Ginoza
RFC Production Center
On Aug 18, 2025, at 2:21 PM, [email protected] 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://www.rfc-editor.org/faq/).
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://trustee.ietf.org/license-info).
* 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://authors.ietf.org/rfcxml-vocabulary>.
* 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
* [email protected] (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).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* 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,
[email protected] 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://www.rfc-editor.org/authors/rfc9843.xml
https://www.rfc-editor.org/authors/rfc9843.html
https://www.rfc-editor.org/authors/rfc9843.pdf
https://www.rfc-editor.org/authors/rfc9843.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9843-diff.html
https://www.rfc-editor.org/authors/rfc9843-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9843-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9843
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 -- [email protected]
To unsubscribe send an email to [email protected]
