Thank you Loa for your review, context, and comments! Please see inline.
On Sat, Jan 20, 2024 at 12:53 AM <l...@pi.nu> wrote: > OPSAWG participants, Carlos, Adrian and Greg. > > As one of the co-authors RFC 6291 I agree that it makes sense to update > RFC 6291 in this way. > > In part, this draft is very close to what Greg and I tried to say in a > mail that we sent to some wg's. We saw a DETNET/RAW document that used the > acronyms iOAM and oOAM, and we found that this was too easy to confuse > with e.g. the widely used IOAM. > > We tried to recommend that we should use easily distinguishable acronyms, > I find that Adrian and Carlos do a much better job on this. > > Some notes: > > RFC 6291 is a BCP, which is the target status of this draft. Are there any > problems updating a BCP? > > The target is BCP as well, and a BCP can point to 2 RFCs. > In the introduction, I find: > > Additionally, this document recommends avoiding the creation and use of > extended acronyms for the qualifiers of "OAM". For example, the first > "O" in "OOAM" could mean out-of-band, overlay, or something else. > > If I understand correctly this leaves us with IOAM as an "extended > abbreviation", right? I hope you are planning to change that > abbreviation.. I hope you are not planning to change that. > > The RFC Editor talks about for example "IOAM" as abbreviations if there > are no strong reasons we should follow suit, i.e. avoid acronyms. > This is a good point, and IOAM is the only "OAM acronym" included in https://www.rfc-editor.org/materials/abbrev.expansion.txt I think while keeping the reco, we can acknowledge this pre-existing use. I added some text to this effect, let's see if this works. > > Section 2 in the document discusses "in-band" and "out-of-band", there are > several examples and I agree with the recommendation: > > The guidance in this document is to avoid the terms "*-band" and > instead find finer-granularity descriptive terms. > > However, there a simple search among IETF drafts shows that several > documents have "in-band" in the file name and also use "out-of-band" in > the text. There might be a substantial review required to enforce the > recommendation. Should we ask that the directorates put an instruction for > the directorate reviewers to try to capture this? > Another useful comment -- we feel that laying out and 'enforcing' recommendations going forward is the most effective approach, and indeed there are active I-Ds using "in-band" in the filename. At this point, as this document is also an I-D and not approved, highlighting this issue and suggesting a discussion on the relevant I-Ds as part of OpsDir review would be indeed an approach. Thanks! Carlos. > > The rest of the document seems fine to me. > > /Loa > > > > > Hi Adrian, > > thank you for your kind consideration of my notes. Please find my > follow-up > > notes below tagged by GIM>>. > > Regards, > > Greg > > On Fri, Jan 12, 2024 at 11:25 AM Adrian Farrel <adr...@olddog.co.uk> > wrote: > >> Hi Greg, > >> Thanks for your thoughtful inspection of our draft. > >> Carlos and I wanted to be sure that all of the discussions of this > draft > >> were indexed on one list, and we wanted to avoid multiple copies going > to > >> people who are subscribed to multiple lists. So we asked that > follow-ups > >> went only to OPSAWG. I have moved IPPM, MPLS, SPRING, and DetNet to BCC > on > >> this email. > > GIM>> Thank you. > >> It was certainly not our intent to disparage any work that was being > done > >> in any other working group, and I understand the effort that has gone > into > >> the DetNet OAM Framework to ensure that the terminology is clear and > unencumbered in the DetNet context. > >> Our concern was, however, that different contexts are applying > different > >> definitions of the terms “in-band” and “out-of-band”. Those > definitions are > >> (often) clear and precise, but they are not consistent across contexts. > Thus, a water-tight definition in the DetNet context is not universally > applicable, and a reader coming to DetNet from another context may > bring > >> with them their own understanding of the terms. > > GIM>> Although the wording in the DetNet OAM Framework is indeed > specific > > for DetNet environment, for example, the reference to DetNet service > sub-layer and PREOF, the authors and the WG strived to make the > > definitions > > generic. I believe that we achieved a reasonable level of generality > because the interpretation of "in-band/out-of-band" terminology in RAW > OAM > > was based on our work in DetNet. I believe that it could be a reasonable > way of building common understanding through a discussion of existing > terms > > instead of fork-lifting and trying to invent something different that > has > > not been used by any WG. > >> Our intent, therefore, is to select a finer-grained set of terms that > have > >> universal applicability and that can be selected within a context > without > >> loss of generality. > > GIM>> I agree with that wholeheartedly. > >> This is a tricky little subject and I know that Carlos and I expected > it > >> to generate more than a little discussion. If we end up with > >> “everything is > >> OK and nothing needs to change” that will be OK with us. If we discover > >> that some work is using terms too generally, while others already have > perfect definitions, that will lead to something similar to this > document > >> to bring the good into the light. > >> Further comments in line… > >> *From:* Greg Mirsky <gregimir...@gmail.com> > >> *Sent:* 12 January 2024 00:09 > >> *To:* Carlos Pignataro <cpign...@gmail.com>; Adrian Farrel < > >> adr...@olddog.co.uk> > >> *Cc:* Ops Area WG <opsawg@ietf.org>; IETF IPPM WG <i...@ietf.org>; > mpls < > >> m...@ietf.org>; spring <spr...@ietf.org>; DetNet WG <det...@ietf.org> > *Subject:* Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM" > >> - Hi Carlos and Adrian, > >> thank you for starting this work. I believe that having a common > dictionary helps in having more productive discussions. I took the > liberty > >> of inviting all the WGs which you invited to review the document and > added > >> DetNet WG. Please feel free to trim the distribution list. > >> I've read the document and have several general questions to start our > discussion: > >> - It seems that the motivation of this document is the assumption > >> that > >> "in-band OAM" and "out-of-band OAM" are not representative or cannot > >> be > >> understood or correctly attributed, interpreted by the IETF > >> community. Is > >> that correct? > >> I think the wording here would be “cannot be reliably understood > consistently”. That is, without looking at a context-specific > definition > >> (such as that which you supply in the DetNet OAM Framework), the use of > the > >> terms may be misinterpreted. > >> This is an assertion, but one (we think) is founded on observation of > recent conversations on mailing lists, and also of witnessing many > years > >> of > >> people talking passed each other. > >> - As we discuss and try to establish (change) the IETF dictionary, > it > >> is important to analyze the terminology used by other SDOs. I > believe > >> that > >> it is beneficial to maintain consistent terminology which will > >> minimize > >> misunderstandings among experts with different experiences of > working > >> at > >> different centers of technological expertise. > >> This is a good point. It is certainly true that if other SDOs working > with > >> packet networks have established terminology that we can agree with and > which is not, itself, subject to context-specific definitions, then > there > >> is no reason to choose other terms. Do you have any suggested sources? > > IEEE 802.1Q 2014 uses in-band/out-of-band > >> It is notable that the ITU-T has long worked with non-packet transport > networks and has used the terms in-band and out-of-band. But even there > we > >> see some fragmentation with terms such as “in-fibre, but > >> out-of-band” > >> becoming necessary. > >> - I that DetNet OAM Framework > >> <https://datatracker.ietf.org/doc/draft-ietf-detnet-oam-framework/> > provides sufficiently clear interpretation of terms that can be > >> generalized > >> for non-DetNet networks: > >> * In-band OAM is an active OAM that is in-band within the monitored > >> DetNet OAM domain when it traverses the same set of links and > interfaces receiving the same QoS and Packet Replication, > Elimination, and Ordering Functions (PREOF) treatment as the > monitored DetNet flow. > >> This, of course, does not distinguish between “in-packet” (such as > IOAM), > >> and having its own packet (such as ping). > >> GIM>> The definition is for active OAM. Hybrid OAM, which, as I > understand > > it, is referred to in the document as "in-packet", is inherently > "in-band" > > with the monitored data flow. Looking back, perhaps we could have noted > that in DetNet OAM Framework. Furthermore, I note that what is referred > to > > as "in-packet" is identified as "on-path telemetry". What do you think > about that term? > >> * Out-of-band OAM is an active OAM whose path through the DetNet > >> domain is not topologically identical to the path of the > monitored > >> DetNet flow, or its test packets receive different QoS and/or > PREOF treatment, or both. > >> As can be seen, the interpretation of "in-band" accepted by the DetNet > WG > >> includes not only topological equivalence between the monitored data > flow > >> and path traversed by active OAM but also QoS equivalence between them. > I > >> believe that is essential in differentiating in-band OAM from > >> out-of-band > >> OAM. > >> Right. But is there terminology to talk about a packet that does follow > the topology, but does not receive the same QoS treatment? > >> GIM>> Is there a case of useful information that an operator obtains in > > that scenario, i.e., when a test packet is topologically with the > monitored > > flow but is marked by a different CoS and, as a result, receives a > different QoS treatment? In other words, can topology and CoS marking be > different between the monitored data flow and specially constructed test > packets that are aimed to monitor that data flow? Personally, I am not > aware of any useful information (except for direct loss measurement) > that > > can be obtained using that setup and I conclude that active OAM must > repeat > > topology of the data paths and use the same CoS marking. > >> It is perhaps a little strong to say this, but what you have done is > define two classes of OAM (both good things and meaningful in the > DetNet > >> context) and then assigned existing names to those classes. What we are > suggesting is that you have some finer granularity categorisation of > OAM > >> available, and that for the purposes of your DetNet work, you are > collecting those granularities into two different sets. > >> GIM>> As I noted above, I believe that topology and CoS are both > > requirements for an active OAM method and separating them "throws baby > out > > of water". > >> - I find the use of "path congruence" in inherently meshed > >> packet-switched networks confusing if not misleading. (Note that RFC > 6669 <https://www.rfc-editor.org/rfc/rfc6669> explains congruence by > using in-band term.) Is there evidence of the term being used > besides > >> a > >> single case in RFC 6669? > >> Well, I would say that 6669 is an example of how “in-band” has been > used, > >> and I’d point out that it does not match your DetNet OAM Framework > definition (as there is no mention of identical treatment). Note that > the > >> text from RFC 6669 is replicated into RFC 7276 (same authors, same > subject). > >> You don’t say what you find misleading or confusing. Is it that, in a > meshed packet network, each individual packet might be forwarded > differently so that congruence cannot be guaranteed? That could be > true, > >> but we hope for greater stability than that, I think. > >> If “path congruence” was a new term (with only one previous use) that > >> might make it a really neat term to use (because it would lack all > previous > >> meanings). However, it is not. It has been used (to mean the same set > of > >> links, ports, and nodes) in our more path-oriented work such as RFC > 5828, > >> RFC 6373, right up to RFC 9059. > >> Perhaps “congruent” is overloaded given that we are not talking about > >> “topological congruence”, a term that is also quite widely used > (e.g., RFC > >> 2796, RFC 4258, RFC 5059, RFC 6549, RFC 8795) > > GIM>> My concern with using "congruence" is most likely caused by how > the > > term is used in geometry.And saying that "congruent paths" are paths > that > > cross the same set of nodes and links seems like too narrow compared to > the > > definition in geometry. And that raises my next question: Why not simply > define the relationship between the data path and the path traversed by > a > > test packet without introducing, what seems, an unnecessary term? > >> - Similarly, "in-packet" vs. "dedicated packet". I believe that RFC > 7799 <https://www.rfc-editor.org/rfc/rfc7799> has that addressed by > using "active", "passive", and "hybrid" terminology. Although these > >> terms > >> applied to measurement methods, i.e., performance monitoring > >> component of > >> OAM, but, in my opinion, can be extended to fault management OAM. > >> Well, we agree that RFC 7799 can be used to generate the terms "active > OAM", "passive OAM", and "hybrid OAM". Although we think, for the > benefit > >> of clarity, the reader should not be left to examine RFC 7799 and > project > >> meaning from performance monitoring to OAM in general: they should be > presented with a clear set of definitions (per our section 3). > >> It is further our belief that the definitions of active and passive OAM > do > >> not match with “in-packet” and “dedicated-packet”. Indeed, > possibly, the > >> closest is that “active OAM” is “dedicated-packet”, and > “hybrid OAM” is > >> “in-packet” leaving “passive OAM” to be just observation. > > GIM>> I consider OAM to define a toolbox that contains tools based on > active, passive, and hybrid methods in support of OAM functions > > (connectivity check, continuity verification, automatic protection > switchover, and performance monitoring among others). Thus, I prefer to > use > > the terminology of RFC 7799 that classifies measurement methods, not > OAMs. > >> - It seems like the definition of Compound/Combined misses the point > that RFC 7799 already defines a hybrid measurement method (not OAM > >> but > >> measurement methods) as a method in which elements of active and > passive measurement methods are used. Hence, hybrid is already a > combination of active and passive measurement methodologies and the > introduction of compound or combined terms is unnecessary, a > >> duplication of > >> the existing and accepted terminology (at least in IPPM WG). And > "Active-Hybrid-Passive OAM" is the result of that omission because, > according to the definition in RFC 7799, Active-Passive is Hybrid. > >> Thus, > >> Active-Hybrid-Passive is nothing else but Hybrid-Hybrid. Does that > >> make > >> sense? > >> I should certainly have preferred it had RFC 7799 not used the term > “hybrid” to actually refer to a third category that is not a hybrid > of the > >> first two categories. For the definitions of active OAM and passive > OAM, > >> I > >> don’t think the combination matches the definition of hybrid OAM. So, > perhaps, let’s stop referring to RFC 7799’s definitions of > not-actually-OAM-packets, and nail down our own definitions. That will > tell > >> us whether we need two, three, four, or more terms. > > GIM>> I would note that the terminology introduced in RFC 7799 has been > accepted and broadly used not only in the documents produced by IPPM WG > but > > also many groups in the Routing area. > >> - I cannot agree that RFC 7799 "adds to the confusion" by pointing > >> that > >> Passive performance metrics are assessed independently of the > packets > >> or traffic flows, and solely through observation. Some refer to > such > >> assessments as "out of band". > >> Indeed, passive measurement methods are not required to use packets > that > >> are in-band with the monitored data flow. Usually, the management plane > protocol is used to collect, to perform the observation function. In > some > >> cases, in-band active OAM packets may be used, e.g., direct loss > measurement in ETH-OAM. > >> Yes, but where is this “in-band with the monitored data flow” > defined for > >> a packet network? And you say “are not required to” rather than > “MUST NOT”. > >> That means that the passive methods might send their packets with the > monitored data flow or might not. > >> We live in a world where there is not necessarily a distinction between > the MCN and DCN. > >> GIM>> Although there might be no topological distinction between MCN > and > > DCN, it is more likely that they use different CoS markings. If that is > the > > case, from the point of the definitions in DetNet OAM Framework, MCN is > out-of-band relative to DCN. > >> I find that throw-away sentence in RFC 7799 both helpful and unhelpful. > It > >> is helpful to know that some people call this “out of band”. It is > unhelpful to refer to an assessment method as “out of band” as > there > >> is no > >> message or packet involved to be in or out of band. > >> FWIW, I believe that RFC 7799 and DetNet OAM Requirements already > provide > >> a clear terminology for OAM in general and its elements, i.e., Fault > Management and Performance Monitoring. > >> OK. I suspect that we are going to have to come up with a set of OAM > techniques and ask you to categorise them according to your terminology > to > >> see whether all bases are covered. > >> But I am also going to have to review your text from the DetNet OAM > Framework because it contains phrases that are not clear (to me)… > >> In-band OAM is an active OAM that is in-band within the monitored > DetNet OAM domain when it traverses the same set of links and > interfaces receiving the same QoS and Packet Replication, > Elimination, and Ordering Functions (PREOF) treatment as the > monitored DetNet flow. > >> There is something broken here. Maybe too many words. Perhaps you mean… > >> In-band OAM is an active OAM that traverses the same set of links > >> and > >> interfaces receiving the same QoS and Packet Replication, > Elimination, and Ordering Functions (PREOF) treatment as the > monitored DetNet flow within the monitored DetNet OAM domain > >> …and… > >> Out-of-band OAM is an active OAM whose path through the DetNet > domain is not topologically identical to the path of the > monitored > >> DetNet flow, or its test packets receive different QoS and/or > PREOF treatment, or both. > > GIM>> Many thanks for your thoughtful suggestion. I'll make sure that we > apply this change in the course of AUTH48. > >> As noted before, this leaves a few gaps. > >> - Active OAM that follows the same path, but does not receive the > >> same > >> QoS treatment > >> GIM>> That would be out-of-band > >> - > >> - There is no distinction between instrumentation of data packets > and > >> dedicated instrumentation packets > >> GIM>> That is the distinction between hybrid and active OAM methods. > >> - > >> Cheers, > >> Adrian > >> On Fri, Jan 5, 2024 at 12:39 PM Carlos Pignataro <cpign...@gmail.com> > wrote: > >> Hi, Ops Area WG, > >> Every now and again, there are discussions on how to best characterize > or > >> qualify a particular kind of "OAM", as well as misunderstandings due to > having different definitions and contexts for a given term. A case in > point > >> is "in-band" or "out-of-band" OAM, as recently surfaced at > >> > https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/. > To alleviate this issue, Adrian and I wrote a short I-D to provide > forward-looking guidance on "foobar OAM". > >> We would appreciate feedback and input on this position, which aims at > updating the guidelines for the "OAM" acronym, with unambiguous > guidelines > >> for their modifiers. > >> Guidelines for Charactering "OAM": > >> > https://datatracker.ietf.org/doc/draft-pignataro-opsawg-oam-whaaat-question-mark/ > Look forward to input and comments to make this more clear and > >> effective! > >> Adrian & Carlos. > >> _______________________________________________ > >> OPSAWG mailing list > >> OPSAWG@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > mpls mailing list > > m...@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
