Re: [Detnet] Éric Vyncke's No Objection on draft-ietf-detnet-mpls-oam-14: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Éric,
thank you for your kind consideration of our work and thoughtful comments
and questions. Please find my notes below tagged by GIM>>.

Regards,
Greg

On Tue, Jan 2, 2024 at 5:11 AM Éric Vyncke via Datatracker <[e-mail]>
wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-detnet-mpls-oam-14: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # É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).
>
GIM>> Thank you for your understanding.

>
> 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,
>
GIM>> It certainly does.

>
> 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.
>
GIM>> The group discussed that and agreed that 16 OAM sessions per given
Level originated from the DetNet node identified by the Node ID is
acceptable. Would the following update makes it clearer:
OLD TEXT:
       Session ID is a 4-bit field.  The Session field is used to
      distinguish OAM sessions originated from the same node (a given
      Maintenance End Point may have multiple simultaneously active OAM
      sessions).
NEW TEXT:
      Session ID is a 4-bit field.  The Session field distinguishes OAM
      sessions originating from the same node (a given Maintenance End
      Point may have multiple simultaneously active OAM sessions) at the
      given Level.


> Is the Node ID a well-known DetNet concept ?
>
GIM>> The concept of Node ID exists in TSN OAM (inherited from ETH OAM).

>
> ## 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.
>
GIM>> Excellent question, thank you! For DetNet OAM monitoring the DetNet
forwarding sub-layer, a transit DetNode will treat an OAM packet in the
same manner as a DetNet data packet. On the DetNet service sub-layer, that
might be controlled to test the Packet Replication, Elimination, and
Ordering Functions.

>
> ## Section 4.1
>
> Should there be an informative reference to IEEE TSN?
>
GIM>> Will ask the TSN experts for their recommendation.

>
> ## 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).
>
GIM>> Thank you for your suggestion. I extended the section with an
explanation of interworking between DetNet MPLS and DetNet IP when BFD is
used. Also, noted that performance measurements within domains can be used
to calculate metrics that are composable allowing evaluation of the
end-to-end DetNet service performance. Below is the updated text:
NEW TEXT:
4.2.  OAM of DetNet MPLS Interworking with OAM of DetNet IP

   Interworking between active OAM segments in DetNet MPLS and DetNet IP
   domains can also be realized using either the peering or the
   tunneling model, as discussed in Section 4.1.  Using the same
   protocol, e.g., BFD, over both segments, simplifies the mapping of
   errors in the peering model.  For example, respective BFD sessions in
   DetNet MPLS and DetNet IP domains can be in a concatenated relationship
   as described in Section 6.8.17 of [RFC5880].  To provide performance
   monitoring over a DetNet IP domain, STAMP [RFC8762] and its
   extensions [RFC8972] can be used to measure packet loss and packet
   delay metrics.  Such performance metrics can be used to calculate
   composable metrics [RFC6049] within DetNet MPLS and DetNet IP domains
   to reflect the end-to-end DetNet service performance.

>
> ## 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?
>
GIM>> Although in this document we don't discuss the applicability of
either LSP ping, or BFD, we don't forsee any technical issues with using
these OAM mechanisms on the DetNet forwarding sub-layer. Following that
consideration, we included references to Security Considerations section of
the respective RFCs.

>
> # NITS (non-blocking / cosmetic)
>
> ## DetNet or Detnet
>
> The document uses both `DetNet` and `Detnet`, suggest to use only one.
>
GIM>> Thank you pointing that out to me. DetNet is the canonical form and I
did s/Detnet/DetNet/.