Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

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 i

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

h
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?

> *(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.

> *(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. 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 
>>> *Sent:* 12 January 2024 00:09
>>> *To:* Carlos Pignataro ; Adrian Farrel <
>>> adr...@olddog.co.uk>
>>> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls
>>> ; spring ; DetNet WG 
>>> *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.

>
>
>>>- 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 benefic

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

Many thanks, Med, for the review and useful suggestions!

I seem to prefer path-coupled to path-congruent as well.

I also like the packet-embedded or user-packet-embedded alternatives, as
they do seem more clear than in-packet.

WG - Any other thoughts on this?

Adrian, what do you think? (including as a native speaker)

Thanks a lot!

Carlos.

On Wed, Jan 17, 2024 at 12:32 PM  wrote:

> Hi Carlos, Adrian, all,
>
>
>
> Thank you for editing this document. This is really useful.
>
>
>
> Alternate terms to consider for the path-congruent terms are
> path-coupled/path-decoupled OAM (inspired from RFC4080).
>
>
>
> When editing RFC 9451, I wish I had terms for:
>
>- “OAM packet that exclusively includes OAM data”
>- “OAM packet that includes user data”
>
>
>
> I don’t think “in-packet OAM” conveys unambiguously the intent. I would
> suggest explicit terms such as: “User Data Embedded OAM” or “OAM-embedded
> User Data”.
>
>
>
> Thank you.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Carlos Pignataro
> *Envoyé :* vendredi 5 janvier 2024 21:39
> *À :* Ops Area WG ; Adrian Farrel 
> *Objet :* [OPSAWG] New I-D -> Guidelines for Charactering "OAM"
>
>
>
> 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.
>
>
>
>
>
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[mohamed . boucadair]

Hi Carlos, Adrian, all,

Thank you for editing this document. This is really useful.

Alternate terms to consider for the path-congruent terms are 
path-coupled/path-decoupled OAM (inspired from RFC4080).

When editing RFC 9451, I wish I had terms for:

  *   "OAM packet that exclusively includes OAM data"
  *   "OAM packet that includes user data"

I don't think "in-packet OAM" conveys unambiguously the intent. I would suggest 
explicit terms such as: "User Data Embedded OAM" or "OAM-embedded User Data".

Thank you.

Cheers,
Med

De : OPSAWG  De la part de Carlos Pignataro
Envoyé : vendredi 5 janvier 2024 21:39
À : Ops Area WG ; Adrian Farrel 
Objet : [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

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.



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

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  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 
> 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.*
*(2) the terms "in-band"/"out-of-band" are already tainted with a multitude
of potential meanings, and have interpretations attached to them. *
*(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)*
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 
>> *Sent:* 12 January 2024 00:09
>> *To:* Carlos Pignataro ; Adrian Farrel <
>> adr...@olddog.co.uk>
>> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls <
>> m...@ietf.org>; spring ; DetNet WG 
>> *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:
>&

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

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  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 
> *Sent:* 12 January 2024 00:09
> *To:* Carlos Pignataro ; Adrian Farrel <
> adr...@olddog.co.uk>
> *Cc:* Ops Area WG ; IETF IPPM WG ; mpls <
> m...@ietf.org>; spring ; DetNet WG 
> *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

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Adrian Farrel]

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.

 

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.

 

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.

 

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  
Sent: 12 January 2024 00:09
To: Carlos Pignataro ; Adrian Farrel 
Cc: Ops Area WG ; IETF IPPM WG ; mpls 
; spring ; DetNet WG 
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?

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).

 

   *  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 equiv

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Greg Mirsky]

   - 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?
   - 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.
   - I that 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.

   *  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.


   - I find the use of "path congruence" in inherently meshed
   packet-switched networks confusing if not misleading. (Note that RFC 6669
    explains congruence by using
   in-band term.) Is there evidence of the term being used besides a single
   case in RFC 6669?
   - Similarly, "in-packet" vs. "dedicated packet". I believe that RFC 7799
    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.
   - 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 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.

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.

Regards,
Greg

On Fri, Jan 5, 2024 at 12:39 PM Carlos Pignataro  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":
>
> 

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Michael Richardson]

Carlos Pignataro  wrote:
> The more practical approach, considering the above, seems to progress this
> document as an RFC and use the same BCP 161 (as RFC6291) -- not sure how 
to
> signal that in the I-D.

Yes, adding this new RFC to BCP161 would make sense.
I don't think that there is a specific way to signal this, except that you
are updating 6291, and you can write some text explaining why, and it would
go into the Shepherd write up.

>> Path-Congruent is a nice technically accurate term.
>> I'm just sure that congruent is a term that is easy to say.  It's very
>> grade
>> 9 geometry class. ("Congruent triangles")
>> Probably it's also the case the native english speakers, if they do not
>> know
>> the term well, will assume something inaccurate, while non-native 
speakers
>> will go
>> look it up.
>>

