Hi Greg, Thanks for adding your notes. Please see inline [GF] Regards,
Giuseppe From: Greg Mirsky <[email protected]> Sent: Friday, September 26, 2025 6:07 PM To: Giuseppe Fioccola <[email protected]> Cc: Benoît Claise <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [OPSAWG]Re: WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends 2025-09-30) Hi Giuseppe, Thank you for highlighting the question about the terminology defined in RFC 7799 and its application in this draft. In particular, what is the relationship between the definition of Hybrid Type I measurement methods and what is defined as In-Data-Packet OAM? [GF]: I think the issue is the current definition of Hybrid Type I in RFC 7799 as “Synthesis of Fundamental Methods”. Therefore, it looks like RFC 7799 considers Hybrid Type I also when Active and Passive methods are used together. In this regard, in section 3.8 of RFC 7799, you can find the following example related to the Hybrid Type I: “As an example, consider the case where the method generates traffic load stream(s), and observes an existing stream of interest according to the criteria for Passive Methods. Since loading streams are an aspect of Active Methods, the stream of interest is not "solely observed", and the measurements involve a single stream of interest whose treatment has been modified by the presence of the load. Therefore, this is a Hybrid Type I method.” Firstly, OAM includes the fault management and performance monitoring methods and protocols. AFAICS, this document only provides examples of performance monitoring methods characterized as In-Data-Packet. Thus, it would be correct to use In-Data-Packet Performance Monitoring (PM) OAM. [GF]: I fully agree on this point. Maybe it is better to change the name to avoid any misunderstanding. Secondly, I support the addition of a reference to draft-ietf-ippm-on-path-active-measurements. But I think that the resulting measurements method is characterized as active per definitions in RFC 7799 because the test packet that is the combination of an active method and some additional information, e.g., the shim that enables the Alternate-Marking method, is nothing but a specially constructed test packet, i.e., an instrument of an active measurement method. [GF]: Yes, I also agree on that. The combination of Active and Hybrid methods, as explained in draft-ietf-ippm-on-path-active-measurements, is an Active Method. But, I meant that there are other types of combinations which can result in Hybrid Methods, as the previous example from RFC 7799. And if my understanding is correct, In-Data-Packet is not a subset of Hybrid Type I methods but just a renaming of the class of measurement methods defined in RFC 7799. Since there is no apparent ambiguity in understanding RFC 7799, I don't see any benefit in renaming Hybrid Type I as In-Data-Packet and suggest removing it and all related text from the draft. [GF]: The point is that Hybrid Type I, as currently defined in RFC 7799, includes some cases, such as the combination of Active and Passive methods, which are not In-Data-Packet PM. For this reason, the definition of In-Data-Packet still makes sense for differentiation. Please consider my notes above as WG LC comments. Regards, Greg On Thu, Sep 25, 2025 at 3:40 AM Giuseppe Fioccola <[email protected]<mailto:[email protected]>> wrote: Hi All, I think this is a useful document. However, I have some comments: - When referring to Hybrid OAM, I suggest to specify if it is Type I or Type II, in order to be more aligned with RFC 7799 terminology. I noticed that various examples in the text are simply referred as Hybrid OAM. - I would mention the Active OAM variation described in draft-ietf-ippm-on-path-active-measurements, that is when Hybrid OAM methods are combined with Active OAM tools to perform active on-path measurements. According to the definitions in RFC7799, this is still Hybrid Type I. - Consequently, I propose to revise the definition of In-Data-Packet OAM and specify that it is a subset of Hybrid Type I, where the OAM information is carried in the user traffic stream. In this way, it is clear that, any application to a specially generated stream can be Hybrid Type I but it is not In-Data-Packet OAM. - Finally, I suggest to add another classification for the OAM methods, depending on whether the method can support on-path (hop-by-hop) or only edge-to-edge measurements. Regards, Giuseppe -----Original Message----- From: Benoît Claise via Datatracker <[email protected]<mailto:[email protected]>> Sent: Tuesday, September 16, 2025 9:47 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: [OPSAWG]WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends 2025-09-30) Subject: WG Last Call: draft-ietf-opsawg-oam-characterization-12 (Ends 2025-09-30) This message starts a 2-week WG Last Call for this document. Abstract: As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band" which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in future IETF work. This document updates [RFC6291] by adding to the guidelines for the use of the term "OAM". It does not modify any other part of [RFC6291]. File can be retrieved from: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/ Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected]<mailto:[email protected]> in copy. Objections should be motivated and suggestions to resolve them are highly appreciated. Authors, and WG participants in general, are reminded again of the Intellectual Property Rights (IPR) disclosure obligations described in BCP 79 [1]. Appropriate IPR disclosures required for full conformance with the provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. Sanctions available for application to violators of IETF IPR Policy can be found at [3]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ _______________________________________________ OPSAWG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ OPSAWG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
