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.”
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.)
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.
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”.
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).
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.
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
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)
Appendix A:
Delete the first sentence, as the doc doesn’t discuss in-band examples directly
anymore.
---- snip ----
Best wishes,
Tim
On 03/09/2025, 09:34, "[email protected]" <[email protected]>
wrote:
You don't often get email from [email protected]. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
Hi Tim,
Can you please schedule a review of the latest draft version.
The datatracker still shows: OPSDIR IETF Last Call review (of -04) by Tim
Chown<https://datatracker.ietf.org/doc/review-ietf-opsawg-oam-characterization-04-opsdir-lc-chown-2024-11-21/>
Not ready
Thanks and Regards, Benoit
Hi Tim,
We believe that the current version (10) addresses your comments below.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/10
Please see below - marked [TM].
On Mon, Jul 7, 2025 at 5:49 PM Tim Chown
<[email protected]><mailto:[email protected]> wrote:
Hi Tal,
To be more specific, I find the hybrid vs in-packet terminology still too
inter-twined. And ‘hybrid’ just seems the wrong word, to me.
[TM] In the current version we have clarified the "Hybrid" definition
and the overlap with "In-Data-Packet". We have also added clearer
examples to clarify this. Notably, "hybrid" is a term that was defined
in [RFC7799], and the current draft does not update or change that
term. The current version is clearer about that.
And the additional text on “Using Multiple Criteria” could/should be morphed
into a set of examples, though of course you also have examples earlier in the
document. Maybe do one or the other.
[TM] The "Using Multiple Criteria" in the current version indeed
includes a set of examples, starting from the sentence "A few example
of OAM classification according to the three criteria are presented
below".
Tim
[TM] We hope this addresses the comments.
Thanks,
The authors.
On 11/06/2025, 09:42, "Tal Mizrahi"
<[email protected]><mailto:[email protected]> wrote:
Hi Tim,
Thanks again for the thorough review and comments.
We have posted an updated version that we believe addresses the
comments you recently sent.
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization/07/
Updates compared to version 06 include:
- "Terminology and Guidance" was moved into a separate section
(section 3), with a subsection for each criterion.
- The definition of the term "Hybrid OAM" was slightly reworded based
on the feedback.
- Slightly clarified the example illustrating the difference between
hybrid and in-packet OAM.
- A clarification about the term "path-congruent" was added.
Please let us know whether the current version has addressed your concerns.
Thanks,
The authors.
On Thu, Jun 5, 2025 at 12:06 PM Tim Chown
<[email protected]><mailto:[email protected]> wrote:
Hi Carlos,
Thanks. I think it’s those categories where in-band and out-of-band language
is used very loosely when it needn’t be used.
The proposed use of hybrid and in-packet isn’t great. I think ideally you’d
encourage use of descriptors that explicitly spell out what is meant with
respect to the path followed, treatment at a device, encapsulation, header
insertion, etc.
I think your (very good) goal is to remove/reduce poor / ambiguous use of the
in-band/out-of-band language, and that approach should help achieve that.
Tim
On 05/06/2025, 00:16, "Carlos Pignataro"
<[email protected]><mailto:[email protected]> wrote:
Tim,
Thank you again for taking the time to re-review this document. I really
appreciate both your time and the thoughtful details in your feedback.
We (Tal, Adrian, and I) will be replying in detail — in the meantime, thanks
for this assertion:
I like that the emphasis is now on saying “don’t just use in-band and
out-of-band” as that language is usually loose and can be ambiguous.
As well as for the specifics on the remaining concerns you have.
Best,
Carlos.
On Jun 4, 2025, at 12:14 PM, Tim Chown
<[email protected]><mailto:[email protected]> wrote:
Hi Carlos.
Apologies for the delay, too many life distractions.
The -06 draft is now better than the -04 I reviewed, in that it is shorter, and
less complex. But I still have a few concerns.
I like that the emphasis is now on saying “don’t just use in-band and
out-of-band” as that language is usually loose and can be ambiguous. I fully
support that aspect of this draft, and it is welcome. Sections 1 and the first
part of 2 are fine.
But then in 2.1 you introduce several terms in a bit of a haphazard way. I
think the document is a little Frankenstein in nature after being reworked a
few times. Not your fault, but I think it needs some fresh structure on top of
the ideas you have.
The differentiation for pathing, for packet treatment, and for active vs
passive is good, but you also muddle in hybrid and in-packet with active and
passive, and the difference between hybrid and in-packet is a bit ambiguous and
unclear. Hybrid sounds to me like hybrid active+passive, if I had to guess.
My suggestion would be to make section 2.1 a new section of its own, 3, and
within that have numbered subsections with headings something like:
3.1 OAM – general approach
3.2 OAM – traffic modification in flight
3.3 OAM – traffic path followed
3.4 OAM – traffic forwarding treatment
And then you can re-use much of your text by talking clearly in there about
OAM – general approach
Describe the use of dedicated (active) probe packets, OAM via pure traffic
observation (passive), and OAM by modifying the data stream.
Maybe ‘hybrid’ is then where active probe packets are modified in transit?
OAM – traffic modification in flight
Describe ways in which traffic can be modified, e.g.:
· Encapsulation/tunnelling
· Header-insertion (IPv6, in particular)
· Rewriting header fields
Some of these will affect packet size, some won’t. And may have
MTU/fragmentation impact, though that’s not in the scope of this draft.
Note here that this might be modification of active probes or of the data
stream traffic.
The modification may be localised to a domain, such that modifications are
undone or changed in some way on egress.
OAM – traffic path followed
Active probes may follow different paths to the data stream traffic
OAM – traffic forwarding treatment
Within a specific forwarding device, active probes may get different treatment,
e.g., QoS, to the data stream traffic.
Maybe define the term ‘data stream’ as meaning the non-OAM data passing through
the network which is the subject of OAM.
Section 2.2 then becomes section 4, and the subsequent sections are renumbered
accordingly.
A small nit in Section 2:
“that OAM can be” -> “that OAM traffic can be”
Oh, and if you want to ack me for comments, feel free.
Best wishes,
Tim
On 30/05/2025, 15:21, "Carlos Pignataro"
<[email protected]><mailto:[email protected]> wrote:
Thank you, Tim!
We look forward to your re-review.
Best,
Carlos.
On May 29, 2025, at 10:59 AM, Tim Chown
<[email protected]><mailto:[email protected]> wrote:
Hi Tal,
I’ll look shortly.
Tim
On 28/05/2025, 07:08, "Tal Mizrahi"
<[email protected]><mailto:[email protected]> wrote:
Hi Tim,
A kind reminder - please let us know if the current version addresses
your comments.
Thanks,
Tal.
On Thu, May 15, 2025 at 7:09 PM Tal Mizrahi
<[email protected]><mailto:[email protected]> wrote:
Hi Tim,
Thanks again for your review.
We have revised the draft, and we believe the current version
addresses the main comments you raised.
Link to the current draft:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-characterization
Diff compared to version 04 (which you previously reviewed):
https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-04&url2=draft-ietf-opsawg-oam-characterization-06&difftype=--html
Please let us know if the current version has addressed your comments
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
