Early Review of draft-ietf-detnet-mpls-oam-09
review-ietf-detnet-mpls-oam-09-rtgdir-early-hardwick-2022-12-12-00

Hi there

I have been selected to do a routing directorate "early" review of this draft.
draft-ietf-detnet-mpls-oam-09 - Operations, Administration and Maintenance
(OAM) for Deterministic Networks (DetNet) with MPLS Data
Plane<https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/09/>

The routing directorate will, on request from the working group chair, perform
an "early" review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft's lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is already post working group last call, my focus for the
review was to determine whether the document is ready to be published.

For more information about the routing area directorate, please see RtgDir -
Routing Area Wiki (ietf.org)<https://trac.ietf.org/trac/rtg/wiki/RtgDir>.

Summary
I have some minor concerns about this document that I think should be resolved
before the publication process begins.

Comments
Section 3.1
Channel type - please give a reference to the actual online registry URL.
The discussions of the following fields are very brief.  I can see what they
are used for, but it is not clear to me how these will be used.  Can you add
more in the way of specification, or are there any references that you can give?

  *   Node ID
  *   Level
  *   Session ID

Section 3.2
Which bits are intended by "28 MSBs of the d-ACH"?  I think this probably means
the 28 most significant bits of the first 32-bit word of the header (that is,
bits 4 to 31 inclusive).  I think there is a chance that people may interpret
this as "the first 28 bits of the packet in network order" (that is, bits 0 to
27 inclusive).  I suggest identifying the bits explicitly, e.g., 4 to 31.

Section 4.1
The following are not very clear to me, and I think need to be specified in
more detail.

   *  Active OAM test packet MUST be mapped to the same TSN Stream ID as
      the monitored DetNet flow.

How is this to be done? Is the mapping configured?

   *  Active OAM test packets MUST be treated in the TSN domain based on
      its S-label and CoS marking (TC field value).

What must be done in the TSN domain based on the settings of these fields?  Is
there an inverse, where these fields must be inferred from some fields in the
TSN domain?