Hi Tim, A kind reminder - we would highly appreciate it if you could take a look at the current draft and see whether it addresses your comments.
Regards, The authors. On Wed, Jun 11, 2025 at 11:41 AM Tal Mizrahi <[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]> 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]
