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]
