Hello Authors/All, In general, I support the adoption of this document. There is, however, one specific point which is not clear to me (8) below that I would appreciate some clarity on before adoption.
Some questions/comments/suggestions: 1. Why is the Generic Metric type in ISIS limited to 3 byte size? OSPF allows 4 byte size and so why not the same for ISIS? Elsewhere in the document, I do see MAX METRIC being referred to as 4,261,412,864. 2. Would be good to cover the max-metric considerations for the Generic Metric. Similar to https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-15#section-15.3 3. Since the draft is covering FlexAlgo, I would have expected that Generic Metric is carried only in the ASLA and this document specifies usage only for the FA application. Later this can be also used/extended for other applications but still within ASLA. Keeping an option of advertising both outside and within the ASLA is problematic – we will need precedence rules and such. I prefer we avoid this complication. 4. For the newly proposed FAD b/w constraints, I would suggest the following names for the constraint sub-TLVs where the b/w value signalled by all is compared with the Max Link B/w attribute. This is just to make the meaning, at least IMHO, more clear. * Exclude Higher Bandwidth Links * Exclude Lower Bandwidth Links * Include-Only Higher Bandwidth Links * Include-Only Lower Bandwidth Links 5. Similar naming for the FAD delay constraints as well would help. Though I can only think of the use of “exclude” for links above a certain delay threshold to be more practical but perhaps others might eventually be required as well? 6. For the Max B/w Link attribute and its comparison with the FAD b/w constraints, I see the reference to ASLA. While in OSPF max-bandwidth is not allowed in ASLA - https://datatracker.ietf.org/doc/html/rfc8920#section-7, in case of ISIS also, it is not really appropriate for use within ASLA - https://datatracker.ietf.org/doc/html/rfc8919#section-4.2.1? 7. Document should cover the FAPM aspects for the Generic Metric and especially the Bandwidth metric. 8. The document introduces a new Generic Metric type called Bandwidth metric. I’ve been trying to follow some of the discussion related to this on the mailing list – about it being cumulative or not. I am perhaps somewhat confused by those discussions. The OSPF/ISIS SPT computation has always worked with cumulative link (and prefix) metrics. If the computation for the Generic Metric of this new type b/w is not going to be cumulative (I thought it is – but not very clear anymore), then the document needs to describe the computation algorithm. Is it then hop count based? Perhaps I am missing something very basic here and if so, please point me to the text in the draft. Thanks, Ketan From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) Sent: 13 May 2021 02:39 To: lsr@ietf.org Cc: draft-hegde-lsr-flex-algo-bw-...@ietf.org Subject: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02 Esteemed Members of the LSR WG, This begins a 2 week WG adoption call for the following draft: https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/ Please indicate your support or objection by May 27th, 2021. Authors, please respond to the list indicating whether you are aware of any IPR that applies to this draft. Thanks, Chris and Acee
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
