Speaking as document shepherd and LSR Co-chair: Co-authors,
> On Feb 4, 2025, at 12:59 PM, Roman Danyliw via Datatracker <nore...@ietf.org> > wrote: > > Roman Danyliw has entered the following ballot position for > draft-ietf-lsr-flex-algo-bw-con-18: 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-flex-algo-bw-con/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 3.1.1 > Min Bandwidth (4 octets): > A 32-bit field specifying the link bandwidth encoded in IEEE > floating point format (32 bits). > > Please normatively cite this format. Is it IEEE754? > > Same comment for Sections 3.2.1, 4.1.3.1, 4.1.4.1, and 4.1.4.2 Note the Google Gemini will generate the xml2rfc version 3 reference. You just got to make sure you ask for the right version. I believe 2019 is the latest. <reference anchor="IEEE754-2019"> <front> <title>IEEE Standard for Floating-Point Arithmetic</title> <author> <organization>Institute of Electrical and Electronics Engineers</organization> </author> <date day="22" month="July" year="2019"/> </front> <seriesInfo name="IEEE" value="754-2019"/> <seriesInfo name="DOI" value="10.1109/ieeestd.2019.8766229"/> <format type="HTML" target="https://ieeexplore.ieee.org/document/8766220"/> </reference> Please incorporate or at least respond to the non-blocking comments as well. Thanks, Acee > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to Christer Holmberg for the GENART review. > > ** Abstract. Editorial. > Many networks configure the link metric relative to the link > capacity. High bandwidth traffic gets routed as per the link > capacity. Flexible algorithms provide mechanisms to create > constraint based paths in an IGP. This draft documents a generic > metric type and set of bandwidth related constraints to be used in > Flexible Algorithms. > > Reading this abstract using a dictionary’s definition of some of these phrases > could lead to significant confusion. Could the text more clearly state the > IGP > appropriate context. For example: > > -- “Many networks configure the ink metric relative to the link capacity”, > what’s a link metric? Do you mean “IGP link metric”? > > -- “Flexible algorithms provide mechanisms to create constraint based paths in > an IGP”, what kind of flexible algorithms. Do you mean “The IGP Flexible > Algorithm defined in RFC9350 …”? > > ** Section 2. > The metric type field is assigned by the > "IGP metric type" IANA registry. Metric types 0-127 are standard > metric types as assigned by IANA. This document further specifies a > user-defined metric type space of metric types 128-255. These are > user defined and can be assigned by an operator for local use. > > -- Isn’t it the “IGP Metric-Type” registry not “IGP metric type” per > https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type? > > -- What is the basis of the code point allocation range 0-127 being different > from 128-255? The registry > (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type) > doesn’t seem to make a distinction. I do see that 128-255 is set aside for > Flexible Algorithms in the “IGP Algorithm Types” registry > (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types) > > ** Section 2.2. Should the Reserve field be set to zero by the sender and be > ignored by the receiver? Same question for Sections 4.1.4.1 and 4.1.4.2. > > ** Section 2.2. > Type (2 octets): > A 16-bit field assigned by IANA (To Be Determined as TBD21/TBD22/TBD23). > This value uniquely identifies the Generic Metric TLV. > > Why does the OSPF Generic Metric Sub-TLV have three types? What’s the > difference? > > ** Section 4.1.3.1. Per the Flags, field, should the unassigned values be set > to zero? Same question for Sections 4.1.3.2, 4.1.4.1, 4.1.4.2 > > ** Section 10.1 > IGP Metric-type Registry is updated to include another column > specifying whether the pariticular metric-type is allowed in the > generic-metric sub-TLV or not. > … > 128-255(TBA) User defined metric this document yes > > -- What does the TBA mean here? > > -- Does the registration procedure for this range change? > > -- Shouldn’t the introductory text say that the 128-255 range is being > redefined? > > ** Section 10.2. It would improve readability to mention that “IS-IS > Sub-Sub-TLVs for Flexible Algorithm Definition Sub-TLV” is part of the “IS-IS > TLV Codepoints” registry group. > > ** Section 10.3. It would improve readability to mention that the “OSPF > Flexible Algorithm Definition TLV Sub-TLVs” registry is part of the “Open > Shortest Path First (OSPF) Parameters” registry group. > > ** Section 10.4. It would improve readability to mention that the “IS-IS > Sub-TLVs for TLVs Advertising Neighbor Information” registry is part of the > “IS-IS TLV Codepoints” registry group > > ** Section 10.5 – 10.6. Same comment about mentioning the parent registry > group. > > > _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
