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)