> Very open to other suggestions -- we opted for optimizing technical
> accuracy in descriptiveness. (Carlos, a non-native English speaker, who
> looks up words in his native languages too)

Yes, so maybe it's not so terrible.  I agree that it's accurate.

>> terms.  I thought I was going to learn more about in-band/out-of-band 
from
>> a
>> military radio point of view, and/or SS7 vs 2600Hz.
>>

> Thank you -- all fixed.

> We'd welcome a citation from radio and/or SS7 telephony!

I don't have a good one; I didn't live through that.
Fidonet, Xmodem->Zmodem to UUCP to IP for me :-)

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

Many thanks Michael for the review and useful feedback!

Please find some follow-ups inline.

On Sun, Jan 7, 2024 at 2:54 PM Michael Richardson 
wrote:

>
> Carlos Pignataro  wrote:
> > 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!
>
> Thank you for the interesting read.
> What do you want to do with this document?
> You say publish it to update RFC6291, but I wonder if revising 6291 might
> be
> better.  In particular, SDN maybe has changed the landscape enough that not
> everyone still has the common understandings.
>

Thank you investing time in review and share feedback!

Our initial intention is to have this document published as a BCP updating
RFC6291 (a BCP), because the two documents are well demarcated in scope
(one about the noun, one about the adjective). RFC6291 stood the test of a
decade+, even without errata.

The more practical approach, considering the above, seems to progress this
document as an RFC and use the same BCP 161 (as RFC6291) -- not sure how to
signal that in the I-D.

Other thoughts?


>
> On this topic, RFC8994, we added qualifications "virtual out-of-band" and
> we
> debated a lot about whether it was in-band or out-of-band!!! Because the
> ACP
> is an overlay network, it is not tied up with the in-band traffic or
> addressing, but it is also not free from depending upon it.
>

And that is, indeed, the issue. On a separate off-list thread, we were
wondering if ICMP is out of band or in band, given different definitions
(in data plane, in packet flow)

Net-net: "there is no band" -- Neo.
And then different discussions and contexts mean different (incompatible)
things for "in-band".

Also RFC 8994 uses the M for Management instead of Maintenance (and this is
sensible to me since it's a management autoconfigured, authenticated,
secure layer, kinda)

   for autonomic functions.  It also serves as a "virtual out-of-band
   channel" for Operations, Administration, and Management (OAM)
   communications over a network that provides automatically configured,




>
> Path-Congruent is a nice technically accurate term.
> I'm just sure that congruent is a term that is easy to say.  It's very
> grade
> 9 geometry class. ("Congruent triangles")
> Probably it's also the case the native english speakers, if they do not
> know
> the term well, will assume something inaccurate, while non-native speakers
> will go
> look it up.
>

Very open to other suggestions -- we opted for optimizing technical
accuracy in descriptiveness. (Carlos, a non-native English speaker, who
looks up words in his native languages too)


>
> Section 3 also has some nice new terms, and I suspect that they are really
> useful in a number of arenas, including up-coming proof-of-transit work.
>

Once again, indeed! PoT is another clear target in our mind.


>
> Nits:
> * OAM is not expanded in the introduction, and the RFC6191 reference needs
> to
> come earlier.
> * Section 2 starts off talking about history, and then gets into defining
> new
> terms.  I thought I was going to learn more about in-band/out-of-band from
> a
> military radio point of view, and/or SS7 vs 2600Hz.
>

Thank you -- all fixed.

We'd welcome a citation from radio and/or SS7 telephony!

Thanks!

Carlos.


>
> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Michael Richardson]

Carlos Pignataro  wrote:
> 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!

Thank you for the interesting read.
What do you want to do with this document?
You say publish it to update RFC6291, but I wonder if revising 6291 might be
better.  In particular, SDN maybe has changed the landscape enough that not
everyone still has the common understandings.

On this topic, RFC8994, we added qualifications "virtual out-of-band" and we
debated a lot about whether it was in-band or out-of-band!!! Because the ACP
is an overlay network, it is not tied up with the in-band traffic or
addressing, but it is also not free from depending upon it.

Path-Congruent is a nice technically accurate term.
I'm just sure that congruent is a term that is easy to say.  It's very grade
9 geometry class. ("Congruent triangles")
Probably it's also the case the native english speakers, if they do not know
the term well, will assume something inaccurate, while non-native speakers will 
go
look it up.

Section 3 also has some nice new terms, and I suspect that they are really
useful in a number of arenas, including up-coming proof-of-transit work.

Nits:
* OAM is not expanded in the introduction, and the RFC6191 reference needs to
come earlier.
* Section 2 starts off talking about history, and then gets into defining new
terms.  I thought I was going to learn more about in-band/out-of-band from a
military radio point of view, and/or SS7 vs 2600Hz.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


signature.asc
Description: PGP signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

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