Dear all,
Great series of comments by Tim.
I don't want to reply for Tim here, but I believe that draft v11 is now
clearly.
Three minor observations on my side
- An example of "Hybrid OAM" that is also "In-Data-Packet OAM", is
an IOAM [RFC9197] trace option that is incorporated into data
packets. According to [RFC9197], IOAM '...records OAM information
within the packet while the packet traverses a particular network
domain. The term "in situ" refers to the fact that the OAM data
is added to the data packets rather than being sent within packets
specifically dedicated to OAM.'
I would extend the first IOAM acronym, to stress the "in situ" qualifier, otherwise the
reference to "in situ" comes out of nowhere, unless you know RFC9197.
Since this document is about terminology, this seems important.
Should this draft also mention something such as : the "In situ" qualifier
should not be reused, if possible, and is not advised by this document? Or this is going
to far?
Note: I saw this note, in the appendix. Is this sufficient?
In-Data-Packet OAM was in some cases referred to as "in-band".
Initially, "In situ OAM" [RFC9197] was also referred to as "In-band
OAM", but was renamed due to the overloaded meaning of "In-band OAM".
Further, [RFC9232] also intertwines the terms "in-band" with "in
situ", though [I-D.song-opsawg-ifit-framework] settled on using "in
Situ". Other similar uses, including [P4-INT-2.1] and
[I-D.kumar-ippm-ifa], still use variations of "in-band", "in band",
or "inband".
-
Appendix A. Examples of the Use of the Term In-Band
This appendix provides a few examples of the use of the term "in-
band". These are intended to highlight the varying interpretations
of the term across different contexts.
Do you want to say: These are intended to highlight the varying interpretations
of the term across different contexts, which led to the guidelines in this
document.
- nits
measurment
Regards, Benoit (Doc. Shepherd)
Hi Tim,
Thanks for the comments, and thanks for some further offline discussion.
We believe the current version of the draft addresses these comments:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/11/
Please let us know if there are any remaining comments about this version.
Please see my responses below, marked [TM].
On Thu, Sep 4, 2025 at 6:46 PM Tim Chown<[email protected]> wrote:
Hi,
Here is my review of -10. I would still like to see some tweaks (sorry) not
least due to the divergence from 7799 which I think is counter intuitive as is.
----- snip ----
I have re-reviewed the latest version of the OAM Characterisation draft,
draft-ietf-opsawg-oam-characterization-10.
The draft seeks to simplify and clarify descriptors used for different types of
OAM-related traffic, not least due to the archaic use of in-band and
out-of-band terminology, which this document effectively deprecates.
I consider it a good improvement on the earlier version I reviewed for ops-dir,
but still have non-trivial Nits with the document that I would like to see
addressed before it is advanced further. I appreciate that the document has
been discussed for some time, but I feel these relatively small changes to make
would improve the text and future use of the guidance.
General comments:
The document is well written.
The definition of Hybrid still doesn’t sit well with me, I think because of the
divergence from what is written in RFC7799, which states Hybrid is - quite
intuitively - a blend of Active and Passive, but this document changes that.
Hence my comments further below.
The document recommends avoiding the use of in-band and out-of-band. Perhaps
it should go further and deprecate their use in future documents? (This is not
a strong view, and I’m fine if this isn’t done, but it might be worth doing for
emphasis.)
Specific comments:
Abstract:
Add at the end of para 1:
“This document recommends they no longer be used when referring to OAM.”
[TM] The abstract was updated with a slightly reworded sentence.
so the abstract makes this feature of the document very clear. The abstract
says nothing on this as is.
Section 3.1:
The “Hybrid” term as used here is NOT consistent with RFC 7799. Hence, I would
rewrite the definition to be in line with it:
Hybrid OAM:
Use a combination of active and passive methods which may
include augmentation or modification of a single data stream of interest, or
the coordinated use of multiple streams, e.g., an active OAM stream alongside
an unmodified data stream. (This is in line with Section 3.8 of RFC7799.)
[TM] The Hybrid OAM definition was updated along the lines you suggested.
I would then rename In-Data-Packet OAM to Modified-Data-Packet OAM (it avoids
the use of “in”, as per “in-band” and does exactly what it says on the tin), as
a sub type of Hybrid.
[TM] We have had many discussions about this term, and In-Data-Packet
OAM seemed like the most reasonable compromise, so it would be
preferable not to change it.
Modified-Data-Packet OAM:
OAM-related information is carried in the packets that also
carry the data traffic, e.g., where OAM-related bits may be added or rewritten
along the path. This is a specific case of Hybrid OAM. It was sometimes
referred to as “in-band”.
[TM] This definition was slightly reworded based on your comment.
However, please note that "OAM-related bits may be added or rewritten
along the path" is not necessarily the general case. IOAM is an
example in which this is true, and it is presented in this section
(the third example). So it seems like the current (updated) text makes
sense.
Then for the examples in this section:
Examples 1-4 are fine (with In- rewritten to Modified-)
Example 5 clarify the active packets here are not ‘probe’ packets but rather
carry data about observed (passive) network characteristics (loss).
[TM] A clarification was added to the example.
Example 6 is exactly why the Hybrid OAM terms needs to be as I’ve rewritten it
above, as per 7799.
Section 3.2:
I think this needs to say for Path-Congruent that:
“The OAM information is guaranteed to follow…”
and for Non-Path-Congruent OAM:
“The OAM information does not necessarily follow…”
because it might not. It’s about certainty, and the possibility/likelihood of
incongruent traffic.
[TM] The definition of "Non-Path-Congruent OAM" was slightly reworded
along these lines. It does not seem necessary to update
"Path-Congruent". Similarly, "Different-Forwarding-Treatment OAM" was
also updated.
If you look at the IP Ping example in 3.4, you already say “is not guaranteed”
there. Same principle.
I’d delete the last sentence of the penultimate paragraph and “A further
concept” as that’s covered below in 3.3
[TM] Agreed.
Section 3.3:
Same thing here
Equal:
“The OAM packets are guaranteed to receive the same…”
and for Different:
“The OAM packets may receive different...”
(adding guaranteed and may)
[TM] Right, as noted above, "Different-Forwarding-Treatment OAM"
definition was reworded.
Appendix A:
Delete the first sentence, as the doc doesn’t discuss in-band examples directly
anymore.
[TM] This sentence was reworded.
---- snip ----
Best wishes,
Tim
Thanks,
The authors.
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
