Hi Pascal,
thank you for the discussion and your thoughtful consideration of my notes. I believe that we're converging and the one remaining issue I have is more a question to Giuseppe then to you. Please find my follow-up notes below tagged GIM3>>.
Kind regards,
Greg
On Fri, Jul 11, 2025 at 12:29 AM Pascal Thubert <pascal.thubert@xxxxxxxxx> wrote:
Hello GregLe 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,GregOn 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 belowLe 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 considerRFC 7799 and RFC 9551 for reference and include only the terms useful in thecontext of this document. I would simply refer to the definitions of RFC 9551for 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 documentand, if needed, could be taken into account fordraft-ietf-opsawg-oam-characterization.Done.The OAM section is gone. Replaced by"RAW reuses terminology defined for Operations, Administration, andMaintenance (OAM) protocols in Section 1.1 of the "Framework of OAMfor DetNet" [DetNet-OAM] and "Active and Passive Metrics and Methods(with Hybrid Types In-Between" [RFC7799]. The reader is encouragedto consider the Guidelines for Characterizing "OAM"[I-D.ietf-opsawg-oam-characterization] to fully understand thesemantics of the terms Active, Passive, Hybrid, and In-Packet OAM,and usage guideline of the terms In-Band and Out-of-Band OAM that aredefined 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
GIM3>> Thank you!
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, andMaintenance (OAM) protocols in Section 1.1 of the "Framework of OAMfor 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]."
GIM3>> I might sound like a broken record, but I cannot find any technical reason for referencing [I-D.ietf-opsawg-oam-characterization] in this draft. As we've agreed above, "in-packet OAM" is replaced with "In-situ OAM" as an example of using Hybrid Type I measurement methods (per RFC 7799 classification). AFAICS, [I-D.ietf-opsawg-oam-characterization] doesn't change the definition of Active, Passive, and Hybrid OAM methods. In my opinion, the characterization of OAM methods established in RFC 7799 is well-understood and broadly referenced (16 RFCs), as well as in specifications published by other SDOs (e.g., BBF's TR-390 series). So, there's no apparent need to "provide additional semantics of the terms Active, Passive, Hybrid", in my opinion. To summarize, reference to [I-D.ietf-opsawg-oam-characterization] is unnecessary in this document and following the "the document is ready when there's no text left that can be removed without negatively affecting the value of the document", I propose remove the reference and shorten text to:
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 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 bestPascal
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
