Co-Authors, I believe these are the only pending WG last comments.
Thanks, Acee > On Mar 21, 2024, at 12:36 PM, Ketan Talaulikar <[email protected]> wrote: > > Hi All, > > I have reviewed this document and believe it needs some further work before > publication. > > I am sharing my comments below: > > 1) There is the following text in sec 2.1 and 2.2 for Generic Metric. > > A metric value of 0xFFFFFF is considered as maximum link metric and a link > having this metric value MUST NOT be used during Flex-algorithm calculations > [RFC9350]. The link with maximum generic metric value is not available for > the use of Flexible Algorithms but is availble for other use cases. > > I believe the FlexAlgo reference here is to > https://www.rfc-editor.org/rfc/rfc9350.html#name-max-metric-consideration > But the above text does not align with the RFC9350. If a link is to be made > unavailable for FlexAlgos operating with a specific Generic Metric, then the > way to do that is to omit that specific Generic Metric TLV from the ASLA for > flex-algo application. The same would apply for other applications - just > omit the metric. Why do we need a special MAX-LINK-METRIC value for generic > metric given that it is a new thing we are introducing? > > 2) This comment is specific to OSPF given the encoding differences it has > with ISIS. Section 2.2 allows for Generic Metric TLV to be used in too many > places without clear specification of what it is used for - this is a > potential pitfall for interop issues. RFC9492 provides helpful directions for > us here. > a) This draft specifies FlexAlgo extensions, it is natural that Generic > Metric be advertised under ASLA TLV. No issues here. > b) This draft does not specify anything about use of generic metric in base > OSPF and as a reminder there is nothing like L-bit in OSPF encoding. > Therefore, it does not make sense to advertise Generic Metric outside of ASLA > and under the OSPFv2 Extended Link TLV or OSPFv3 Router Link TLV. > c) This draft does not specify anything about use of generic metric with > RSVP-TE/GMPLS. Therefore, it does not make sense to advertise Generic Metric > in the TE Opaque LSAs. > We can have specific documents that introduce (b) or (c) when there is a > proper specification. > > 3) Please introduce a reserved field to pad the OSPF FAEMD sub-TLV to a 4 > octet boundary as is the convention in OSPF - > https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-3.2.2 > > 4) In section 3.2.2 there is the following text for OSPF. Could you please > use the TLV/sub-TLV name? OSPF folks are not good at remembering numbers ;-) > > The Min Unidirectional Link Delay as advertised by sub-sub-TLV 12 of ASLA > sub-TLV [RFC8920], MUST be compared against the Maximum delay advertised in > the FAEMD sub-TLV. > > 5) Do we want to call out that the reference bandwidth approach requires a > router to compute and maintain a per link per algo bandwidth metric for every > link in that algo topology. It may not be very obvious to some. > > 6) There are a lot of procedures which are common to both OSPF and ISIS and > are repeated in each section instead of a common section. It would be easier > (and avoid errors) if there was some consolidation. > https://www.rfc-editor.org/rfc/rfc9350.html#section-5 provides a good > reference for such an organization of text. > > 7) Regarding > https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#section-6, > it seems like we want to retain a numbering ordering of rules/sequence for > flex-algo as extension documents are introduced. Am I correct? If so, then > this document should formally "update" RFC9350 since it is changing the "set > of rules/sequence" for FlexAlgo computations. Further such extensions will > also need to keep updating the base spec similarly. I would suggest that a > full set of rules that is a union of what is in RFC9350 and rules added by > this draft are maintained in an Appendix section. Other documents in the > future can similarly maintain the latest set of rules. > > 8) Please fix idnits warnings - some are related to obsolete references while > others are related to formatting. There are also some spelling/grammar errors. > > Thanks, > Ketan > > > On Tue, Feb 20, 2024 at 3:56 AM Acee Lindem <[email protected]> wrote: > > This starts the Working Group Last call for > draft-ietf-lsr-flex-algo-bw-con-07. At least some of the flex algorithm > enhancements described in the document have been implemented. > > Please send your support or objection to this before March 5th, 2024. > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
