Dear Greg, Please see inline as *CMP2*.
On Mon, Jan 22, 2024 at 2:56 PM Greg Mirsky <gregimir...@gmail.com> wrote: > Dear Carlos, > > thank you for sharing your thoughts and responding to my notes. I have > added follow-up notes and questions below under the GIM2>> tag. But before > I go to the specific topics of our discussion, it is essential > to bring forward the question of not how the 'OAM' abbreviation is expanded > but how we interpret it, whether in the expanded or abbreviated form. > *CMP2: Correct, that's what RFC6291 does.* *CMP2: And as one of the authors of RFC6291 supported this proposal, I feel we are on a useful path.* *CMP2: That said, I'll try to provide some follow-ups, and will let others on the list chime-in, as the discussion seems to be getting circularly convoluted.* RFC 7276 <https://datatracker.ietf.org/doc/rfc7276/> in the Abstract gives > the following explanation of the scope of OAM: > > Operations, Administration, and Maintenance (OAM) is a general term > > that refers to a toolset for fault detection and isolation and for > > performance measurement. > > Hence, based on that definition, we can expect that an OAM toolset > includes tools that use different methods classified in RFC 7799 > *CMP2: I do not see the "hence". That RFC defines OAM toolsets, not methods. Yes, those toolsets can use methods that use frameworks that use principles. Those methods can be written in Italian as well, without a "hence".* > , i.e., active, passive, and hybrid. Of course, some operators might build > their OAM toolsets only using mechanisms of the same type, i.e., only > active or hybrid. But such choices don't make OAM active or passive. Thus, > I suggest that the document clarify that and refer to "an active OAM > method" rather than "active OAM" (and so on for other types). > *CMP2: The main goal is that we have overloaded how we categorize and describe OAM, and this proposal tackles the "[qualifier] OAM".* *CMP2: Please note that RFC7799 gives two definitions to Hybrid, and thus some disambiguation is already needed.* *CMP2: To me, your suggestion could be useful but seems an Update to RFC7799 what you are asking.* > > Regards, > > Greg > > On Tue, Jan 16, 2024 at 2:41 PM Carlos Pignataro <cpign...@gmail.com> > wrote: > >> Dear Greg, >> >> Thank you for your interest in our draft, and the associated extensive >> comments! All welcome! >> >> *CMP: Please find some additional follow-ups.* >> >> On Sat, Jan 13, 2024 at 7:52 PM Greg Mirsky <gregimir...@gmail.com> >> wrote: >> >>> 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. >>> >> >> CMP: The set of challenges continues to be that >> *(1) these are still context-dependent re-definitions of >> "in-band". draft-ietf-detnet-oam-framework says "*In-band OAM is [...] >> within the monitored DetNet OAM domain [... long set of conditions ...]*". >> Clearly, these are only within a DetNet context. These are not portable nor >> generic or generalizable.* >> > GIM2>> The only context that is essential for OAM is the monitored data > flow. The data flow has two characteristics: > > - the rendered path, i.e., nodes and links traversed by a data packet > - QoS experienced by the data packet > > *CMP2: Do you have a reference for this statement? Are those the only characteristics of a data flow? Not security and fw rules, for example? Not whether ip fragments are allowed, for example? Not packet sizes? Filtering on byte rate or on packet rate?* > Any OAM method, whether for fault management or performance monitoring, to > monitor a particular data flow must have the same characteristics, i.e., > the same rendered path and QoS. These characteristics cannot be separated > to have a useful presentation of the conditions experienced by the packets > of the monitored data flow. Consider a scenario when only the rendered path > is the same as for the monitored flow; QoS is not. Can the observed flow > state or the collected performance metrics be attributed to the flow? > *CMP2: Trying to stay on-topic, are there different descriptors for on-rendered-path only, qos only, AND of those two, OR of those two? * *CMP2: Counter-argument in point, PREOF.* *CMP2: Does the rendered path include incoming interfaces into a note for example? (Reference requested)* > *(2) the terms "in-band"/"out-of-band" are already tainted with a >> multitude of potential meanings, and have interpretations attached to >> them. * >> > GIM2>> I am open to discussing alternative terminology that can reflect > the union between the rendered path and QoS (or lack thereof) in one or two > simple words. At the same time, a group of people who agree on the > interpretation can explain it to others. That is easier than inventing some > new term foreign to others in the industry. > *CMP2: Greg, we are open to using existing artifacts if they work. If they don't, as we have showed, we have to invent something, which initially will be foreign as everything else. I imagine when someone wanted to invent OAM or Passive, they might have received similar push-back :-)* *CMP2: As Adrian mentioned before, depends on the context of the 'group of people'. If WG-1 uses "banana IP" to define something, and a different WG2 uses "banana IP" to define something completely different, both WGs would tell the other one 'we agree, have an interpretation, and we can explain it'* > *(3) IOAM saw the same confusion with the I for "in-band", and instead of >> redefining it with a narrower scope, it changed the term to a finer >> resolution of the defintion and uniqueness (there is no band)* >> > GIM2>> As I recall the discussion with the proponents of interpreting 'I' > in IOAM as "in-band", that was not because the term "in-band" is complex, > but because there was the perception that active OAM cannot be in-band. > *CMP2: I was sitting in the room when we were talking about this, and Erik Nordmark suggested 'in situ'. I remember visually the moment. It was, clearly in my recollection, because in-band was mis-descriptive and confusing.* *CMP2: As Frank Brockners mentioned, "there is no band in IP'* *CMP2: Do not try to redefine "in-band" -- that would be impossible. Only try to realize the truth: "there is no band".* > I am glad that that was clarified and that a less confusing expansion of > 'I' was found that all parties could live with. > >> CMP: Thus far, this does not show to me that the terms are >> confusion-safe. >> > > >> >> >>> >>>> >>>> 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. >>>> >>> >> CMP: Further: >> (1) Cannot be understood unambiguously. >> (2) Cannot be interpreted by someone who first hears the terms (i.e., >> "there is no band") >> > CMP: I added some of this text to the draft. >> > GIM2>> As I understand it, IETF documents are created based on the > expectation that a reader has a certain level of understanding of the > technology. To help the reader, we provide references to prior documents. > Suppose the model of the IETF document changes with the requirement to be > understandable to a novice. Would that result in each document reproducing > the basic knowledge about the subject repeatedly? That would be undesirable > result. > *CMP2: This is a strawman. No one mentioned level of expertise, novice, or deep understander. * *CMP2: The issue is non-ambiguity, and confusion. When someone hears "the WG-XYZ in-band" versus "DetNet inband" versus "WG3 inband", being experts, they cannot get meaning from it.* >> >>>> - 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 >>> >> >> CMP: Unless somehow I missed it, this (paid, 1832 page) document does not >> use the terms "in-band OAM" or "out-of-band OAM". It mentions in-band >> loopback, and in-band management. As such, I do not think they are >> relevant, nor solve the IETF confusion. >> > GIM2>> Correct. There's no "in-band OAM" but can be an "in-band OAM > method" (please see my note in the email opening). > >> >> *CMP2: That seems like an update to RFC7799. See above.* > >> >>> 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. >>>> >>>> >>>> >>>> >> CMP: I strongly disagree with this definition gening easy to generalize. >> This is not only 'within a DetNet OAM domain', but also: >> (1) "same set of links and interfaces" --> how are 'links' and >> 'interfaces' defined here, include 'tunnels' or not, etc... looking at rfc >> 8343... >> > GIM2>> Isn't a tunnel represent a logical link? > *CMP2: Could you please reply the question before asking a different one? How are links and interfaces defined?* > (2) "...receiving the same QoS and PREOF treatment..." --> that also seems >> specific and not generalizable. What if you want to define OAM that follows >> the same topology but not same QoS treatment? Or an "or" of those... >> > GIM2>> As noted above, PREOFs are DetNet service sub-layer functions. For > a more general definition of in-band OAM, we look only at the equivalence > of rendered paths and QoS between a packet with OAM and the monitored data > flow. For an OAM method based on on-path telemetry, that is native, but > that is essential for an active OAM method. Perhaps the DetNet AD and WG > Chairs can add to the discussion. > *CMP2: I thought you said only rendered-path and QoS mattered!* > *(3) how does this generalize to in-situ?* >> > GIM2>> IOAM is an example of on-path telemetry. > *CMP2: What is Telemetry? Does it help in the context of clarifying OAM, or muddies lexicon even more?* > Other examples standardized or being discussed at IETF, to the best of my > memory, are the Alternate Marking method, High-precision Congestion Control > (HPCC++), Cogestion Signaling (CSIG), and Path Tracing (for IPv6). > >> >> >>> 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? >>> >> >> CMP: Thanks for agreeing that the DetNet OAM framework has a gap in >> regards to in-situ. >> > GIM2>> Could you point to me where I left you with such an impression? > *CMP2: Where you wrote: "*Looking back, perhaps we could have noted that in DetNet OAM Framework." > Because IOAM applicability until now is only defined for IPv6 data plane, > the discussion of using IOAM in DetNet is a moot point as there are no > expectations to use IOAM in IPv4, and the discussion of using IOM in MPLS > continues as a part of MPLS Network Actions. As I see it, the gap is with > IOAM applications outside of IPv6. > >> CMP: I would not use "telemetry", but "on-path OAM" can work -- so long >> as it is not "in-band" due to the confusion experienced. >> > GIM2>> I can live with "on-path OAM method" as reference to some > enhancement of a packet to collect operational state and telemetry > information. > >> CMP: If there is a path defined, then "on-path" or "in-path" can work >> perfectly. If there were a "band" we could use "in-band", but... >> > GIM2>> Nodes, as networks overall, treat packets with different CoS > markings differently. Performance metrics measured for two data flows over > the same path but with different CoS markings will likely also differ. > *CMP2: So is it QoS treatment, CoS marking, or both, to define your OAM?* > >> >>> >>>> >>>> * 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. >>> >> >> CMP: Greg, I feel you have not answered the question -- which is the same >> one I posed above. What would you call OAM following topology but not >> receiving (necessarily) the same QoS treatment? I believe that "in-band >> type 27" is not descriptive, and finer granularity. >> > GIM2>> It seems like you've missed my answer. > *CMP2: Sorry about that, not intentionally.* > From the perspective of the flow marked with CoS A, the OAM packet marked > by CoS B is out-band even if both cross the same set of nodes and links. > But the same OAM packet is in-band with the data flow marked with CoS B and > renders the same path. > *CMP2: Do you have a reference for this intended definition and use?* > >>>> >>>> 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". >>> >> >> CMP: I understood something different in Adrian's point. You have created >> a new definition, within Detnet, one that amalgamates a number of criteria >> together, but then assigned them an existing term, "in-band OAM"... >> > GIM2>> Why wouldn't we invite the DetNet WG to the discussion? Perhaps > the AD and WG Chairs can add to the discussion. > *CMP2: Feel free to invite, for sure! I imagine will help. My only comment is to try to keep the discussion in the Opsarea wg list.* > >>>> - 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? >>> >> >> CMP: A more fitting term would most certainly be welcomed! The objective >> is that it does not redefine "in-band" for example (RFC 6669 and DetNet >> already have different definitions for the same term!) >> > *CMP2: By the way, you seem to have skipped over a few comments...* > >> >>> >>>> - 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. >>> >> >> CMP: Greg, this does not seem to drive us towards a path of more clarity. >> Let me explain. >> *(1) First, RFC 7799 defines Hybrid Type I and Hybrid Type II (methods >> and metrics). This in itself is already overloading when you are using only >> "hybrid".* >> *(2) Second, let's look at this text from RFC7799:* >> 3.7. *Passive Metric* >> Passive Metrics apply to observations of packet traffic (traffic >> flows in [RFC7011]). >> 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".* >> >> CMP: So based on that trajectory, *passive can be out-of-band*, but your >> DetNet document says "*Out-of-band OAM is an active OAM*". >> > GIM2>> You cut the quote too soon: > * 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. > The detNet OAM Framework document gives an example of out-of-band OAM > method. > *CMP2: Which, again, is out-of-band within the DetNet context. * > Obviously, other examples, including the ones referenced in RFC 7799, > exist. > >> >> CMP: Frankly, the more we look at it, the clearer it becomes that *-band >> can lead to confusions... >> >> >>>> - 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. >>> >> >> CMP: Even more reason to readjust trajectory and prevent further >> confusion. >> > GIM2>> It is strange that this discussion being conducted outside of the > IPPM WG that is the recognized center of expertise on performance > measurements at IETF. Perhaps the AD and WG Chairs of the IPPM WG can add > to the discussion. > *CMP2: Absolutely! * *CMP2: There's no 'leaving WGs outside', but, as Adrian explained twice, concentrating discussion on this list. You had already copied all these lists, and we had sent individual emails to those lists already, so they were ALL invited to have the discussion on this mailing list -- twice at least.* IETF IPPM WG <i...@ietf.org>; mpls <m...@ietf.org>; spring <spr...@ietf.org>; DetNet WG <det...@ietf.org> > >>>> - 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. >>> >> >> CMP: Do you feel that is a clear unambiguous use of terms? >> > GIM2>> Could you please clarify, which terms? > *CMP2: When you wrote "*MCN is out-of-band relative to DCN"*, which "BAND" are you please referring to? * *CMP2: See, the issue is that within the context of a WG someone defines a meaning for "in-band" and "out-of-band", in another WG someone else a different meaning, and at the end of the day: there is no band. * *CMP2: Do not try to redefine "in-band" -- that would be impossible. Only try to realize the truth: "there is no band".* *CMP2: Carlos.* >>>> >>>> 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. >>>> >>>> >>>> >>> >> CMP: Thanks for sharing your beliefs. Our observations show otherwise. >> >> >>> 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. >>> >> >> CMP: I would qualify this as retrofitting existing terms into >> narrowscoped contexts, instead of building unambiguous terms for the future. >> >> Thanks, >> >> Carlos.. >> >> >>> >>>> - >>>> >>>> >>>> >>>> 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 >>>> >>>>
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
