Re: [Detnet] [EXTERNAL] Re: Routing directorate early review of draft-ietf-detnet-mpls-oam

[Jon Hardwick <[e-mail]>]

Hi Greg

Many thanks for this update. Your replies and the new text you proposed have addressed my concerns.

Best regards
Jon


From: Greg Mirsky <[e-mail]>
Sent: Thursday, December 15, 2022 3:51 PM
To: Jon Hardwick <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: [EXTERNAL] Re: Routing directorate early review of draft-ietf-detnet-mpls-oam

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi Jon,
thank you for the review and your thoughtful comments. Please find my responses below, tagged by GIM>>. Attached is the diff that highlights the proposed updates.

Regards,
Greg

On Mon, Dec 12, 2022 at 7:59 AM Jon Hardwick <[e-mail]<mailto:[e-mail]>> wrote:
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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-detnet-mpls-oam%2F09%2F&data=05%7C01%7Cjonhardwick%40microsoft.com%7Cb622ed8dbf2a42dc488e08dadeb43967%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638067164648537061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=hgqi4TSeuqsLPZuwRTIbP3Nrjc7NywUE0C3dz0pwKCk%3D&reserved=0>

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Frtg%2Fwiki%2FRtgDir&data=05%7C01%7Cjonhardwick%40microsoft.com%7Cb622ed8dbf2a42dc488e08dadeb43967%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638067164648537061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=LxZOAwTP%2BT3uwtGTLbjm86BaMIslqrkqBLyzTBUAiWY%3D&reserved=0>.

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.
GIM>> Added as an informational reference
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
GIM>>  We envision that the precise use of these fields will be specified in the future documents that defined OAM solutions for the DetNet sub-layer.

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.
GIM>> Thank you for the suggested text. Please review the proposed update:

OLD TEXT:
   PREOF relies on sequencing
   information in the DetNet service sub-layer; for a DetNet active OAM
   packet, PREOF MUST use the 28 MSBs of the d-ACH as the source of this
   sequencing information.

NEW TEXT:
   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.

Is the new text acceptable?

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?
GIM>> The authors discussed these questions. We believe that Section 4 RFC 9037 includes all the necessary information. Would adding the reference as follows addresses your concerns:
NEW TEXT:
   The following considerations apply when using the tunneling model of
   OAM interworking between DetNet MPLS and TSN domains based on general
   principles described in Section 4 [RFC9037]:

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

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