Hi Acee, Thanks for the reminder. Not yet. Will do later this week or during next week.
G/ Sent from Outlook for iOS<https://aka.ms/o0ukef> ________________________________ From: Acee Lindem <[email protected]> Sent: Wednesday, November 27, 2024 6:02:03 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: shraddha <[email protected]>; [email protected] <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] [Shepherding AD review] review of draft-ietf-lsr-flex-algo-bw-con-15 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hey Gunter, Did you get a chance to look at the -16 version? Thanks, Acee > On Nov 25, 2024, at 5:56 AM, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > Shraddha, > Thanks for the fast response. > I believe we are almost there. > Follow-up remarks inline with: GV2> > From: Shraddha Hegde <[email protected]> > Sent: Friday, November 22, 2024 6:00 PM > To: Gunter van de Velde (Nokia) <[email protected]>; > [email protected] > Cc: lsr <[email protected]> > Subject: RE: [Shepherding AD review] review of > draft-ietf-lsr-flex-algo-bw-con-15 > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > Hi Gunter, > Thanks for the detailed review and comments. > Pls see inline for the replies. > Version -16 will contain the changes. > Rgds > Shraddha > Juniper Business Use Only > From: Gunter van de Velde (Nokia) <[email protected]> > Sent: 19 November 2024 22:00 > To: [email protected] > Cc: lsr <[email protected]> > Subject: [Shepherding AD review] review of draft-ietf-lsr-flex-algo-bw-con-15 > [External Email. Be cautious of content] > # 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. > " > <SH> Will update the draft with the new > 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? > <SH> yes. > 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. > " > <SH> ok > 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? > <SH> legacy metric types MUST be used from the existing TLV/sub-TLVs and if > generic metric advertises legacy metric It MUST be ignored. > Since IGP Metric-type registry is common Legacy metric-types may appear there. > GV2> I believe I understand. Is the following accurately describing the > procedure you had in mind?: > “ > For a link, if the metric type corresponds to a metric type for which legacy > advertisement > mechanisms exist (e.g., the IGP metric, the Minimum Unidirectional Link > Delay, or the > Traffic Engineering Default Metric), the legacy metric types MUST be utilized > from the existing > TLV or sub-TLVs. If a Generic Metric advertises a legacy metric, it 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***.". > <SH> OK added in parenthesis “that Flex-Algorithm in its source area or > domain (source area from the ABR perspective)”. > Pls confirm if it looks ok. > GV2> Looks accurate. Thank you > 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'? > <SH> It should be “lower”. Only then excluded. > GV2> ok. 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? > <SH> It should be “higher” to be excluded > GV2> OK > 546 not aadvertised for a link but the FAD contains this > sub-TLV,then > GV> s/aadvertised/advertised/ > <SH> OK > 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) > <SH> I don’t think there is any special consideration for stub-links but you > bring about an important point about overload. I think we should mention how > overload scenarios apply to > Generic metric. > GV2> Yes. Thank you. Overload is a behaviour that seem to cause confusion > and interop issues. I have seen inconsistencies at operators when overload > (especially with max metric) is used, Having guidance will be helpful for > consistent implementations > 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?) > <SH> ok > 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 > <SH> What you described is right but the text here is just giving an example > for the reader to understand what is expected. The accurate formula for > computation is given in sec 4.1.3.1 > I feel explaining more here might be unnecessary. Let me know what > you think. > GV2> I am divided and it is a hill I am not willing to die upon. If you feel > it is overloading the intent of this text blob, then that that works for me > 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? > <sH> ok > 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. > " > <SH> OK > 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. > " > <SH> I’ll take the text most of it. It’s definitely more organized and easy > to read. > “* 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.” > In Flex-algo the link in considered unreachable if the there is no metric > advertisement for the link. Max metric links are considered reachable. > 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/ > <SH>ok > 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? > <SH>. All other scenarios the receiver ignores multiple sub-TLVs in the FAD. > It should apply here as well for consistency. I don’t see any special reason > “stop participating” > GV2> Thank you for your input. I agree that “ignoring the invalid FAD” is > sufficient. To stop participating , because an invalid FAD exists seems to be > more constrained then classic flex-algo procedures at first glance. > 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? > <SH> ok > 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. > " > <SH> ok > 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. > " > <SH> ok > G/ > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
