Éric Vyncke's No Objection on draft-ietf-rtgwg-segment-routing-ti-lfa-13: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-rtgwg-segment-routing-ti-lfa-13: 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-rtgwg-segment-routing-ti-lfa/



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


# Éric Vyncke, INT AD, comments for draft-ietf-rtgwg-segment-routing-ti-lfa-13

Thank you for the work put into this document. The flow appears to be logical
and the text well explained, but to be honest it is too specific and too
acronyms-heavy for me, i.e., my review is rather superficial and I am trusting
the RTG ADs for their content review. Nevertheless, I like the clarity of
section 10.

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

Special thanks to Stewart Bryant for the shepherd's detailed write-up including
the WG consensus *but it lack* the justification of the intended status. I like
the `This is a deployed protocol.` ;-) OTOH, the justification for *6* authors
is rather weak: `The document has taken seven year to get to this point and
seems to have settled at this number of authors.`

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

Should "IP-FRR" be expanded ?

## Section 6

This section contains multiple "SHOULD" but does not explain when the "SHOULD"
can be bypassed.

## Section 8.2

I am afraid cannot parse `Then the packet is protected as if its were a transit
packet.`

## Section 12

This is value information of course even if the actual networks are not
referenced. Beside the depth of the SID list, I would have welcome the amount
of additional repair entries required in the node (is it simply destinations *
links ?) as it could have an impact of amount of states in the routers.

# NITS (non-blocking / cosmetic)

## Section 2

Usually acronyms are introduced *after* the expansion, e.g., not as in `TLDP
sessions (Targeted Label Distribution Protocol)`

## Section 2.1

This BCP14 template should probably better placed after the acronyms.