[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-lsr-flex-algo-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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

Thank you for the work put into this document. The underlying concept is
brillant and can be useful, but it was hard for me to understand all the
details as the document is rather tedious to read (and to author -- so
congrats!), I may have misunderstood several points.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Acee Lindem for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status. ***But***, I
regret the lack of reply to the question about `WG discussion and conclusion
regarding the IPR disclosures`.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Alvaro's DISCUSS

Just to write that I find Alvaro's DISCUSS points sensible, but I am sure that
the authors will address those points.

### Who allocates the flex algo ID

After reading the I-D (and skipping some too deeply technical parts to be
honest), I still wonder whether it is the operator who defines locally
significant flex algo ID or whether it will be the IETF by standard actions. I
was about to raise a DISCUSS on this point.

### Section 1

For the non-expert reader, it would be nice to shortly indicate why this
document is about SRv6 locators and not SRv6 SIDs. (no need to explain this to
me BTW ;-) )

### Section 4

In `We want the mapping`, who is the "we" ? Please do not use such ambiguous
sentence patterns.

In `As long as all routers in the domain`, what is the "domain" ? The OSPF
area? the AS? another concept ?

In `The following values area allocated from this registry for
Flex-Algorithms`, the reader would benefit to already understand which party
(operator/IANA/?) will assign specific values in that range.

### Section 5.1

Even if obvious, it will not hurt to have the unit specified in `Length:
variable,`.

### Section 5.1 Calc-Type

I am probably confused and lost due to my lack of knowledge... But the
definition of Calc-Type:

1) specifies that type 0 is SPF, which is useless as the IANA
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
already says so. I.e., why addin useless/redundant information in the normative
part (use of MUST)

2) the same IANA registry
https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types
has a clear indication that value 2-127 are unassigned. I.e., this I-D should
not add constraints in this registry.

### Section 5.1 Priority tie

What is the expected behavior when there is a priority tie ? Perhaps add a
forward reference to section 5.3 ?

### Sections 6.2 and 6.3

Suggest to repeat the TLV format from section 6.1.

### Sections 6.4, 7.4

Sorry, but cannot understand/parse `Bits that are not transmitted MUST be
treated as if they are set to 0 on receipt.` Is the meaning "bits defined by
further specification but not in the actual transmitted TLV" ?

What is the expected behavior when length is 0, i.e., I would assume that SRv6
nodes will either do not send this TLV or send it with length=0.

### Section 11

Again a "we" in `we say it`, please rephrase without using ambiguous "we".

### Section 20.1

Is RFC 8986 really normative? I would have assumed it is informative.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

*************
As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion; I really think that the
document would be improved with a change here, but can be convinced otherwise.

Check for IPv4, IPv6, address, NAT, ICMP, MTU

As usual, as the responsible AD for the ADD WG, I have done an AD review before
the IETF Last Call. Please find a MD-formatted review below. Before going
further, I am requesting the authors to act/reply/comment on all the points
below. The end goal is to ease the rest of the publication process.

Please note that Tim Winters is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir reviews as well when Tim
will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/