[Last-Call] Re: [Detnet] Re: draft-ietf-raw-architecture-25 ietf last call Opsdir review

[Pascal Thubert <pascal.thubert@xxxxxxxxx>]

Hello Greg

Le mar. 8 juil. 2025 à 23:42, Greg Mirsky <gregimirsky@xxxxxxxxx> a écrit :

Hi Pascal,

thank you for your quick and detailed response. Please find my follow-up notes below tagged GIM2>>.

Regards,

Greg

On Tue, Jul 8, 2025 at 5:02 AM Pascal Thubert <pascal.thubert@xxxxxxxxx> wrote:

Hello Greg:

I'd like to reach a consensus here, and, in particular, ensure that Giuseppe is OK since this is his review.

Let's see below

Le lun. 7 juil. 2025 à 22:44, Greg Mirsky <gregimirsky@xxxxxxxxx> a écrit :

Hi, Pascal et al.,

 as a contributor to this work, I have a proposal for the OAM terminology. Top-posting from the discussion below and adding my note tagged GIM>>:

The main issue, from an OPSDIR point of view, is section 2.6 on OAM variations.

Considering the ongoing discussion on draft-ietf-opsawg-oam-characterization,

it might be better to avoid general OAM definitions here. I suggest to consider

RFC 7799 and RFC 9551 for reference and include only the terms useful in the

context of this document. I would simply refer to the definitions of RFC 9551

for In-band OAM and Out-of-band OAM. In addition, I would omit new terms, e.g.

Limited OAM or Upstream OAM, which are not used in the rest of the document

and, if needed, could be taken into account for

draft-ietf-opsawg-oam-characterization.

Done. 

The OAM section is gone. Replaced by 

"

   RAW reuses terminology defined for Operations, Administration, and

   Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM

   for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods

   (with Hybrid Types In-Between" [RFC7799].  The reader is encouraged

   to consider the Guidelines for Characterizing "OAM"

   [I-D.ietf-opsawg-oam-characterization] to fully understand the

   semantics of the terms Active, Passive, Hybrid, and In-Packet OAM,

   and usage guideline of the terms In-Band and Out-of-Band OAM that are

   defined in [DetNet-OAM] but .

"

at the very beginning of the terminology section. I retained "residence time" that I moved in another section, and a discussion on low layers information that also moved..

GIM>> I find that in-packet OAM is used in only in Figure 11. In fact, according to RFC 7799, protocols that combine passive and active methods of performance measurement are classified as Hybrid (e.g., IOAM and Alternate Marking). Thus, I propose changing s/in-packet OAM/Hybrid OAM/.

In Figure 11: "PLR Conceptual Interfaces", the idea is really "in-packet", since that column is about packet processing. Could we use "in-situ" ?

Hybrid really applies to the right column. I added it there.

GIM2>> Thank you for the clarification. "In-situ", as I see it, is associated with the particular method of collecting operational state and performing measurements - RFC 9197 In-situ OAM. As other methods support the same functionality as IOAM, do you think the caption of Figure 11 can be edited to "An example of ..."? Then changing "in-packet" to "In-situ" will work.

done

 

 

As a result, there is no apparent need to reference I-D.ietf-opsawg-oam-characterization as RFC 7799 is the earlier authoritative source defining active, passive, and hybrid OAM measurement methods. Hence, the proposed text that replaces the OAM section can be updted as follows:

NEW TEXT:

   RAW reuses terminology defined for Operations, Administration, and

   Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM

   for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods

   (with Hybrid Types In-Between)" [RFC7799].

The terms are defined authoritatively in RFC 9551, that much remains true - note that the reference to RFC 9551 is normative. The issue (as I understand it)  is that referencing RFC 9551 imports all the terms therein and (I understood from the comments that) the terms  "In-Band" and "Out-of-Band" are confusing and should be avoided in future specs. 

GIM2>> Although some are confused by how "in-band" and "out-of-band" terms are used in the characterization of OAM methods, several WGs in the Routing Area, i.e., DetNet, NVO3, and BIER, accepted their interpretation in published documents. Furthermore, the statement that [I-D.ietf-opsawg-oam-characterization] is needed "to fully understand the semantics of the terms Active, Passive, Hybrid" seems inaccurate. RFC 7799 provides clear definitions and gives helpful examples for each class of OAM methods defined in RFC 7799. I believe that [I-D.ietf-opsawg-oam-characterization] adds no value regarding understanding these terms.

OPS Area insists on having that ref. I can see that your points make sense too. Let me try the below:

"

   RAW reuses terminology defined for Operations, Administration, and
   Maintenance (OAM) protocols in Section 1.1 of the "Framework of OAM
   for DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods
   (with Hybrid Types In-Between)" [RFC7799].  "Guidelines for
   Characterizing OAM" [I-D.ietf-opsawg-oam-characterization] provides
   additional semantics of the terms Active, Passive, Hybrid, and In-
   Packet OAM that are consistent with [RFC7799].  It also warns about
   potential inconsistencies in the way the terms "in-band" and "out-of-
   band" are used across the IETF; the DetNet reference for those terms
   is [DetNet-OAM]. 

 "

The informational reference to draft-ietf-opsawg-oam-characterization was  thus added to discourage employing the terms "In-Band" and "Out-of-Band" OAM.  

Giuseppe and Benoit recommend this addition. I complied, adding the reference as "informational" for "usage guidelines". Now you're suggesting removing it. I need a consensus to move on. 

2 questions (to all):

- Do we have a consensus that draft-ietf-opsawg-oam-characterization is correct about "In-Band" and "Out-of-Band", in other words, should we effectively discourage using those terms?

- If so, is there an issue with using the informational reference to do that?

GIM2>> AFAICS, the DetNet WG accepted these terms and they are used in DetNet OAM documents without any controversy. I cannot find these terms being used in draft-ietf-raw-architecture. If that is the case, why do we need to discuss them in this document?

Because it is an architecture and docs that reference it will directly inherit the listed terminology, as opposed to indirectly via the references.

I agree they could refer to RFC 9551 and be done too, since in the case of OAM that particular doc exists. This is not the case for many other terms therein though. 

I guess the main thing is not to introduce inconsistencies between this and its references. I hope the above text achieves that.

All the best

Pascal

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx