Hi Peter, > On Nov 20, 2024, at 12:06, Peter Psenak <[email protected]> wrote: > > Hi Acee, > > On 20/11/2024 18:00, Acee Lindem wrote: >> Hi Gunter - Your review uncovered some needed edits and proposed >> clarifications. Nobody has implemented the automatic metric derivation from >> the bandwidth (at least if I understood the implementation poll right), so >> we have some leeway here. Authors can correct me if I'm wrong. > we have implemented the Automatic Metric Calculation using the Reference > bandwidth method. I mentioned it in one of my responses when you asked about > the implementation status. >
Right - however, I don’t think Gunter is suggesting changes to reference bandwidth metric calculation - only clarifications that those familiar with the interface IGP reference bandwidth metric calculation wouldn’t need. However, I’ll let you guys respond. Thanks, Acee > thanks, > Peter > >> >> Hi Shraddha, Peter, and other Co-Authors, >> >> Can you either update the draft or respond as to why you didn’t for each >> comment below? >> >> Thanks, >> Acee >> >>> On Nov 19, 2024, at 11:30, Gunter van de Velde (Nokia) >>> <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> # Gunter Van de Velde, RTG AD, comments for >>> draft-ietf-lsr-flex-algo-bw-con-15 >>> >>> # the referenced line numbers are derived from the idnits tool: >>> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-15.txt >>> >>> #GENERIC COMMENTS >>> #================ >>> ## I found the draft well written, and the procedures are well described. >>> Thank you for the nice document >>> ## This review is mostly about clarifications and consistency and nearly >>> ready for IETF LC >>> >>> #DETAILED COMMENTS >>> #================= >>> >>> 26 Requirements Language >>> 25 >>> 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", >>> "SHALL NOT", >>> 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" >>> in this >>> 30 document are to be interpreted as described in RFC 2119 >>> [RFC2119]. >>> >>> GV> This seems like an old boilerplate was used. The new one looks as >>> follows: >>> >>> " >>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >>> "OPTIONAL" in this document are to be interpreted as described in BCP >>> 14 [RFC2119] [RFC8174] when, and only when, they appear in all >>> capitals, as shown here. >>> " >>> >>> 170 Section 3 defines additional Flexible Algorithm Definition >>> (FAD) >>> 171 constraints that allow the network administrator to preclude >>> the use >>> 172 of low bandwidth links or high delay links. >>> >>> GV> Could a reference to RFC9350 be added for FAD? >>> >>> 236 0 1 2 >>> 3 >>> 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 >>> 9 0 1 >>> 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> 239 | Type | Length | metric-type | >>> 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> 241 | Value | >>> 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> 244 Type : TBD1 (To be assigned by IANA) >>> 245 Length: 4 octets >>> 246 Metric-type: A value from the IGP metric-type registry >>> 247 Value : Metric value range (0 - 16,777,215) >>> >>> GV> The picture is slightly confusing. What about the following alternate >>> explanation. Similar structire could be used with the other encoding in the >>> sections that follow. >>> >>> " >>> Type (1 octet): >>> An 8-bit field assigned by IANA (To Be Determined as TBD1). This value >>> uniquely identifies the Metric TLV. >>> >>> Length (1 octet): >>> An 8-bit field indicating the total length, in octets, of the subsequent >>> fields. For this TLV, the Length is set to 4. >>> >>> Metric-Type (1 octet): >>> An 8-bit field specifying the type of metric. The value is taken from the >>> "IGP metric-type" registry maintained by IANA. >>> >>> Value (3 octets): >>> A 24-bit unsigned integer representing the metric value. The valid range is >>> from 0 to 16,777,215. >>> " >>> >>> 334 If the metric type indicates a standard metric type for which >>> there >>> 335 are other advertisement mechanisms (e.g., the IGP metric, the >>> Min >>> 336 Unidirectional Link Delay, or the Traffic Engineering Default >>> 337 Metric), the Generic Metric advertisement MUST be ignored. >>> >>> GV> I am slightly confused. I may misunderstand this procedure rule. Is >>> this section trying to prescribe that generic metric type TLV should not >>> carry a standard metric? or is it trying to prescribe that when for a >>> specific link there is a legacy metric type advertisement (e.g. IGP metric) >>> that the generic TLV must be ignored? >>> >>> 355 Flexible-Algorithm-specific metric. Metrics carried in FAPM >>> will be >>> 356 equal to the metric to reach the prefix for that >>> Flex-Algorithm in >>> 357 its source area or domain. When Flex-Algorithm uses Generic >>> metric, >>> >>> GV> Maybe a small clarification for accuracy by adding few words: "Metrics >>> carried in FAPM will be equal to the metric to reach the prefix for that >>> Flex-Algorithm in its source area or domain ***from the ABR >>> perspective***.". >>> >>> 430 If the Maximum Link Bandwidth is lower than the Minimum link >>> 431 bandwidth advertised in FAEMB sub-TLV, the link MUST be >>> excluded from >>> 432 the Flex-Algorithm topology. If a link does not have the >>> Maximum >>> >>> GV> corner case scenario. I suspect that the existing text is written >>> already on purpose, but i wanted to sanity check: Is the intent to have >>> 'lower' or 'lower or equal'? >>> >>> 471 If the Min Unidirectional Link Delay value is higher than the >>> Maximum >>> 472 link delay advertised in FAEMD sub-TLV, the link MUST be >>> excluded >>> 473 from the Flex-Algorithm topology. If a link does not have the >>> Min >>> >>> GV> same as above. Is this higher or higher and equal? >>> >>> 546 not aadvertised for a link but the FAD contains this >>> sub-TLV,then >>> >>> GV> s/aadvertised/advertised/ >>> >>> 564 link advertisements. Bandwidth metric is a link attribute and >>> for >>> 565 the advertisement and processing of this attribute for Flex- >>> 566 algorithm, MUST follow the the section 12 of [RFC9350] >>> >>> GV> Is there special consideration for stub links? are there any special >>> behaviours for transit or stub links applied when a router is configured >>> for "overload max-metric"? (to take a router out-of-service for >>> maintenance, or for making an ABR less desirable during maintenance) >>> >>> 653 which may cause undesired load-balancing on the links. In such >>> 654 cases, a device may locally apply load-balancing factor >>> relative to >>> 655 the link bandwidth on the ECMP nexthops. >>> >>> GV> Would it be worthwhile to say explicit that these load-balancing >>> mechanisms are out of scope of this document (similar as a few lines >>> earlier?) >>> >>> 683 For example, >>> 684 >>> 685 reference bandwidth = 1000G >>> 686 >>> 687 Granularity = 20G >>> 688 >>> 689 The derived metric is 10 for link bandwidth in the range >>> 100G to >>> 690 119G >>> >>> GV> Maybe more accurate that the FLOOR function is used to rounds number >>> down, toward zero, to the nearest multiple of significance >>> >>> 746 When granularity_bw is less than or equal to >>> Total_link_bandwidth >>> 747 >>> 748 Metric calculation: (Reference_bandwidth) / >>> 749 (Total_link_bandwidth - >>> 750 (Modulus >>> of(Total_link_bandwidth, >>> 751 granularity_bw))) >>> 752 >>> 753 When granularity_bw is greater than Total_link_bandwidth >>> 754 Metric calculation: Reference_bandwidth / >>> 755 Total_link_bandwidth >>> >>> GV> should it be mentioned that this is an integer division? >>> >>> 769 automatically derived metric for that link. In case of >>> Interface >>> 770 Group Mode, if all the parallel links have been advertised >>> with the >>> 771 Bandwidth Metric, The individual link Bandwidth Metric MUST be >>> used. >>> 772 If only some links among the parallel links have the Bandwidth >>> Metric >>> 773 advertisement, the Bandwidth Metric for such links MUST be >>> ignored >>> 774 and automatic Metric calculation MUST be used to derive link >>> metric. >>> >>> GV> what about following alternative writeup to make the text easier to >>> understand: >>> >>> " >>> In the case of Interface Group Mode, the following procedures apply: >>> * When all parallel links have advertised the Bandwidth Metric: The >>> individual link Bandwidth Metric MUST be used for each link. >>> * When only a subset of the parallel links have advertised the Bandwidth >>> Metric: The Bandwidth Metric advertisements for those links MUST be >>> ignored. In this scenario, automatic metric calculation MUST be used to >>> derive the link metrics for all parallel links. >>> " >>> >>> 847 When the computed link bandwidth is less than Bandwidth >>> Threshold 1, >>> 848 the MAX_METRIC value of 4,261,412,864 MUST be assigned as the >>> 849 Bandwidth Metric on the link during the Flex-Algorithm SPF >>> 850 calculation. >>> 851 >>> 852 When the computed link bandwidth is greater than or equal to >>> 853 Bandwidth Threshold 1 and less than Bandwidth Threshold 2, >>> Threshold >>> 854 Metric 1 MUST be assigned as the Bandwidth Metric on the link >>> during >>> 855 the Flex-Algorithm SPF calculation. >>> 856 >>> 857 Similarly, when the computed link bandwidth is greater than or >>> equal >>> 858 to Bandwidth Threshold 2 and less than Bandwidth Threshold 3, >>> 859 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on >>> the >>> 860 link during the Flex-Algorithm SPF calculation. >>> 861 >>> 862 In general, when the computed link bandwidth is greater than >>> or equal >>> 863 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, >>> 864 Threshold Metric X MUST be assigned as the Bandwidth Metric on >>> the >>> 865 link during the Flex-Algorithm SPF calculation. >>> 866 >>> 867 Finally, when the computed link bandwidth is greater than or >>> equal to >>> 868 Bandwidth Threshold N, then Threshold Metric N MUST be >>> assigned as >>> 869 the Bandwidth Metric on the link during Flex-Algorithm SPF >>> 870 calculation. >>> >>> GV> What about the following procedure rewrite? >>> >>> " >>> Assignment of Bandwidth Metric Based on Computed Link Bandwidth >>> >>> The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path >>> First (SPF) calculation MUST be assigned according to the following rules: >>> >>> 1. When the computed link bandwidth is less than Bandwidth Threshold 1: >>> * The Bandwidth Metric MUST be set to the maximum metric value of >>> 4,261,412,864. >>> >>> 2. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold 1 and less than Bandwidth Threshold 2: >>> * The Bandwidth Metric MUST be set to Threshold Metric 1. >>> >>> 3. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold 2 and less than Bandwidth Threshold 3: >>> * The Bandwidth Metric MUST be set to Threshold Metric 2. >>> >>> 4. In general, for all integer values of X such that 1≤X<N: >>> * When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold X and less than Bandwidth Threshold X+1: >>> ** The Bandwidth Metric MUST be set to Threshold Metric X. >>> >>> 5. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold N: >>> * The Bandwidth Metric MUST be set to Threshold Metric N. >>> >>> Notes: >>> >>> * The term Bandwidth Threshold X refers to a predefined threshold value >>> corresponding to the index X. >>> * The term Threshold Metric X refers to the metric value associated with >>> Bandwidth Threshold X. >>> * N represents the total number of bandwidth thresholds defined in the >>> system. >>> * The maximum metric value of 4,261,412,864 indicates that the link is >>> considered unreachable for the purposes of the Flex-Algorithm SPF >>> calculation. >>> >>> Implementations MUST ensure that these rules are consistently applied to >>> maintain interoperability and optimal path computation within the network. >>> " >>> >>> 872 The IS-IS FADBT sub-TLV MUST NOT appear more than once in an >>> IS-IS >>> 873 FAD sub-TLV. If it appears more than once, the IS-IS FAD >>> sub-TLV >>> 874 MUST MUST stop participating in such flex-algorithm. >>> >>> GV> s/MUST MUST/MUST/ >>> GV> Is it deliberate that here is written to stop participating in such >>> flex-algo, where at line 762 is written that "the IS-IS FAD sub-TLV MUST be >>> ignored by the receiver.". Is this intended? >>> >>> 934 When granularity_bw is less than or equal to >>> Total_link_bandwidth >>> 935 >>> 936 Metric calculation: (Reference_bandwidth) / >>> 937 (Total_link_bandwidth - >>> 938 (Modulus >>> of(Total_link_bandwidth, >>> 939 granularity_bw))) >>> 940 >>> 941 When granularity_bw is greater than Total_link_bandwidth >>> 942 >>> 943 Metric calculation: Reference_bandwidth/ >>> 944 Total_link_bandwidth >>> 945 Figure 10: OSPF FADRB Sub-TLV >>> >>> GV> I was wondering to mention that for completeness this is an integer >>> division? >>> >>> 957 automatically derived metric for that link.In case of >>> Interface Group >>> 958 Mode, if all the parallel links have been advertised with the >>> 959 Bandwidth Metric, The individual link Bandwidth Metric MUST be >>> used. >>> 960 If only some links among the parallel links have the Bandwidth >>> Metric >>> 961 advertisement, the Bandwidth Metric for such links MUST be >>> ignored >>> 962 and automatic Metric calculation MUST be used to derive link >>> metric. >>> >>> GV> proposed rewrite >>> >>> " >>> Metric Assignment in Interface Group Mode: >>> When a link does not have a configured Bandwidth Metric, the automatically >>> derived metric MUST be used for that link. >>> >>> 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. >>> >>> This approach ensures consistent metric calculation and avoids >>> discrepancies caused by partial Bandwidth Metric advertisements among >>> parallel links. >>> " >>> >>> 1036 When the computed link bandwidth is less than Bandwidth >>> Threshold 1 , >>> 1037 the MAX_METRIC value of 4,294,967,296 MUST be assigned as the >>> 1038 Bandwidth Metric on the link during the Flex-Algorithm SPF >>> 1039 calculation. >>> 1040 >>> 1041 When the computed link bandwidth is greater than or equal to >>> 1042 Bandwidth Threshold 1 and less than Bandwidth Threshold 2, >>> Threshold >>> 1043 Metric 1 MUST be assigned as the Bandwidth Metric on the link >>> during >>> 1044 the Flex-Algorithm SPF calculation. >>> 1045 >>> 1046 Similarly, when the computed link bandwidth is greater than or >>> equal >>> 1047 to Bandwidth Threshold 2 and less than Bandwidth Threshold 3, >>> 1048 Threshold Metric 2 MUST be assigned as the Bandwidth Metric on >>> the >>> 1049 link during the Flex-Algorithm SPF calculation. >>> 1050 >>> 1051 In general, when the computed link bandwidth is greater than or >>> equal >>> 1052 to Bandwidth Threshold X AND less than Bandwidth Threshold X+1, >>> 1053 Threshold Metric X MUST be assigned as the Bandwidth Metric on >>> the >>> 1054 link during the Flex-Algorithm SPF calculation. >>> 1055 >>> 1056 Finally, when the computed link bandwidth is greater than or >>> equal to >>> 1057 Bandwidth Threshold N, then Threshold Metric N MUST be assigned >>> as >>> 1058 the Bandwidth Metric on the link during the Flex-Algorithm SPF >>> 1059 calculation. >>> >>> GV> From readability maybe following rewrite/restructuring proposal: >>> >>> " >>> Assignment of Bandwidth Metric Based on Computed Link Bandwidth: >>> >>> The Bandwidth Metric for a link during the Flex-Algorithm Shortest Path >>> First (SPF) calculation MUST be assigned according to the following rules: >>> >>> 1. When the computed link bandwidth is less than Bandwidth Threshold 1: >>> * The Bandwidth Metric MUST be set to the maximum metric value of >>> 4,294,967,296. >>> >>> 2. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold 1 and less than Bandwidth Threshold 2: >>> * The Bandwidth Metric MUST be set to Threshold Metric 1. >>> >>> 3. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold 2 and less than Bandwidth Threshold 3: >>> * The Bandwidth Metric MUST be set to Threshold Metric 2. >>> >>> 4. In general, for all integer values of X where 1≤X<N: >>> * When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold X and less than Bandwidth Threshold X+1: >>> ** The Bandwidth Metric MUST be set to Threshold Metric X. >>> >>> 5. When the computed link bandwidth is greater than or equal to Bandwidth >>> Threshold N: >>> * The Bandwidth Metric MUST be set to Threshold Metric N. >>> >>> Notes: >>> * Bandwidth Threshold X refers to the predefined bandwidth threshold >>> corresponding to index X. >>> * Threshold Metric X is the metric value associated with Bandwidth >>> Threshold X. >>> * N represents the total number of bandwidth thresholds defined in the >>> system. >>> * The maximum metric value of 4,294,967,296 indicates that the link is >>> effectively considered unreachable during the Flex-Algorithm SPF >>> calculation. >>> >>> Implementations MUST consistently apply these rules to ensure accurate path >>> computations and maintain interoperability within the network. >>> " >>> >>> G/ >>> _______________________________________________ >>> Lsr mailing list -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
