IGP Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
draft-ietf-lsr-flex-algo-bw-con-22

Section 1, 'elephant flows', I had to look this up, it might be worth a small explanation.  

Section 5, 'winning FAD', I'm not sure what to think of this.  It seems odd.  Does a particular definition actually 'win'?  What happens to the loser definitions?

Section 7 or 8:  It appears that this might be a bigger opportunity for a denial of service attack?

Thank you to Christer Holmberg for the GENART review.

Thank you for addressing my DISCUSS and COMMENT feedback.

# Éric Vyncke, INT AD, comments for draft-ietf-lsr-flex-algo-bw-con-18
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status, there is no justification for six authors though.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS (non-blocking)

### Support of metrics by IGP routers

It is perhaps specified in other RFCs, but I failed to see the specification of what to do when a router receives a metric that it does not support.

### Section 1

Should the terms throughput be used in addition to bandwidth ? E.g., s/High bandwidth traffic/High throughput traffic/ ?

s/This document proposes /This document specifies / (or "defines"), after all it will be published as a PS RFC ;-)

Else, this section is super well written and easy to read.

Suggest adding a reference to "PCE".

### Section 2

Suggest adding references to IS-IS and OSPF.

Please expand "ASLA".

### Section 2.1

It took me a while to understand that figure 1 is not part of bullet item g. Please insert some leading text to ensure a clear understanding of the figure 1 between bullet g and the figure 1. Like done in section 2.2 for figure 2.

### Sections 2.1 & 2.2

`The value is taken from the "IGP metric-type" registry maintained by IANA`, but it was written previously that values 128-255 are for private use.

### Section 3.1.1

Should there be a reference to `IEEE floating point format (32 bits)` ?

### Section 10.1

Strongly suggest to add a reference to https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-metric-type rather than using "IGP Metric-type Registry"

## NITS (non-blocking / cosmetic)

## Requirements language

While correct, it appears at an unusual location. I guess that the RFC editor will fix it.

### Section 2.1

s/0XFFFFFF/0xFFFFFF/ or be consistent on how to write hexadecimal constant.

### Section 9

s/When user defined metrics/When user-defined metrics/

### Section 10.1

s/ pariticular / particular /

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-)

In Section 4.1.3.2 you seem to have forgotten that a 3 byte metric can only encode 2^24-1. It looks like you pasted the OSPF encoding without revising the possible metric range.