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 > draftdeprecating “in-band” and “out-of-band”, which can be genuinely > ambiguous,requiring clarity in new drafts without prescribing exactly how, > as there is alot of variety in use cases. Which is what is said at the > start of 2.1. Solong 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 <nore...@ietf.org> 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 <https://datatracker.ietf.org/doc/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 <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 -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
