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? 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. 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? 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 <[email protected]> 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 <[email protected]> >> *Sent:* 12 January 2024 00:09 >> *To:* Carlos Pignataro <[email protected]>; Adrian Farrel < >> [email protected]> >> *Cc:* Ops Area WG <[email protected]>; IETF IPPM WG <[email protected]>; mpls < >> [email protected]>; spring <[email protected]>; DetNet WG <[email protected]> *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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > mpls mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
