Re: [Lsr] Working Group Last Call for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-ietf-lsr-flex-algo-bw-con-07

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
<https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#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
<https://www.ietf.org/archive/id/draft-ietf-lsr-flex-algo-bw-con-08.html#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 <acee.lindem@gmail.com> 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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>