Hi Roman, Thanks for the careful review and comments. Pls see inline for replies <SH>... Ver-20 will address your comments.
Rgds Shraddha Juniper Business Use Only -----Original Message----- From: Roman Danyliw via Datatracker <nore...@ietf.org> Sent: 04 February 2025 23:29 To: The IESG <i...@ietf.org> Cc: draft-ietf-lsr-flex-algo-bw-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; acee.i...@gmail.com; a...@cisco.com Subject: Roman Danyliw's Discuss on draft-ietf-lsr-flex-algo-bw-con-18: (with DISCUSS and COMMENT) [External Email. Be cautious of content] 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!D-r4rSzr8Ttwf7DxWfhAMSHUR5wzUISkEI51Gu3WOeVVpT6Mq6XrnpEdnfqL2hbwUiP-dYecSuIcniOM$ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!D-r4rSzr8Ttwf7DxWfhAMSHUR5wzUISkEI51Gu3WOeVVpT6Mq6XrnpEdnfqL2hbwUiP-dYecSrRYtor3$ ---------------------------------------------------------------------- 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 <SH> ok ---------------------------------------------------------------------- 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 …”? <SH> ok ** 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://urldefense.com/v3/__https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*igp-metric-type?__;Iw!!NEt6yMaO-gk!D-r4rSzr8Ttwf7DxWfhAMSHUR5wzUISkEI51Gu3WOeVVpT6Mq6XrnpEdnfqL2hbwUiP-dYecSvRUJPoK$ <SH> yes. Will change it -- What is the basis of the code point allocation range 0-127 being different from 128-255? The registry (https://urldefense.com/v3/__https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*igp-metric-type__;Iw!!NEt6yMaO-gk!D-r4rSzr8Ttwf7DxWfhAMSHUR5wzUISkEI51Gu3WOeVVpT6Mq6XrnpEdnfqL2hbwUiP-dYecSkG9oqqP$ ) doesn’t seem to make a distinction. <SH> The distinction and definition of 128-255 is user-defined is proposed in this document. I see that IANA hasn't updated this yet. Will make sure they do it. I do see that 128-255 is set aside for Flexible Algorithms in the “IGP Algorithm Types” registry (https://urldefense.com/v3/__https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml*igp-algorithm-types__;Iw!!NEt6yMaO-gk!D-r4rSzr8Ttwf7DxWfhAMSHUR5wzUISkEI51Gu3WOeVVpT6Mq6XrnpEdnfqL2hbwUiP-dYecSuU02kiu$ ) <SH> User defined metric types and user defined algorithms are not directly related. For ex: user defined flex-algo 128 can use standard metric type 2 keeping the user-defined range 128-255 for metric will match it with the User-defined Flex-algorithm range and has some operational benefits. For ex: user defined flex-algo 130 can use user defined metric type 130. ** 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. <SH> fixed ** 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? <SH> It appears in three different TLVs and gets assigned different sub-TLV values under each registry ** 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 <SH> yes. ** 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? <SH> Guidance for IANA to update this in registry -- Does the registration procedure for this range change? <SH> yes -- Shouldn’t the introductory text say that the 128-255 range is being redefined? <SH> yes. Will add it ** 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. <SH> OK _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
