Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane
draft-ietf-detnet-mpls-oam-15

I support Martin's DISCUSS.

Please sort Section 2.1.

Nothing to add to my esteemed colleagues' comments :)

Thank you to Hilarie Orman for the SECDIR review.

Thank you for addressing my DISCUSS and COMMENT feedback.

# Éric Vyncke, INT AD, comments for draft-ietf-detnet-mpls-oam-14

Thank you for the work put into this document. As my knowledge of MPLS is rather low, please bear with me. I also found this document not so easy to read without the context (but this is OK).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to János Farkas for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 3.1

I find weird to only have 4 bits for session IDs and a 5-bit flags field that has no flag defined yet. I.e., I fear that more than 16 OAM sessions may be useful.

Is the Node ID a well-known DetNet concept ?

## Section 3.2

Does this section mean that for transit DetNet node, the processing of an OAM packet is identical (to the bit level) as a normal data plane DetNet packet? This may be worth mentioning. 

## Section 4.1

Should there be an informative reference to IEEE TSN? 

## Section 4.2

Suggestion: give more explanations on the interworking with DetNet IP (in the same level of interworking with TSN in section 4.1).

## Section 6

This document specifies neither LSP ping nor BFD (they are cited as examples), so, is there a reason to have the last sentence in the security section about them?

# NITS (non-blocking / cosmetic)

## DetNet or Detnet

The document uses both `DetNet` and `Detnet`, suggest to use only one.

# GEN AD review of draft-ietf-detnet-mpls-oam-14

CC @larseggert

Thanks to Russ Housley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/3-RqWPjdoCCPFAZ0xgZEqAOdnws).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2.1, paragraph 13
```
-    layer is an MPLS network that provides Lqabel Switched Path (LSP)
-                                            -
```

### Outdated references

Document references `draft-ietf-detnet-oam-framework-09`, but `-10` is the
latest available revision.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Thanks for addressing my DISCUSS and COMMENT

I support Martin's Discuss.

Given I've written it, my comment is below, but have subsequently seen that this is the same issue that Martin raised in his Discuss ...

Minor level comments:

(1) p 6, sec 3.2.  DetNet Packet Replication, Elimination, and Ordering Functions
      Interaction with Active OAM

   At the DetNet service sub-layer, special functions (notably PREOF)
   MAY be applied to the particular DetNet flow to potentially reduce
   packet loss, improve the probability of on-time packet delivery, and
   ensure in-order packet delivery.  PREOF relies on sequencing
   information in the DetNet service sub-layer.  For a DetNet active OAM
   packet, PREOF MUST use the bit string from bit 4 through bit 31
   inclusive of the first 32-bit word of the d-ACH, i.e., the
   concatenation of Version, Sequence Number, and Channel Type fields,
   as the source of this sequencing information.  In that, DetNet OAM
   uses a 28-bit field for sequencing and is conforming to Section 4.1
   of [RFC8964].

I'm slightly confused by this because the "Sequence Number" field (which is incremented by 1 for each packet) is in the middle of the 28 bit field used for sequencing in Section 4.1 or RFC 8964.  I.e., every time the "Sequence Number" field is incremented in the d-ACH header then the logical 28-bit field for sequencing is being incremented by 2^16.  I'm not sure if this isn't an issue, or I'm just confusing things, but thought that it would be helpful to flag it anyway ...