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]<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. > > Thanks, > Tal. > > On Mon, Dec 30, 2024 at 3:01 PM Carlos Pignataro > <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > > To unsubscribe send an email to > > [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
