Last Call Review of draft-ietf-opsawg-oam-characterization-04
review-ietf-opsawg-oam-characterization-04-opsdir-lc-chown-2024-11-21-00

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft is an attempt to harmonise use of OAM terminology, with a focus on
common ambiguous terms such as in-band and out-of-band. As it stands, both of
these terms would be deprecated (no future use) by the document, with more
specific language bing proposed instead.  Other terminology is proposed with
the noble aim to make future documents clearer in their use of language around
OAM.

While noble, the document is a hard read. I found myself repeatedly looking
back to check the earlier definitions of new terms. I wonder whether the
document tries to do too much, and to prescribe too many terms.

I have to say at this time due to the lack of clarity and its complexity the
document is Not Ready to move to the IESG, but I note the WGLC has completed
before me writing this, so that position has already been established.

It’s not clear where the proposed new terminology has come from, or who was
consulted.  I check by searching on the data tracker (*). There are 27 current
“oam” I-Ds, 9 of with are WG-adopted, and 55 RFCs, around 13 of which have been
published in the last two years. Some review of these would be prudent, if this
hasn’t happened already.

I would also agree with soliciting feedback from groups such as detnet, ippm,
maprg and others where definitions of and use of OAM methods are common.  Do
the proposed terms meet their needs? Do they seem intuitive?

I have read a few OAM documents. I don’t necessarily feel confused by them,
e.g, RFC 9634. Perhaps a simpler first step here is to publish a shorter draft
deprecating “in-band” and “out-of-band”, which can be genuinely ambiguous,
requiring clarity in new drafts without prescribing exactly how, as there is a
lot of variety in use cases.  Which is what is said at the start of 2.1.  So
long as the drafts are clear, is it a problem?

Other comments:

2.1
Non-path-congruent or path-incongruent?
In many cases, you just won’t know if they are congruent or not, due to certain
load balancing methods. In-band can include OAM inserted on path. In-Packet OAM
*can* be Non-path-congruent, can’t it?  Consider OAM data in a v6 DO. On
forwarding treatment, v6 EHs can cause different treatment when packets get
punted to the slow path (another type of path!) I don’t understand the Combined
OAM part.

3.
The phrase “dedicated OAM packets” is used, but we should call this “dedicated
packet OAM” if following the document? What’s an atomic OAM packet? What’s
explicit OAM? “Compound OAM” seems unnecessary, just use the combinations?

5.
“En/de-capsulating” is a bad term as it may be insertion, or modification, not
adding / removing a header. A transparent node should also not drop any OAM.

Tim

(*)
https://datatracker.ietf.org/doc/search?name=OAM&sort=&rfcs=on&activedrafts=on&by=group&group=