Early Review of draft-ietf-rtgwg-qos-model-13
review-ietf-rtgwg-qos-model-13-tsvart-early-black-2025-10-30-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the WIT area directors, but are copied to the document's authors
and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Colin Perkins' earlier TSV-ART review of the -11 version of this draft
(https://datatracker.ietf.org/doc/review-ietf-rtgwg-qos-model-11-tsvart-lc-perkins-2023-12-06/)
continues to be applicable to this -13 version of the draft.  That review notes
the use of dated AQM algorithms (RED, WRED) and recommends inclusion of support
for more modern AQM algorithms, which appears to have been done.  The
color-based markers (overview in sections 3.1 and 3.2) are analogously dated,
and the authors are likewise encouraged to make an updated check on "commonly
used algorithms in industry" (quoted from section 2 of the draft), as "grouping
meter" does not appear to contain any meters aside from those used in the
color-based markers. Token bucket and/or leaky bucket metering would be
possibilities to include.  In general, it's important to provide support for
mechanisms used by network operators, not just those for which RFC or other
documentation can be readily located, and I concur with Colin's observations on
the importance of extensibility (e.g., so that network operators are able to
add their own operator-specific mechanisms).

The DSCP modeling in this draft uses ranges to specify the DSCP code points for
classifiers.  This appears to violate RFC 2474, which states (in Section 3):
"DS-compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP
field, e.g., by treating the value of the field as a table index which is used
to select a particular packet handling mechanism which has been implemented in
that device." To be pedantic, a range match condition can be viewed as an
optimized implementation and/or representations of a collection of individual
match conditions on each value in the range, but this needs some discussion and
guidance to network administrators.  The Configuration example for QoS
Classifier in Appendix C.1 provides a worked example of how to get in trouble
in this area, as the DSCP range of 11-13 consists of (see
https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml#dscp-registry-1):
a Pool 2 DSCP reserved for experimental or Local Use (11), a Pool 1 DSCP that
is the default for the AF12 PHB (12), and a Pool 3 DSCP whose default behavior
is effectively reserved for future standardization (13).  While use of this
DSCP range is not prohibited, it's not a good example of 3 DSCPs that are
generally reasonable to map to the same PHB and/or result in packets marked
with them receiving the same packet handling treatment.  If this draft
continues to use DSCP ranges, the draft needs some discussion about how that
use of DSCP ranges aligns with the requirement quoted from RFC 2474, and the
example in Appendix C.1 probably should be revised to something more
reasonable.  In general, range match and match under mask are not good ways to
match DSCPs due to the structure of the DSCP value pools (see the IANA
registry).

Beyond these two concerns, I concur with Colin's concluding remarks that this
draft seems broadly ready.  Like Colin, I have not reviewed the YANG in detail.