Reviewer: Thomas Fossati Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-v6ops-hbh-10 Reviewer: Thomas Fossati Review Date: 2024-08-25 IETF LC End Date: 2024-09-02 IESG Telechat date: Not scheduled for a telechat Summary: The state of IPv6 hop-by-hop options header (HBH) processing is sub-optimal (see also draft-ietf-6man-eh-limits). This document tries to make a case for fixing HBH processing in network devices so that new and existing services that depend on HBH can be successfully deployed. The draft, in its current form, is IMO not ready. I found the presentation of the contents lacking internal coherency. More generally, there appears to be a lack of alignment between the goals stated in the abstract & introduction and the content presented. The draft sets out to achieve some ambitious goals: * "Break the endless cycle that resulted in HBH being a DOS vector" * "HBH option header […] deployed without operational impact." but reading through the document it was unclear to me what kind of actions were required and from whom to get there. Is this an ask to vendors to allow configurability of HBH processing? Or for operators to use such configurability, if available? Or for operators to upgrade their equipment? Or for operators to require HBH-friendly equipment in their RFPs? The reader gets a bit lost in the discussion around the technical details. However, as a v6ops deliverable, I think the document should be framed in terms of what is expected of the network operators, leaving the technical description to other referenced documents for clarity. Another thing that puzzles me is the dependency on draft-ietf-6man-hbh-processing. Is the publication and implementation of that document the keystone? Is that the reason why it's referenced normatively? ISTM that the editors and the working group should make the scope, aims and means of this document more precise, clear and actionable. Nits/editorial comments: # Abstract * Remove duplicated sentence: "This document outlines reasons why the Hop-by-Hop Options Header is rarely utilized in current networks." * In: "[...] allowing deployment and operations of new services requiring a more optimized way to leverage network resources [...]”, do you really mean "requiring" or "leading to"? # Introduction See overall comments. # New Services * I suggest rewriting to convey 9343’s goal: "The Alternate Marking Option is a new IPv6 Hop-by-Hop option for passive performance measurements [RFC9343]." * I suggest rewriting for clarity: "This Hop-by-Hop option is intended for use within data centers, between data centers, and across the general Internet. It provides a valuable tool for optimizing paths with a large Path MTU." * Small typos (missing '-', missing "be", and extra '.'): "A Virtual Transport Network (VTN) Option is used to carry the VTN-related information, which could be used to identify the set of network resources allocated to a VTN and the rules for packet processing [I-D.ietf-6man-enhanced-vpn-vtn-id]." * In "[...] but each plane is responsible for different functions.", the us of the adversative (but) seems misplaced.. # Modern Router Architecture * Typo: s/on only/only on/ * Please fix this stray sentence: "IPv6 Extended Header limitations that need to be addressed to make HBH processing more efficient and viable in the forwarding plane." * The contents of this section are a bit scattered, with light internal coherency. From the title I'd have expected a more in-depth description of the "modern router" but that’s not the case. # Specification of RFC8200 * IMHO this doesn't deserve a section on its own. It seems sufficient to say that the limitations in 8200 are being addressed in draft-ietf-6man-hbh-processing. # Common Implementations * The last paragraph restates content that was already presented. I suggest to drop the C&P. # Design Principles and Migration Strategies The content here seems mostly directed to protocol designers rather than operators. # References * It is not clear in what sense [I-D.ietf-6man-eh-limits], and [I-D.ietf-6man-hbh-processing] are normative. * Refresh refs (e.g,., HBH processing is now -20 vs -12) -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
