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]> 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]> 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]> 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]> 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]> wrote: > > > > Hi Tal, > > > > I’ll look shortly. > > > > Tim > > > > On 28/05/2025, 07:08, "Tal Mizrahi" <[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]> 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. > > > > Thanks, > > Tal. > > > > On Mon, Dec 30, 2024 at 3:01 PM Carlos Pignataro <[email protected]> wrote: > > > > > > Hi, Tim, > > > > > > Many thanks for this thorough review, which I find incredibly helpful! > > > > > > As a preface, this I-D began with a central concern and idea, gradually > > > evolving to include adjacent terms based on group discussions and > > > participants' requests. This organic-growth process seems not uncommon > > > for terms that were widely, unquestionably used, but suddenly come under > > > deeper examination and scrutiny. I find this email and OpsDir review a > > > very useful point to pause and re-organize some of the 'stacking blocks' > > > in the doc. > > > > > > Before getting to the point-by-point review, please allow me to share > > > some top-of-review points: > > > > > > First, let me start with the core concern, which is the confusion created > > > by the unqualified, diverse uses of the terms "in-band" and > > > "out-of-band". I believe you agree with this ambiguity, since you write: > > >> > > >> deprecating “in-band” and “out-of-band”, which can be genuinely > > >> ambiguous, > > > > > > > > > When we wrote that initial part, we received significant feedback in the > > > form of "well, what shall we use instead?" > > > The approach we took was to say "well, anything descriptive enough", and > > > we also tried to codify terms for the most commonly-used contexts. > > > > > > However, I realize that getting full alignment and agreement on all these > > > terms can be a bit of a tilting-at-windmills exercise. > > > > > > You make a very astute suggestion: > > >> > > >> Perhaps a simpler first step here is to publish a shorter draft > > >> deprecating “in-band” and “out-of-band”, which can be genuinely > > >> ambiguous, > > >> requiring clarity in new drafts without prescribing exactly how, as > > >> there is a > > >> lot of variety in use cases. Which is what is said at the start of 2.1. > > >> So > > >> long as the drafts are clear, is it a problem? > > > > > > > > > I believe this objective can be achieved without queuing up a subsequent > > > draft. For example, deprecating in/out-of band, requiring clarity without > > > prescribing, *and* sharing examples of potential uses. Now, the > > > requirement is for them to be clear and unambiguous. > > > > > > I will attempt to massage that approach into a revision++ > > > > > > And in the meantime, please find additional thoughts and context inline, > > > marked with "CMP:" > > > > > > > > > On Thu, Nov 21, 2024 at 9:11 AM Tim Chown via Datatracker > > > <[email protected]> wrote: > > >> > > >> Reviewer: Tim Chown > > >> Review result: Not Ready > > >> > > >> Hi, > > >> > > >> I have reviewed this document as part of the Operational directorate's > > >> ongoing > > >> effort to review all IETF documents being processed by the IESG. These > > >> comments > > >> were written with the intent of improving the operational aspects of the > > >> IETF > > >> drafts. Comments that are not addressed in last call may be included in > > >> AD > > >> reviews during the IESG review. Document editors and WG chairs should > > >> treat > > >> these comments just like any other last call comments. > > > > > > > > > CMP: Thank you for this review! > > > > > >> > > >> > > >> The draft is an attempt to harmonise use of OAM terminology, with a > > >> focus on > > >> common ambiguous terms such as in-band and out-of-band. As it stands, > > >> both of > > >> these terms would be deprecated (no future use) by the document, with > > >> more > > >> specific language bing proposed instead. Other terminology is proposed > > >> with > > >> the noble aim to make future documents clearer in their use of language > > >> around > > >> OAM. > > > > > > > > > CMP: For clarity, rather than an attempt at nobility, the impetus of all > > > the proposals is direct feedback and suggestion for participants, as they > > > were using OAM in various contexts and were hoping to make use of > > > normalization. For example, draft-ietf-opsawg-ipfix-on-path-telemetry > > > requested Section 5 of this document. > > > CMP: That said, the approach of what is required versus what is suggested > > > or exemplified is useful. > > > > > >> > > >> While noble, the document is a hard read. I found myself repeatedly > > >> looking > > >> back to check the earlier definitions of new terms. I wonder whether the > > >> document tries to do too much, and to prescribe too many terms. > > > > > > > > > CMP: Let's simplify. > > > > > >> > > >> > > >> I have to say at this time due to the lack of clarity and its complexity > > >> the > > >> document is Not Ready to move to the IESG, but I note the WGLC has > > >> completed > > >> before me writing this, so that position has already been established. > > > > > > > > > CMP: We are considering all these as WGLC comments, regardless of > > > relative timing of the review. > > > > > >> > > >> > > >> It’s not clear where the proposed new terminology has come from, or who > > >> was > > >> consulted. I check by searching on the data tracker (*). There are 27 > > >> current > > >> “oam” I-Ds, 9 of with are WG-adopted, and 55 RFCs, around 13 of which > > >> have been > > >> published in the last two years. Some review of these would be prudent, > > >> if this > > >> hasn’t happened already. > > > > > > > > > CMP: As mentioned, the proposed terminology, and to-be downgraded to > > > suggested, comes from participants using the terms or interested -- see > > > the Acknowledgements section. > > > > > >> > > >> > > >> I would also agree with soliciting feedback from groups such as detnet, > > >> ippm, > > >> maprg and others where definitions of and use of OAM methods are common. > > >> Do > > >> the proposed terms meet their needs? Do they seem intuitive? > > > > > > > > > CMP: This has been done repeatedly, in-mailing-list and > > > out-of-mailing-list. > > > CMP: You can see in the following search (*) some specific mentions of > > > the draft filename in those groups' mailing lists (ippm (6) detnet (5) > > > mpls (5) spring (5) gen-art (4) bier (1), etc.) -- considering there were > > > discussions without mentioning draft-name. > > > > > > CMP: (*) > > > https://mailarchive.ietf.org/arch/search/?q=%22draft-pignataro-opsawg-oam-whaaat-question-mark%22%20OR%20%22draft-ietf-opsawg-oam-characterization%22 > > > > > >> > > >> > > >> I have read a few OAM documents. I don’t necessarily feel confused by > > >> them, > > >> e.g, RFC 9634. > > > > > > > > > CMP: First, RFC 9634 does not include the term "band". > > > > > > CMP: Second, let's look at some comments on those lists. Take for example > > > the following (**) DetNet's post > > > > > > CMP: (**) > > > https://mailarchive.ietf.org/arch/msg/detnet/NqTndz1P2DaGTH45JCw5O9XQQqc/ > > > > > > CMP: It says the following, and this DetNet comment was not addressed, or > > > responded to! > > > CMP: The in-band and out-of-band OAM definitions are not clear to > > > me. > > > CMP: Perhaps I’m not alone, there is a suggestion to avoid these > > > terms: > > > CMP: > > > https://www.ietf.org/archive/id/draft-ietf-opsawg-oam-characterization-01.html#name-in-band-and-out-of-band-oam > > > CMP: What should we do with it in draft-ietf-raw-architecture? > > > > > > CMP: I am very concerned to see very similar yet different re-definitions > > > of "in-band OAM" in all different drafts -- all without an Implementation > > > Considerations section. For example, the definition in > > > draft-ietf-nvo3-geneve-oam, draft-ietf-bier-oam-requirements, rfc9551 and > > > several others are all similar but different. > > > > > > CMP: And then, from the thread precursor to this I-D, see > > > https://mailarchive.ietf.org/arch/msg/opsawg/NUBqiQG7QOJ2tVY1EZOvEfJ9bSY/ > > > > > > CMP: GIM>> The intention of introducing "in-band OAM" and > > > "out-of-band OAM" > > > CMP: terms is to stress that some performance measurements can be > > > performed > > > CMP: without traversing the same set of links and nodes as the > > > monitored flow. > > > CMP: Which is again different from 'same QoS treatment'. > > > > > > CMP: And more from the same thread > > > https://mailarchive.ietf.org/arch/msg/opsawg/hV_xfNRBKjgfGXFq2KNW5vVsYEY/ > > > CMP: Personally, I find the term "in-band OAM" for what is defined > > > in "RAW" confusing - as much as it was confusing for IOAM, which is why > > > IPPM chose a better definition when IOAM was defined. With no "band" > > > being defined for IP, it makes it hard to distinguish "in" and "out of" > > > band. In the RAW case, "in-band" seems to mean that an active OAM packet > > > follows the same path as the user traffic. > > > > > >> > > >> Perhaps a simpler first step here is to publish a shorter draft > > >> deprecating “in-band” and “out-of-band”, which can be genuinely > > >> ambiguous, > > >> requiring clarity in new drafts without prescribing exactly how, as > > >> there is a > > >> lot of variety in use cases. Which is what is said at the start of 2.1. > > >> So > > >> long as the drafts are clear, is it a problem? > > > > > > > > > CMP: This is a brilliant thought, let us explore how this would look -- > > > without going the multi-draft route, and instead the normativeness level. > > > > > >> > > >> > > >> Other comments: > > >> > > >> 2.1 > > >> Non-path-congruent or path-incongruent? > > >> In many cases, you just won’t know if they are congruent or not, due to > > >> certain > > >> load balancing methods. In-band can include OAM inserted on path. > > >> In-Packet OAM > > >> *can* be Non-path-congruent, can’t it? Consider OAM data in a v6 DO. On > > >> forwarding treatment, v6 EHs can cause different treatment when packets > > >> get > > >> punted to the slow path (another type of path!) I don’t understand the > > >> Combined > > >> OAM part. > > > > > > > > > CMP: Ack to all of these points. > > > > > >> > > >> > > >> 3. > > >> The phrase “dedicated OAM packets” is used, but we should call this > > >> “dedicated > > >> packet OAM” if following the document? What’s an atomic OAM packet? > > >> What’s > > >> explicit OAM? “Compound OAM” seems unnecessary, just use the > > >> combinations? > > >> > > > > > > CMP: Ack to all of these points. > > > > > >> > > >> 5. > > >> “En/de-capsulating” is a bad term as it may be insertion, or > > >> modification, not > > >> adding / removing a header. A transparent node should also not drop any > > >> OAM. > > >> > > > > > > CMP: Do you have a suggestion for a better term for “En/de-capsulating” > > > CMP: Ack to all of the other points. > > > > > > Thanks! > > > > > > Carlos. > > > > > >> > > >> Tim > > >> > > >> (*) > > >> https://datatracker.ietf.org/doc/search?name=OAM&sort=&rfcs=on&activedrafts=on&by=group&group= > > >> > > >> > > >> > > > _______________________________________________ > > > 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]
