> -----Original Message----- > From: ippm <[email protected]> On Behalf Of Florian Kauer > Sent: Wednesday, 13 December 2023 12:07 > To: Frank Brockners (fbrockne) <[email protected]>; Greg > Mirsky <[email protected]>; DetNet WG <[email protected]>; mpls > <[email protected]>; 6man WG <[email protected]>; IETF IPPM WG <[email protected]>; > opsawg <[email protected]>; Pascal Thubert <[email protected]>; Loa > Andersson <[email protected]> > Subject: Re: [ippm] [Detnet] IOAM, iOAM, and oOAM abbreviations > > Hi, > so does in-band OAM (RAW architecture) actually mean exactly the same as In- > situ OAM (RFC 9197)?
From https://datatracker.ietf.org/doc/html/draft-ietf-raw-architecture-13#name-in-band-oam, "in-band OAM" An active OAM packet is considered in-band for the monitored Track when it traverses the same set of links and interfaces and if the OAM packet receives the same QoS and PAREO treatment as the packets of the data flows that are injected in the Track. From https://datatracker.ietf.org/doc/rfc9197/. IOAM (In Situ OAM) records OAM information within the packet while the packet traverses a particular network domain. The term "in situ" refers to the fact that the OAM data is added to the data packets rather than being sent within packets specifically dedicated to OAM. Or in other words, IOAM and "in-band OAM" are not necessarily the same. Personally, I find the term "in-band OAM" for what is defined in "RAW" confusing - as much as it was confusing for IOAM, which is why IPPM chose a better definition when IOAM was defined. With no "band" being defined for IP, it makes it hard to distinguish "in" and "out of" band. In the RAW case, "in-band" seems to mean that an active OAM packet follows the same path as the user traffic. Frank > 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? ;-) ) > > 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... > > 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]> *On Behalf Of *Greg Mirsky > > *Sent:* Wednesday, 13 December 2023 04:13 > > *To:* DetNet WG <[email protected]>; mpls <[email protected]>; 6man WG > <[email protected]>; IETF IPPM WG <[email protected]>; opsawg <[email protected]>; > Pascal Thubert <[email protected]>; Loa Andersson <[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/>) > > * iOAM - in-band OAM (RAW architecture > <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>) > > > > 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>. 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] > > https://www.ietf.org/mailman/listinfo/detnet > > _______________________________________________ > ippm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
