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]
