[Last-Call] Genart last call review of draft-ietf-tsvwg-ecn-encap-guidelines-20

[Susan Hares via Datatracker <[e-mail]>]

Reviewer: Susan Hares
Review result: Ready with Issues

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-tsvwg-ecn-encap-guidelines-??
Reviewer: Susan Hares
Review Date: 2023-10-28
IETF LC End Date: 2023-11-02
IESG Telechat date: Not scheduled for a telechat

Summary: The document summarizes decades of work on congestion work in IEEE
802.1 and IETF.  It provides a set of good guidelines/recommendations for
designers of Layer-2 (L2) or L2/L3 shim layer.

The authors (John Kaippallimalil and Bob Briscoe) and the original author/
now-contributor (Pat Thaler) should be commended for their work.

The text is generally readable with relatively few English and editorial
issues.  However, the authors would be wise to fix the editorial issues prior
to sending it to the RFC editor since phrasing needs to be precise.

Major issues: none.

Minor issues:

1. Have the authors considered the SR-routing pathways with tunnels in this
draft?
   If so, the authors might add a side note in the document.
2. Has this document been circulated by the IETF liaisons to IEEE 802.1, MEF,
and 3GPP? 3. Are you really sure your security and manageability sections are
complete?
        RFC7713 predates large deployment of SR routing.

Nits/editorial comments:

Formatting in the pdf seems to be problematic.  I am not commenting on this
point since html form does not have hte same problem.

Nits in Editing:
Section 2
Old/Not-ECN-PDU:
A PDU at the IP layer or below that is part of a congestion control
feedback-loop within which at least one node necessary to propagate any
explicit congestion notification signals back to the Load Regulator is not
capable of doing that propagation./ New:/Not-ECN-PDU: A PDU at the IP layer or
below that is part of a congestion control feedback-loop within which at least
one node necessary to propagate any explicit congestion notification signals
back to the Load Regulator this PDU is not capable of doing that propagation./

Section 3
Text:/
The router forwards the marked L3 header into subnet 2, and when it adds a new
L2 header it copies the L3 marking into the L2 header as well, as shown by the
'C's in both layers (assuming the technology of subnet 2 also supports explicit
congestion marking)./

Question - did you mean subnet b instead of subnet 2 (per figure 1)

Section 4.3
Text:/
This ensures that bulk congestion monitoring of outer headers (e.g. by a
network management node monitoring ECN in passing frames) will measure
congestion accumulated along the whole upstream path — since the Load Regulator
not just since the ingress of the subnet. /

The portion of this sentence that has me confused is "since the Load Regulator
not just since the ingress of the subnet.".   I'm not really sure what you are
trying to say - so I have no suggested new text.