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]> 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]>> 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]>> > *On Behalf Of *Greg Mirsky > > > *Sent:* Wednesday, 13 December 2023 04:13 > > > *To:* DetNet WG <[email protected] <mailto:[email protected]>>; mpls < > [email protected] <mailto:[email protected]>>; 6man WG <[email protected] <mailto: > [email protected]>>; IETF IPPM WG <[email protected] <mailto:[email protected]>>; > opsawg <[email protected] <mailto:[email protected]>>; Pascal Thubert < > [email protected] <mailto:[email protected]>>; Loa > Andersson <[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/>>) > > > * 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>>) > > > * 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>>) > > > > > > 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>>. 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]> > > > 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
