É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. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
