Thanks a lot for the through review
I published version 17 to address your comments
See #Ahmed inline
Ahmed
On 4/10/24 1:39 AM, Éric Vyncke via Datatracker wrote:
É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.`
#Ahmed: Every author on this draft put significant effort in it. IMO to
be fair to some contributors, that draft should have at least 9 authors.
For example, we did not add the authors of the appendix A and B where we
an see actual results from actual networks.
What other justification is needed?
I hope that this review helps to improve the document,
Regards,
-éric
# COMMENTS (non-blocking)
## Abstract
Should "IP-FRR" be expanded ?
#Ahmed: Expanded in version 17
## Section 6
This section contains multiple "SHOULD" but does not explain when the "SHOULD"
can be bypassed.
#Ahmed. "SHOULD" is used in may RFCs without explaining when it can be
bypassed. As an example, RFC7490 and RFC7916, both referenced in this
document, use SHOULD without explaining when the "SHOULD" can be
deviated from or bypassed
## Section 8.2
I am afraid cannot parse `Then the packet is protected as if its were a transit
packet.`
#Ahmed version 17 changed the wording of this sentence to make it more clear
## 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.
#Ahmed: This whole section has been moved to Appendix. However the
additional amount of state heavily depends on the forwarding plane
architecture and it was not available to us at that time.
# NITS (non-blocking / cosmetic)
## Section 2
Usually acronyms are introduced *after* the expansion, e.g., not as in `TLDP
sessions (Targeted Label Distribution Protocol)`
#Ahmed: We no longer use thus acronym in the document. So it was removed
## Section 2.1
This BCP14 template should probably better placed after the acronyms.
#Ahmed: Version 17 did that
_______________________________________________
rtgwg mailing list -- rtgwg@ietf.org
To unsubscribe send an email to rtgwg-le...@ietf.org
