Hi Greg, no problem! So if I understand RFC 8972 section 4.5. correctly in combination with the question of in-band and out-of-band, I would now expect there are still "in-profile packets" (another word with "in-" at the beginning...) that are "in-band" in the RAW sense that actually generate the measurements (but that are out of scope of the standardization) and the results of that are collected "out-of-band" via the "direct loss measurement functionality", right?
In my understanding, the main sentence that motivates why we even care about the distinction of "in-band" and "out-of-band" in the DetNet context is "If an in-band method of transporting telemetry is used, the amount of generated information needs to be carefully analyzed, and additional resources must be reserved." (from draft-ietf-detnet-oam-framework-09). I would just like to add that this COULD be read as "out-of-band OAM allows you to care less about resource provisioning for your OAM traffic", but you would still need to consider the "in-profile packets" (or even just a few additional bytes in the packet headers for generating the metrics) that might influence the original data flow - especially if we talk about something like IEEE 802.15.4 networks. Or is it actually the case that this "direct loss measurement functionality" lets you get the packet loss counters completely for free (in the sense of in-band resources)? Greetings, Florian On 13.12.23 21:52, Greg Mirsky wrote: > Hi Florian, > I probably confused the matter more than necessary by mapping out-of-band OAM > to be a passive measurement method. Let me correct myself. We know active OAM > protocols, e.g., CFM and STAMP, that support the direct loss measurement > functionality. Because the test frame/packet that is used to collect the > counters is specifically constructed, that would be an example of active OAM. > However, because the frame/packet is not used to perform the measurement, it > can be out-of-band relative to the monitored flow. Sorry for the confusion > I've caused. > > Regards, > Greg > > On Wed, Dec 13, 2023 at 12:41 PM Florian Kauer <[email protected] > <mailto:[email protected]>> wrote: > > Hi Greg, > thanks a lot for the explanation, find my comments under FK>> > > On 13.12.23 21:14, Greg Mirsky wrote: > > Hi Florian, > > thank you for your questions. I added my notes below under the GIM>> > tag. > > > > Regards, > > Greg > > > > On Wed, Dec 13, 2023 at 3:06 AM Florian Kauer > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > wrote: > > > > Hi, > > so does in-band OAM (RAW architecture) actually mean exactly the > same as In-situ OAM (RFC 9197)? > > If yes, both should be named and abbreviated exactly the same way > and since RFC 9197 is already published, it should probably be In-situ OAM > (IOAM). (But the question then is what is out-of-band OAM? Out-situ OAM? ;-) ) > > > > GIM>> The intention of introducing "in-band OAM" and "out-of-band OAM" > terms is to stress that some performance measurements can be performed > without traversing the same set of links and nodes as the monitored flow. For > example, direct loss measurement, which is collecting counters of in-profile > frames/packets, can be out-of-band. These measurement methods are classified > as passive per RFC 7799. Examples of in-band OAM, in our view, can be found > among active and hybrid (per RFC 7799) measurement methods. > > Fk>> I am a little confused: After reading this explanation I thought > "out-of-band OAM == passive OAM" and "in-band OAM == active and hybrid OAM". > But draft-ietf-raw-architecture-16 explicitly writes "Out-of-band OAM is an > active OAM". What do I get wrong here? > > > > > If no, PLEASE don't use the same abbreviation for slightly > different things, even in slightly different contexts. I acknowledge the > preference of those working on a very specific topic to keep their daily used > terminology as concise as possible, but as someone who tries to get into all > those topics to understand the bigger picture or to actually implement > something, specific abbreviations are always a hurdle, especially when they > have different meanings in slightly different contexts. > > > > So I really like inb-OAM and oob-OAM, because you can really "see" > the origin in it without repeatedly asking yourself if "i" stands for > in-situ, in-band, internet, industrial, intelligent... > > > > GIM>> Thank you. > > > > > > If you need a whole new section in an RFC just to explain the > different uses of I in an abbreviation, you will likely spend more key > strokes on that section, than on the additional "nb-"s ;-) > > > > Just my two cents. > > > > Greetings, > > Florian > > > > > > On 13.12.23 11:54, Frank Brockners (fbrockne) wrote: > > > > > > > > > When IPPM started working on IOAM, there was a long discussion on > naming – and the conclusion was that “in-band” as not appropriate for OAM > information being piggybacked on top of user traffic. This is why the IPPM WG > concluded to use “In-situ OAM” – or “IOAM” for short, which is what is used > in RFC9197 and all related documents. > > > > > > Frank > > > > > > > > > > > > *From:*ippm <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> *On Behalf Of > *Greg Mirsky > > > *Sent:* Wednesday, 13 December 2023 04:13 > > > *To:* DetNet WG <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; mpls <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>; 6man > WG <[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>>; IETF IPPM WG <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; opsawg <[email protected] > <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>; > Pascal Thubert <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>>; Loa > Andersson <[email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > *Subject:* [ippm] IOAM, iOAM, and oOAM abbreviations > > > > > > > > > > > > Dear All, > > > > > > Loa and I have discussed these abbreviations to help us find a > solution that avoids the confusion we found when we came across them. > Firstly, what they stand for: > > > > > > * IOAM - In-situ OAM (RFC 9197 > <https://datatracker.ietf.org/doc/rfc9197/ > <https://datatracker.ietf.org/doc/rfc9197/> > <https://datatracker.ietf.org/doc/rfc9197/ > <https://datatracker.ietf.org/doc/rfc9197/>>>) > > > * iOAM - in-band OAM (RAW architecture > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13 > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13> > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13 > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>>>) > > > * oOAM - out-of-band OAM (RAW architecture > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13 > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13> > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13 > <https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13>>>) > > > > > > We discussed the issue with Pascal and came to slightly different > abbreviations for the last two: > > > > > > * inb-OAM > > > * oob-OAM > > > > > > We also discord these abbreviations with the RFC Editor. > Resulting from that, RFC Editor agreed to add IOAM to the RFC Editor > Abbreviation List <https://www.rfc-editor.org/materials/abbrev.expansion.txt > <https://www.rfc-editor.org/materials/abbrev.expansion.txt> > <https://www.rfc-editor.org/materials/abbrev.expansion.txt > <https://www.rfc-editor.org/materials/abbrev.expansion.txt>>>. The other two > abbreviations cannot be added at this time. If that is needed, we can ask the > RFC Editor to add them once the respective RFC is published. > > > > > > We are seeking your feedback on the following: > > > > > > * Do you see the benefit of introducing two new abbreviations > for in-band OAM and out-of-band OAM? > > > * Which set of abbreviations (iOAM/oOAM vs. inb-OAM/oob-OAM) do > you prefer for being used in IETF? > > > * Or would you propose another set of abbreviations? > > > > > > Regards, > > > > > > Loa and Greg > > > > > > > > > > > > > > > _______________________________________________ > > > detnet mailing list > > > [email protected] <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>> > > > https://www.ietf.org/mailman/listinfo/detnet > <https://www.ietf.org/mailman/listinfo/detnet> > <https://www.ietf.org/mailman/listinfo/detnet > <https://www.ietf.org/mailman/listinfo/detnet>> > > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
