Hi Greg, Please see inline, marked [[TM]].
On Mon, Nov 3, 2025 at 5:29 PM Greg Mirsky <[email protected]> wrote: > > Hi Tal, > Thank you for your prompt response to my notes. Please find my follow-up > comments below, tagged GIM2>>. > Additionally, I have not found an example of In-Data-Packet Fault Management > OAM, as the document only includes examples of In-Data-Packet Performance > Monitoring OAM. I think that since there's no evidence that the new term > "In-Data_Packet" applies to the Fault Management OAM, the scope of the new > term should be explicitly narrowed to the Performance Monitoring OAM methods. [[TM]] The current document refers to OAM terminology and does not explicitly make the distinction between different OAM functions, such as loss measurement or fault detection. Nevertheless, the document presents IOAM as an example of In-Data-Packet OAM. IOAM is not strictly a measurement protocol; it also provides other capabilities, such as path tracing and fault localization. > > Regards, > Greg > > On Sun, Nov 2, 2025 at 3:57 PM Tal Mizrahi <[email protected]> wrote: >> >> Hi Greg, >> >> Please see below, marked [TM]. >> >> On Wed, Oct 29, 2025 at 5:52 PM Greg Mirsky <[email protected]> wrote: >> > >> > Hi Tal, >> > thank you for your attention to my notes. I have a question about the >> > characterization of the Direct Loss Measurement as the Hybrid Type I >> > measurement method. Do you have a reference to a document that classifies >> > the Direct Loss Measurement as the Hybrid Type I measurement method? In my >> > understanding, it is a passive method of observing and counting packets >> > and/or octets. The mechanism used to collect metrics is orthogonal to OAM >> > measurement method characterization defined in RFC 7799. >> >> [TM] As the draft says, in MPLS direct loss measurement [RFC6374], >> "user packets are not modified by the protocol. Instead, OAM packets >> are used for carrying information about observed network >> characteristics, namely user packet counter values, allowing for >> packet loss computation." This behavior is similar to Ethernet loss >> measurement, as defined in ITU-T Y.1731, which was given as an example >> of Hybrid Type I in [RFC7799]. >> >> > Furthermore, It would be helpful to provide reference where "in-band" term >> > is equated to "In-Data-Packet: >> > In-Data-Packet OAM: >> > OAM-related information is carried in the packets that also carry >> > the data traffic. This is a specific case of Hybrid OAM. It was >> > sometimes referred to as "in-band". >> >> [TM] Paragraph 2 of the appendix describes this aspect. > > GIM2>> The IPPM WG concluded that the "In-band OAM" characterization of the > proposed protocol is not accurate and is misleading, as, for example, an > Active OAM protocol can be applied in-band to the monitored data flow. And > per the request of the IPPM WG the name of the protocol was changed to > In-situ OAM thus maintaining the IOAM acronym. On the other hand, several WGs > in the Routing Area have defined and use "in-band"/"out-of-band" terminology > without a problem or confusion. I believe that their experience should get > more consideration in this proposal. So far, has this proposal to obsolete > "in-band"/"out-of-band" terminology been discussed with DetNet and BIER WGs > that use terms in the OAM-related documents, including published RFCs? [[TM]] As the draft points out, the term "in-band" was indeed used in existing RFCs in a clear manner, but inconsistently across the RFC series. The following paragraph from the draft clarifies this point: For instance, the term "in-band" appears in both Virtual Circuit Connectivity Verification (VCCV) [RFC5085] and OAM for Deterministic Networking (DetNet) [RFC9551]. While the context in each of these documents is clear, the term carries different meanings in each case. These two examples, as well as other examples of uses of the term "in-band" in other documents are described in Appendix A. >> >> >> > Also, it is not clear which aspect of IOAM and the Alternate Marking >> > Method are characterized as the In-Data-Packet method. Is it limited to >> > the strict cases described in RFCs 9197, 9326, 9341, and 9342, or it also >> > includes scenarios described in >> > draft-ietf-ippm-on-path-active-measurements? And if the latter set of >> > scenarios is not included, the definition of In-Data-Packet is not >> > explicit about that. >> >> [TM] Following the reviews of Giuseppe and Thomas, version 13 includes >> an example that covers this case. Please see the last paragraph of >> Section 3.1 (specifically the last sentence). > > GIM2>> Thank you for the reference to the following text: > * Another example of "Hybrid Type I OAM" which is not "In-Data- > Packet OAM" is the case where a packet stream is (actively) > generated while an existing stream of interest is (passively) > observed. This example was introduced in [RFC7799] as a Hybrid > Type I method. Extending this example, if the packets of the > active stream include an IOAM trace option, the method is > characterized by the more general term, Hybrid Type I. > I think that the conclusion is incorrect because, for example, IOAM > Trace-Option modifies packet by adding telemetry information and, in > Incremental Trace mode, additionally adds to the packet length space to > telemetry information. Thus, the stream is not merely observed, but augmented > and modified, making this method, according to RFC 7799, an example of the > Active performance measurement. [[TM]] Indeed, IOAM can be used for active OAM, for example when using the IOAM 'Active' flag. However, in the example provided here "an existing stream of interest is (passively) observed", while an active stream with IOAM is used to measure it. Therefore, it is classified as Hybrid Type I. Cheers, Tal. >> >> >> > >> > Regards, >> > Greg >> > >> >> Cheers, >> Tal. >> >> > On Mon, Oct 20, 2025 at 3:49 AM Tal Mizrahi <[email protected]> >> > wrote: >> >> >> >> Hi Greg, >> >> >> >> Thanks again for reviewing the draft. >> >> >> >> We have added a clarification about the fact that In-Data-Packet OAM >> >> is a specific case of Hybrid Type I. >> >> Notably, "In-Data-Packet OAM" is not equivalent to "Hybrid Type I >> >> OAM", and the draft describes a couple of examples of "Hybrid Type I >> >> OAM" that is not "In-Data-Packet OAM". >> >> >> >> Thanks, >> >> The authors. >> >> >> >> On Fri, Sep 26, 2025 at 7:07 PM Greg Mirsky <[email protected]> wrote: >> >> > >> >> > 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? 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. >> >> > 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. 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. >> >> > Please consider my notes above as WG LC comments. >> >> > >> >> > Regards, >> >> > Greg >> >> > >> >> > On Thu, Sep 25, 2025 at 3:40 AM Giuseppe Fioccola >> >> > <[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]> >> >> >> Sent: Tuesday, September 16, 2025 9:47 AM >> >> >> To: [email protected]; >> >> >> [email protected]; >> >> >> [email protected]; [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] 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] >> >> >> To unsubscribe send an email to [email protected] >> >> >> >> >> >> _______________________________________________ >> >> >> OPSAWG mailing list -- [email protected] >> >> >> To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
