Early Review of draft-ietf-mboned-cbacc-05
review-ietf-mboned-cbacc-05-tsvart-early-trammell-2025-07-08-00

Apologies for the slightly late early review. Also, note: I'm not a YANG
doctor, and don't play one on Youtube, so I assume the usage of netconf in this
proposal is at the very worst unproblematic; I'm only looking at transport/CC
relevant issues here.

This document still needs some work, but I assume the authors are aware of this
as they're the ones who stuck the various TBDs in the text. :) That said,
what's there is encouraging and I think this work is on the right track.

Open questions:

(1) This document maps its concepts incompletely to the terminology of RFC
8084, in a way that I found (as someone who also had to reread 8084 to complete
this review) found confusing. Pointedly 8084 assumes a feedback loop where the
egress meter (on the downstream end of a protected path) causes the ingress
meter to trigger when the circuit breaker trips, while this document seems to
assume that the control point is at the egress meter. I'm not actually certain
whether this matters, since tripping downstream will eventually unload the
upstream path. I also note that the authors note that other reviewers found the
8084 terminology confusing. It probably makes sense for this document to note
explicitly that it is modifying the architectural assumptions in 8084
(replacing an "ingress meter" with an ingress rate declaration via netconf, and
moving the control point forward).

(Thanks for section 1.3, by the way, it made this review *way* easier to jump
into than would otherwise have been the case)

(2) Parallel to current discussions in SCONE, which is dealing with an adjacent
problem (throughput guidance for unicast flows to avoid traffic shapers, which
are their own kind of single-point circuit breaker), the choice of a timescale
is important when defining a trigger function, and I expect the currently TBD
section 2.3.1 will go into this in some detail when it is no longer TBD.