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.
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".
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
<https://datatracker.ietf.org/doc/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.
Regards,
Greg
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 <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]
