Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Adrian Farrel]

That sounds like a good point, Dhruv.

 

Cheers,

Adrian

 

From: OPSAWG  On Behalf Of Dhruv Dhody
Sent: 01 May 2024 11:52
To: Henk Birkholz 
Cc: OPSAWG 
Subject: Re: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

 

Hi,

I support adoption. 

Just one comment - 

In-Packet OAM:
The OAM messages are carried as part of data traffic. This was sometimes 
referred to as "in-band".

 

I wonder if "message" is the correct term here. In the example that follow for 
IOAM you use the term "information". 

 

Thanks!
Dhruv

On Wed, Apr 10, 2024 at 4:36 PM Henk Birkholz mailto:henk.birkholz@ietf.contact> > wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html

ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, 
Administration, and Maintenance" (OAM) is used currently & historically 
in the IETF and intends to consolidate unambiguous and protocol agnostic 
terminology for OAM. The summary includes descriptions of narrower 
semantics introduced by added qualifications the term OAM and a list of 
common capabilities that can be found in nodes processing OAM packets.

The chairs acknowledge a positive poll result at IETF119, but there has 
not been much discussion on the list yet. We would like to gather 
feedback from the WG if there is interest to further contribute and 
review. As a potential enabler for discussions, this call will last 
three weeks.

Please reply with your support and especially any substantive comments 
you may have.


For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org <mailto:OPSAWG@ietf.org> 
https://www.ietf.org/mailman/listinfo/opsawg

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Dhruv Dhody]

Hi,

I support adoption.

Just one comment -

In-Packet OAM:
> The OAM messages are carried as part of data traffic. This was sometimes
> referred to as "in-band".


I wonder if "message" is the correct term here. In the example that follow
for IOAM you use the term "information".

Thanks!
Dhruv
On Wed, Apr 10, 2024 at 4:36 PM Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
> >
> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
>
> ending on Thursday, May 2nd.
>
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently & historically
> in the IETF and intends to consolidate unambiguous and protocol agnostic
> terminology for OAM. The summary includes descriptions of narrower
> semantics introduced by added qualifications the term OAM and a list of
> common capabilities that can be found in nodes processing OAM packets.
>
> The chairs acknowledge a positive poll result at IETF119, but there has
> not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> 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

Re: [OPSAWG] WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Thank you Loa for reviewing this document again! Much appreciated.

Please find some follow-ups inline below

On Sun, Apr 21, 2024 at 3:46 AM Loa Andersson  wrote:

> Working Group, Carlos, and Adrian,
>
> The way I understood draft-pignataro-opsawg-oam-whaaat-question-mark, is
> that
> while it updates RFC 6291, the updates are only additions, is that
> correctly
> understood?
>

CMP: Correct.


>
> You give the guidance:
>
>The guidance in this document is to avoid the terms "*-band" and
>instead find finer-granularity descriptive terms. The definitions
>presented in this document are for use in all future IETF documents
>that refer to OAM, and the terms "in-band OAM" and "out-of-band OAM"
>are not to be used in future documents.
>
> You mean that there is no need to go back and update old documents, e.g.
> the MPLS WG has a handful of documents with *-band" in the title.
> If we don't update them for some other reason? If so I support this.
>

CMP: Correct.


>
> Some small nits
>
> - I think we should follow the RFC Editor, OAM is an abbreviation, not an
>   acronym. Yes I know I had it wrong in RFC 6291, and if you want to make
>   that update I'm all for it.
>

CMP: Good question. I believe OAM is an initialism within abbreviations. I
would like the RFC Editor to provide this guidance at the right time.


>
> - you say: [RFC9197] currently uses the acronym "IOAM" for In Situ
>   Operations, Administration, and Maintenance. While this document
>   does not obsolete that acronym, it still recommends that "In situ
>   OAM" is used instead to avoid potential ambiguity.
>
> "Currently there are 7 RFCs that have the abbreviation IOAM in the title,
> RFC 9197, RFC 9322, RFC 9326, RFC 9359, RFC 9378, RFC 9452, and RFC 9486,
> I suspect there are more that have IOAM in the body.
>
> You might want to make this a more general guidance than just to refer
> to RFC 9197.
>

CMP: Done. "RFC 9197 and other dependent documents"


>
> I also think we should make "OAM" well-known, so we don't have to expand
> it when we use e.g. "In situ OAM" in a title.
>
> Other than that I support adopting the draft as a working group draft.
>
>
CMP: Thanks!

Carlos.


>
> /Loa
>
> --
> Loa Andersson
> Senior MPLS Expert
> Bronze Dragon Consulting
> l...@pi.nu
> loa.pi@mail.com
>
>
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Alex Huang Feng]

Dear OPSAWG,

I support the adoption of this draft.
I think centralising the different used terms in one doc is useful.

Regards,
Alex

> On 10 Apr 2024, at 20:05, Henk Birkholz  wrote:
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
>> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
> 
> ending on Thursday, May 2nd.
> 
> As a reminder, this I-D summarizes how the term "Operations, Administration, 
> and Maintenance" (OAM) is used currently & historically in the IETF and 
> intends to consolidate unambiguous and protocol agnostic terminology for OAM. 
> The summary includes descriptions of narrower semantics introduced by added 
> qualifications the term OAM and a list of common capabilities that can be 
> found in nodes processing OAM packets.
> 
> The chairs acknowledge a positive poll result at IETF119, but there has not 
> been much discussion on the list yet. We would like to gather feedback from 
> the WG if there is interest to further contribute and review. As a potential 
> enabler for discussions, this call will last three weeks.
> 
> Please reply with your support and especially any substantive comments you 
> may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> ___
> 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

Re: [OPSAWG] WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Loa Andersson]

Working Group, Carlos, and Adrian,

The way I understood draft-pignataro-opsawg-oam-whaaat-question-mark, is that
while it updates RFC 6291, the updates are only additions, is that correctly
understood?

You give the guidance:

   The guidance in this document is to avoid the terms "*-band" and
   instead find finer-granularity descriptive terms. The definitions
   presented in this document are for use in all future IETF documents
   that refer to OAM, and the terms "in-band OAM" and "out-of-band OAM"
   are not to be used in future documents.

You mean that there is no need to go back and update old documents, e.g.
the MPLS WG has a handful of documents with *-band" in the title.
If we don't update them for some other reason? If so I support this.

Some small nits

- I think we should follow the RFC Editor, OAM is an abbreviation, not an
  acronym. Yes I know I had it wrong in RFC 6291, and if you want to make
  that update I'm all for it.

- you say: [RFC9197] currently uses the acronym "IOAM" for In Situ
  Operations, Administration, and Maintenance. While this document
  does not obsolete that acronym, it still recommends that "In situ
  OAM" is used instead to avoid potential ambiguity.

"Currently there are 7 RFCs that have the abbreviation IOAM in the title,
RFC 9197, RFC 9322, RFC 9326, RFC 9359, RFC 9378, RFC 9452, and RFC 9486,
I suspect there are more that have IOAM in the body.

You might want to make this a more general guidance than just to refer
to RFC 9197.

I also think we should make "OAM" well-known, so we don't have to expand
it when we use e.g. "In situ OAM" in a title.

Other than that I support adopting the draft as a working group draft.


/Loa

-- 
Loa Andersson
Senior MPLS Expert
Bronze Dragon Consulting
l...@pi.nu
loa.pi@mail.com



___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Adrian Farrel]

Hi Henk,

It should come as no surprise that I would be happy to see this adopted.

I want to note that, as is always the case in the IETF, adoption would mean 
that the working group can change every word of the document and even decide to 
abandon the document. So Carlos and I are listening to all of the comments 
being made and trying to work out solutions. Obviously, some of the comments 
are asking for bigger changes than others so will need more discussion, and 
we'll need to bring the WG along as we search for consensus.

Cheers,
Adrian

-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: 10 April 2024 12:06
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html

ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, 
Administration, and Maintenance" (OAM) is used currently & historically 
in the IETF and intends to consolidate unambiguous and protocol agnostic 
terminology for OAM. The summary includes descriptions of narrower 
semantics introduced by added qualifications the term OAM and a list of 
common capabilities that can be found in nodes processing OAM packets.

The chairs acknowledge a positive poll result at IETF119, but there has 
not been much discussion on the list yet. We would like to gather 
feedback from the WG if there is interest to further contribute and 
review. As a potential enabler for discussions, this call will last 
three weeks.

Please reply with your support and especially any substantive comments 
you may have.


For the OPSAWG co-chairs,

Henk

___
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

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[mohamed . boucadair]

Re-,

I'm afraid so. 

I may see a construct where one would need to insist that "virtual out-of-band" 
is actually relying on an underlying (physical/shared) in-band thing. But, 
something which is in-band; no matter whether this is virtual or physical, it 
is still in-band.

Cheers,
Med

> -Message d'origine-
> De : Michael Richardson 
> Envoyé : mardi 16 avril 2024 15:20
> À : BOUCADAIR Mohamed INNOV/NET ; OPSAWG
> 
> Objet : Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-
> oam-whaaat-question-mark-03
> 
> 
> mohamed.boucad...@orange.com wrote:
> > For example, Michael indicated that he wished he had a better
> name for
> > "Virtual In-Band OAM" (I still don’t digest what does that mean
> > actually). I also indicated that I wished I had terms for the
> following
> > when I edited RFC 9451:
> 
> The fact that you don't know what it means from the term means that we
> got something wrong in the name in my opinion :-)
> 
> --
> Michael Richardson. o O ( IPv6 IøT
> consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 


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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Med,
thank you for sharing your thoughts about the draft. I've added my notes
below under GIM>> tag.

Regards,
Greg

On Tue, Apr 16, 2024 at 2:01 PM  wrote:

> Hi Greg, all,
>
>
>
> Having this discussion is by its own sufficient to justify why we need to
> amend rfc6291 with terms that reflect recent needs/usages in a manner that
> can be easily and generally visible to the target audience.
>
GIM>> I don't think that the proposed updates are in any way related to the
scope of RFC 6291. In fact, they are only affecting RFC 7799, which is the
product of the IPPM WG.

>
>
> For example, Michael indicated that he wished he had a better name for
> "Virtual In-Band OAM" (I still don’t digest what does that mean actually).
>
GIM>> I've read the definitions of 'in-band' and "out-of-band" in RFC 8994.
I agree with these definitions with a note that "in-band" also includes
sharing the same schedulers as the data flow(s) being managed/controlled
using management/control plane. In other words, the management and control
plane receive the same QoS as the data plane.

I also indicated that I wished I had terms for the following when I edited
> RFC 9451:
>
>- “OAM packet that exclusively includes OAM data”
>- “OAM packet that includes user data”
>
> GIM>> RFC 7799, AFAICS, defines the first case as an active OAM, i.e.,
using specifically constructed synthetic packet. The second case - an
example of hybrid OAM method as it combines elements of Active (inclusion
of OAM-specific construct in a data packet) with Passive . Of course, RFC
9451 could have defined its own terms and explicitly list in Terminology
section.

>
>
> I think that we can leverage some definition entries in various documents
> out there (detnet, for example) when this makes sense. Some of the existing
> terms, although used in RFCs, fail to unambiguously convey the intended
> meaning. I don’t think it is problematic to acknowledge that fact and
> consider alternate terms.
>
GIM>> As I've noted before, a term cannot be expected to be
self-explanatory. That is the responcibility of the authors, WG, and all of
us to have explicitly defined dictionary being used in our documents.

>
>
> Of course, this is a cross-WG effort and a pre-requisite I expect for it
> is that the authors commit in soliciting the feedback from relevant WGs.
>
>
>
> I don’t think it is premature to consider adopting this work here in
> OPSAWG. As you know, the content is not frozen given that this is simply a
> call for adoption, not a Last Call.
>
GIM>> I think that we have different perspective and expectations of the
process. That's is okay. I believe that WG Chairs and the Responcible AD
will find the way forward to further advance the development of Internet
and technologies that enable its continuous growth.

>
>
> Cheers,
>
> Med
>
>
>
> *De :* OPSAWG  *De la part de* Greg Mirsky
> *Envoyé :* mardi 16 avril 2024 10:11
> *À :* Carlos Pignataro 
> *Cc :* OPSAWG 
> *Objet :* Re: [OPSAWG]  WG Adoption Call for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
>
>
>
> Dear Carlos,
>
> thank you for making my point even clearer. I do believe that a term may
> have interpretation in different scopes - a document, a series of
> documents, or across all IETF documents. RFC 9551 established the
> interpretation of terms for all DetNet OAM documents. The document under
> discussion, draft-pignataro-opsawg-oam-whaaat-question-mark, as I
> understand its intention, is to establish the scope across all IETF
> documents. That, IMHO, imposes on the decision already made by the DetNet
> WG (and, AFAICS, shared by several other WGs). That is why I consider the
> WG AP premature and encourage the authors to reach out across the WG and
> Area boundaries to socialize the document more before taking any steps to
> progress it.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro 
> wrote:
>
> Greg,
>
>
>
> Repeating something does not make it so…
>
>
>
> You had argued that those were definitions only within the context of
> DetNet, and each context can have different ones. You really cannot have it
> both ways. This is confusing.
>
>
>
> I-Ds follow causality — lots of things were approved to then be corrected.
>
>
>
> In-band — out-of-band — what do they really mean when…
>
>
>
> There is no “band”
>
>
>
>
>
>
>
> C
>
>
>
> Thumb typed by Carlos Pignataro.
>
> Excuze typofraphicak errows
>
>
>
> On Apr 15, 2024, at 09:03, Greg Mirsky  wrote:
>
> 
>
> Hi Carlos,
>
> I have to repeat that the definitions of te

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Michael,
I don't think that every term must and can be self-explanatory. We develop
our dictionary through the development of explicitly defined terms. That is
what we use Terminology section in our drafts for. And, AFAICS, it is
normal to expect that anyone interested in the field, in the particular
application or protocol, read all the relevant documents to learn about the
principles as well as the dictionary used.

Regards,
Greg

On Tue, Apr 16, 2024 at 3:20 PM Michael Richardson 
wrote:

>
> mohamed.boucad...@orange.com wrote:
> > For example, Michael indicated that he wished he had a better name
> for
> > "Virtual In-Band OAM" (I still don’t digest what does that mean
> > actually). I also indicated that I wished I had terms for the
> following
> > when I edited RFC 9451:
>
> The fact that you don't know what it means from the term means that we got
> something wrong in the name in my opinion :-)
>
> --
> 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
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Michael Richardson]

mohamed.boucad...@orange.com wrote:
> For example, Michael indicated that he wished he had a better name for
> "Virtual In-Band OAM" (I still don’t digest what does that mean
> actually). I also indicated that I wished I had terms for the following
> when I edited RFC 9451:

The fact that you don't know what it means from the term means that we got
something wrong in the name in my opinion :-)

--
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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[mohamed . boucadair]

Hi Greg, all,

Having this discussion is by its own sufficient to justify why we need to amend 
rfc6291 with terms that reflect recent needs/usages in a manner that can be 
easily and generally visible to the target audience.

For example, Michael indicated that he wished he had a better name for "Virtual 
In-Band OAM" (I still don’t digest what does that mean actually). I also 
indicated that I wished I had terms for the following when I edited RFC 9451:

  *   “OAM packet that exclusively includes OAM data”
  *   “OAM packet that includes user data”

I think that we can leverage some definition entries in various documents out 
there (detnet, for example) when this makes sense. Some of the existing terms, 
although used in RFCs, fail to unambiguously convey the intended meaning. I 
don’t think it is problematic to acknowledge that fact and consider alternate 
terms.

Of course, this is a cross-WG effort and a pre-requisite I expect for it is 
that the authors commit in soliciting the feedback from relevant WGs.

I don’t think it is premature to consider adopting this work here in OPSAWG. As 
you know, the content is not frozen given that this is simply a call for 
adoption, not a Last Call.

Cheers,
Med

De : OPSAWG  De la part de Greg Mirsky
Envoyé : mardi 16 avril 2024 10:11
À : Carlos Pignataro 
Cc : OPSAWG 
Objet : Re: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear Carlos,
thank you for making my point even clearer. I do believe that a term may have 
interpretation in different scopes - a document, a series of documents, or 
across all IETF documents. RFC 9551 established the interpretation of terms for 
all DetNet OAM documents. The document under discussion, 
draft-pignataro-opsawg-oam-whaaat-question-mark, as I understand its intention, 
is to establish the scope across all IETF documents. That, IMHO, imposes on the 
decision already made by the DetNet WG (and, AFAICS, shared by several other 
WGs). That is why I consider the WG AP premature and encourage the authors to 
reach out across the WG and Area boundaries to socialize the document more 
before taking any steps to progress it.

Regards,
Greg

On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro 
mailto:cpign...@gmail.com>> wrote:
Greg,

Repeating something does not make it so…

You had argued that those were definitions only within the context of DetNet, 
and each context can have different ones. You really cannot have it both ways. 
This is confusing.

I-Ds follow causality — lots of things were approved to then be corrected.

In-band — out-of-band — what do they really mean when…

There is no “band”



C

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows


On Apr 15, 2024, at 09:03, Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:

Hi Carlos,
I have to repeat that the definitions of terms "in-band OAM", "out-of-band 
OAM", and "on-path telemetry"
   In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet
  domain may not be topologically identical to the path of the
  monitored DetNet flow, its test packets may receive different QoS
  and/or PREOF treatment, or both.

   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
  method.  The origination of the telemetry information is
  inherently in band as packets in a DetNet flow are used as
  triggers.  Collection of the on-path telemetry information can be
  performed using in-band or out-of-band OAM methods.

have been adopted by DetNet WG, approved by IESG and published as part of RFC 
9551<https://datatracker.ietf.org/doc/rfc9551/>. I believe that a constructive 
approach would be to use the already accepted terminology, not to attempt to 
negate what has already been achieved in building up the IETF dictionary, 
particularly in the OAM area.

Regards,
Greg

On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro 
mailto:cpign...@gmail.com>> wrote:
Dear Greg,

Thank you for the input.

It appears that much of what you write below was already discussed at 
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/

Am I to understand you might be keen on continuing using "in-band OAM" with 
different meanings depending on the WG or context?

Please find some follow-ups inline below:

On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
mailto:gregimir...@gmail.com>> wrote:
Dear All,
I've read the latest version of the draft, Please find my notes and questions 
below:

  *   All SDOs that standardize methods and/or protocols in the field of OAM 
recognize that, in the FCAPS network management m

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Michael Richardson]

Greg Mirsky  wrote:
> thank you for the update. I'm glad that you found the definition in RFC
> 9551 working for ANIMA's Autonomic Control Plane as well. I will read RFC
> 8994 to educate myself about it.

Well, it works within 9551's definition, but I don't like the term we wound up 
with.

--
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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Dear Carlos,
thank you for making my point even clearer. I do believe that a term may
have interpretation in different scopes - a document, a series of
documents, or across all IETF documents. RFC 9551 established the
interpretation of terms for all DetNet OAM documents. The document under
discussion, draft-pignataro-opsawg-oam-whaaat-question-mark, as I
understand its intention, is to establish the scope across all IETF
documents. That, IMHO, imposes on the decision already made by the DetNet
WG (and, AFAICS, shared by several other WGs). That is why I consider the
WG AP premature and encourage the authors to reach out across the WG and
Area boundaries to socialize the document more before taking any steps to
progress it.

Regards,
Greg

On Tue, Apr 16, 2024 at 4:52 AM Carlos Pignataro  wrote:

> Greg,
>
> Repeating something does not make it so…
>
> You had argued that those were definitions only within the context of
> DetNet, and each context can have different ones. You really cannot have it
> both ways. This is confusing.
>
> I-Ds follow causality — lots of things were approved to then be corrected.
>
> In-band — out-of-band — what do they really mean when…
>
> There is no “band”
>
> [image: image]
>
> C
>
> Thumb typed by Carlos Pignataro.
> Excuze typofraphicak errows
>
> On Apr 15, 2024, at 09:03, Greg Mirsky  wrote:
>
> 
> Hi Carlos,
> I have to repeat that the definitions of terms "in-band OAM", "out-of-band
> OAM", and "on-path telemetry"
>In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet
>   domain may not be topologically identical to the path of the
>   monitored DetNet flow, its test packets may receive different QoS
>   and/or PREOF treatment, or both.
>
>On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
>   method.  The origination of the telemetry information is
>   inherently in band as packets in a DetNet flow are used as
>   triggers.  Collection of the on-path telemetry information can be
>   performed using in-band or out-of-band OAM methods.
>
> have been adopted by DetNet WG, approved by IESG and published as part of RFC
> 9551 . I believe that a
> constructive approach would be to use the already accepted terminology, not
> to attempt to negate what has already been achieved in building up the IETF
> dictionary, particularly in the OAM area.
>
> Regards,
> Greg
>
> On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro 
> wrote:
>
>> Dear Greg,
>>
>> Thank you for the input.
>>
>> It appears that much of what you write below was already discussed at
>> https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
>>
>>
>> Am I to understand you might be keen on continuing using "in-band OAM"
>> with different meanings depending on the WG or context?
>>
>> Please find some follow-ups inline below:
>>
>> On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
>> wrote:
>>
>>> Dear All,
>>> I've read the latest version of the draft, Please find my notes and
>>> questions below:
>>>
>>>- All SDOs that standardize methods and/or protocols in the field of
>>>OAM recognize that, in the FCAPS network management model, OAM is
>>>addressing the 'F' and 'P', i.e., Fault Management and Performance
>>>Monitoring methods and protocols. Furthermore, OAM is understood as a
>>>collection of various methods and protocols, rather than a single 
>>> protocol,
>>>method, or tool. Hence, it seems like the document must use the same more
>>>granular approach in characterizing this or that OAM mechanism, including
>>>the possible variance in the application of that mechanism.
>>>
>>> CMP: This document intends to Update RFC 6291, a product of the IETF
>> about OAM language usage, with support from its lead editor.
>>
>>>
>>>- I was under the impression that the discussion about the
>>>unfortunate choice of the original extended form of IOAM, "In-band OAM",
>>>has been put to rest with the agreement to extend it as "In-situ OAM". 
>>> Why
>>>bring that discussion back? To revisit the decision of the IPPM WG? If 
>>> so,
>>>then, as I imagine, that must be discussed in the IPPM WG.
>>>
>>> CMP: Not really, as explained in the draft already, clearly. See
>> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/
>>
>>
>>>
>>>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>>>reliably understood consistently and unambiguously." That is a very 
>>> strong
>>>and powerful statement that, in my opinion, requires serious analysis. 
>>> For
>>>example, a survey of the IETF community 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Greg,Repeating something does not make it so…You had argued that those were definitions only within the context of DetNet, and each context can have different ones. You really cannot have it both ways. This is confusing. I-Ds follow causality — lots of things were approved to then be corrected. In-band — out-of-band — what do they really mean when…There is no “band”CThumb typed by Carlos Pignataro.Excuze typofraphicak errowsOn Apr 15, 2024, at 09:03, Greg Mirsky  wrote:Hi Carlos,I have to repeat that the definitions of terms "in-band OAM", "out-of-band OAM", and "on-path telemetry"   In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet      domain may not be topologically identical to the path of the      monitored DetNet flow, its test packets may receive different QoS      and/or PREOF treatment, or both.   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM      method.  The origination of the telemetry information is      inherently in band as packets in a DetNet flow are used as      triggers.  Collection of the on-path telemetry information can be      performed using in-band or out-of-band OAM methods.have been adopted by DetNet WG, approved by IESG and published as part of RFC 9551. I believe that a constructive approach would be to use the already accepted terminology, not to attempt to negate what has already been achieved in building up the IETF dictionary, particularly in the OAM area.Regards,GregOn Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro  wrote:Dear Greg,Thank you for the input.It appears that much of what you write below was already discussed at https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/ Am I to understand you might be keen on continuing using "in-band OAM" with different meanings depending on the WG or context?Please find some follow-ups inline below:On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky  wrote:Dear All,I've read the latest version of the draft, Please find my notes and questions below:All SDOs that standardize methods and/or protocols in the field of OAM recognize that, in the FCAPS network management model, OAM is addressing the 'F' and 'P', i.e., Fault Management and Performance Monitoring methods and protocols. Furthermore, OAM is understood as a collection of various methods and protocols, rather than a single protocol, method, or tool. Hence, it seems like the document must use the same more granular approach in characterizing this or that OAM mechanism, including the possible variance in the application of that mechanism.CMP: This document intends to Update RFC 6291, a product of the IETF about OAM language usage, with support from its lead editor.I was under the impression that the discussion about the unfortunate choice of the original extended form of IOAM, "In-band OAM", has been put to rest with the agreement to extend it as "In-situ OAM". Why bring that discussion back? To revisit the decision of the IPPM WG? If so, then, as I imagine, that must be discussed in the IPPM WG.CMP: Not really, as explained in the draft already, clearly. See https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/ "Within the IETF, the terms "in-band" and "out-of-band" cannot be reliably understood consistently and unambiguously." That is a very strong and powerful statement that, in my opinion, requires serious analysis. For example, a survey of the IETF community that undoubtedly demonstrates the existence of multiple confronting interpretations that cannot be resolved by a mere wordsmithing. Can the authors cite such a survey and its results?CMP: The document already contains that analysis. It explains why those terms cannot be reliably understood consistently and unambiguously. And closely following that statement "the terms are not self-defining any more and cannot be understood by someone exposed to them for the first time" seems to break the very foundation of IETF TAO - learn, learn, and learn. I find the expectation of a first-comer to any IETF discussion to be able to fully master all the dictionary and terminology of that group to be, in my experience, a misguided. Through years, I've been suggesting anyone interested in joining and contributing to IETF work to first read (drafts, RFCs) and, most of all, the mail archive. Probably, I've been wasting their time..CMP: I am not sure I follow what you mean here -- but, (1) https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2) **There is no band** The following passage brings additional question:The guidance in this document is to avoid the terms "*-band" and instead find finer-granularity 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Michael,
thank you for the update. I'm glad that you found the definition in RFC
9551 working for ANIMA's Autonomic Control Plane as well. I will read RFC
8994 to educate myself about it.

Regards,
Greg

On Mon, Apr 15, 2024 at 5:54 PM Michael Richardson 
wrote:

>
> Greg Mirsky  wrote:
> > I have to repeat that the definitions of terms "in-band OAM",
> "out-of-band
> > OAM", and "on-path telemetry"
>
> > In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet
> > domain may not be topologically identical to the path of the
> > monitored DetNet flow, its test packets may receive different QoS
> > and/or PREOF treatment, or both.
>
> On the topic of RFC8994's overlay management network, which we described as
> virtual out-of-band.  It would seem to fit into the above definition, since
> the overlay packets might go another route, and might get a different QoS
> treatment.
>
>
> --
> 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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Michael Richardson]

Greg Mirsky  wrote:
> I have to repeat that the definitions of terms "in-band OAM", "out-of-band
> OAM", and "on-path telemetry"

> In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet
> domain may not be topologically identical to the path of the
> monitored DetNet flow, its test packets may receive different QoS
> and/or PREOF treatment, or both.

On the topic of RFC8994's overlay management network, which we described as
virtual out-of-band.  It would seem to fit into the above definition, since
the overlay packets might go another route, and might get a different QoS
treatment.


--
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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Hi Carlos,
I have to repeat that the definitions of terms "in-band OAM", "out-of-band
OAM", and "on-path telemetry"
   In-band OAM:  an active OAM method 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:  an active OAM method whose path through the DetNet
  domain may not be topologically identical to the path of the
  monitored DetNet flow, its test packets may receive different QoS
  and/or PREOF treatment, or both.

   On-path telemetry:  on-path telemetry can be realized as a hybrid OAM
  method.  The origination of the telemetry information is
  inherently in band as packets in a DetNet flow are used as
  triggers.  Collection of the on-path telemetry information can be
  performed using in-band or out-of-band OAM methods.

have been adopted by DetNet WG, approved by IESG and published as part of RFC
9551 . I believe that a
constructive approach would be to use the already accepted terminology, not
to attempt to negate what has already been achieved in building up the IETF
dictionary, particularly in the OAM area.

Regards,
Greg

On Mon, Apr 15, 2024 at 2:00 PM Carlos Pignataro  wrote:

> Dear Greg,
>
> Thank you for the input.
>
> It appears that much of what you write below was already discussed at
> https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/
>
> Am I to understand you might be keen on continuing using "in-band OAM"
> with different meanings depending on the WG or context?
>
> Please find some follow-ups inline below:
>
> On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky 
> wrote:
>
>> Dear All,
>> I've read the latest version of the draft, Please find my notes and
>> questions below:
>>
>>- All SDOs that standardize methods and/or protocols in the field of
>>OAM recognize that, in the FCAPS network management model, OAM is
>>addressing the 'F' and 'P', i.e., Fault Management and Performance
>>Monitoring methods and protocols. Furthermore, OAM is understood as a
>>collection of various methods and protocols, rather than a single 
>> protocol,
>>method, or tool. Hence, it seems like the document must use the same more
>>granular approach in characterizing this or that OAM mechanism, including
>>the possible variance in the application of that mechanism.
>>
>> CMP: This document intends to Update RFC 6291, a product of the IETF
> about OAM language usage, with support from its lead editor.
>
>>
>>- I was under the impression that the discussion about the
>>unfortunate choice of the original extended form of IOAM, "In-band OAM",
>>has been put to rest with the agreement to extend it as "In-situ OAM". Why
>>bring that discussion back? To revisit the decision of the IPPM WG? If so,
>>then, as I imagine, that must be discussed in the IPPM WG.
>>
>> CMP: Not really, as explained in the draft already, clearly. See
> https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/
>
>>
>>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>>reliably understood consistently and unambiguously." That is a very strong
>>and powerful statement that, in my opinion, requires serious analysis. For
>>example, a survey of the IETF community that undoubtedly demonstrates the
>>existence of multiple confronting interpretations that cannot be resolved
>>by a mere wordsmithing. Can the authors cite such a survey and its 
>> results?
>>
>>
> CMP: The document already contains that analysis. It explains why those
> terms cannot be reliably understood consistently and unambiguously.
>
>>
>>- And closely following that statement "the terms are not
>>self-defining any more and cannot be understood by someone exposed to them
>>for the first time" seems to break the very foundation of IETF TAO - 
>> learn,
>>learn, and learn. I find the expectation of a first-comer to any IETF
>>discussion to be able to fully master all the dictionary and terminology 
>> of
>>that group to be, in my experience, a misguided. Through years, I've been
>>suggesting anyone interested in joining and contributing to IETF work to
>>first read (drafts, RFCs) and, most of all, the mail archive. Probably,
>>I've been wasting their time..
>>
>> CMP: I am not sure I follow what you mean here -- but, (1)
> https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2)
> **There is no band**
>
>
>>
>>- The following passage brings additional question:
>>
>> The guidance in this document is to avoid the terms "*-band" and instead
>> find finer-granularity descriptive terms. The definitions presented in this
>> document are for use in all future IETF documents that refer to OAM, 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Dear Greg,

Thank you for the input.

It appears that much of what you write below was already discussed at
https://mailarchive.ietf.org/arch/msg/opsawg/IVQzSSU_kvGgopCyCp-8oqK_xmg/

Am I to understand you might be keen on continuing using "in-band OAM" with
different meanings depending on the WG or context?

Please find some follow-ups inline below:

On Sun, Apr 14, 2024 at 10:49 AM Greg Mirsky  wrote:

> Dear All,
> I've read the latest version of the draft, Please find my notes and
> questions below:
>
>- All SDOs that standardize methods and/or protocols in the field of
>OAM recognize that, in the FCAPS network management model, OAM is
>addressing the 'F' and 'P', i.e., Fault Management and Performance
>Monitoring methods and protocols. Furthermore, OAM is understood as a
>collection of various methods and protocols, rather than a single protocol,
>method, or tool. Hence, it seems like the document must use the same more
>granular approach in characterizing this or that OAM mechanism, including
>the possible variance in the application of that mechanism.
>
> CMP: This document intends to Update RFC 6291, a product of the IETF about
OAM language usage, with support from its lead editor.

>
>- I was under the impression that the discussion about the unfortunate
>choice of the original extended form of IOAM, "In-band OAM", has been put
>to rest with the agreement to extend it as "In-situ OAM". Why bring that
>discussion back? To revisit the decision of the IPPM WG? If so, then, as I
>imagine, that must be discussed in the IPPM WG.
>
> CMP: Not really, as explained in the draft already, clearly. See
https://mailarchive.ietf.org/arch/msg/opsawg/jREEH1sFOZ-uxZNky-RTggpxkuk/

>
>- "Within the IETF, the terms "in-band" and "out-of-band" cannot be
>reliably understood consistently and unambiguously." That is a very strong
>and powerful statement that, in my opinion, requires serious analysis. For
>example, a survey of the IETF community that undoubtedly demonstrates the
>existence of multiple confronting interpretations that cannot be resolved
>by a mere wordsmithing. Can the authors cite such a survey and its results?
>
>
CMP: The document already contains that analysis. It explains why those
terms cannot be reliably understood consistently and unambiguously.

>
>- And closely following that statement "the terms are not
>self-defining any more and cannot be understood by someone exposed to them
>for the first time" seems to break the very foundation of IETF TAO - learn,
>learn, and learn. I find the expectation of a first-comer to any IETF
>discussion to be able to fully master all the dictionary and terminology of
>that group to be, in my experience, a misguided. Through years, I've been
>suggesting anyone interested in joining and contributing to IETF work to
>first read (drafts, RFCs) and, most of all, the mail archive. Probably,
>I've been wasting their time..
>
> CMP: I am not sure I follow what you mean here -- but, (1)
https://www.ietf.org/archive/id/draft-tenoever-tao-retirement-03.html (2)
**There is no band**


>
>- The following passage brings additional question:
>
> The guidance in this document is to avoid the terms "*-band" and instead
> find finer-granularity descriptive terms. The definitions presented in this
> document are for use in all future IETF documents that refer to OAM, and
> the terms "in-band OAM" and "out-of-band OAM" are not to be used in future
> documents.
>
>
>- Is such an overreaching scope of the OPSAWG WG in its charter?
>
> CMP: That is a question for the chairs, but this document originating in
opsawg will need to have ietf-wide review...

>
>- I found a number of references to DetNet OAM that, regrettably,
>misinterpreted documents approved by DetNet WG and some already published
>as RFCs. I can only encourage an open communication between the proponents
>of this work and the DetNet WG rather than an attempt to force something
>foreign to the essence of Deterministic Networking and the application of
>OAM in DetNet.
>- It appears that the term "Combined OAM", introduced in this
>document, allows for a combination of "Non-Path Congruent OAM" with
>"Equal-QoS-Treatment OAM". If that is the case, what do you see as the
>value of using such "combined OAM"?
>- In my reading of Section 3 and references to RFC 7799, I find it
>getting close to benign misinterpretation of RFC 7799:
>   - Firstly, RFC 7799 appropriately discusses OAM methods and
>   metrics, i.e., elements of OAM. Hence, because of, what seems like, a
>   misunderstanding of how OAM is composed, the document dismisses RFC 7799
>   even though that is the fundamental document with 16 references by IETF
>   documents and more by documents in other SDOs.
>   - In the definition of the "Compound OAM" it is suggested that a

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Greg Mirsky]

Dear All,
I've read the latest version of the draft, Please find my notes and
questions below:

   - All SDOs that standardize methods and/or protocols in the field of OAM
   recognize that, in the FCAPS network management model, OAM is addressing
   the 'F' and 'P', i.e., Fault Management and Performance Monitoring methods
   and protocols. Furthermore, OAM is understood as a collection of
   various methods and protocols, rather than a single protocol, method, or
   tool. Hence, it seems like the document must use the same more granular
   approach in characterizing this or that OAM mechanism, including the
   possible variance in the application of that mechanism.
   - I was under the impression that the discussion about the unfortunate
   choice of the original extended form of IOAM, "In-band OAM", has been put
   to rest with the agreement to extend it as "In-situ OAM". Why bring that
   discussion back? To revisit the decision of the IPPM WG? If so, then, as I
   imagine, that must be discussed in the IPPM WG.
   - "Within the IETF, the terms "in-band" and "out-of-band" cannot be
   reliably understood consistently and unambiguously." That is a very strong
   and powerful statement that, in my opinion, requires serious analysis. For
   example, a survey of the IETF community that undoubtedly demonstrates the
   existence of multiple confronting interpretations that cannot be resolved
   by a mere wordsmithing. Can the authors cite such a survey and its results?
   - And closely following that statement "the terms are not self-defining
   any more and cannot be understood by someone exposed to them for the first
   time" seems to break the very foundation of IETF TAO - learn, learn, and
   learn. I find the expectation of a first-comer to any IETF discussion to be
   able to fully master all the dictionary and terminology of that group to
   be, in my experience, a misguided. Through years, I've been suggesting
   anyone interested in joining and contributing to IETF work to first read
   (drafts, RFCs) and, most of all, the mail archive. Probably, I've been
   wasting their time..
   - The following passage brings additional question:

The guidance in this document is to avoid the terms "*-band" and instead
find finer-granularity descriptive terms. The definitions presented in this
document are for use in all future IETF documents that refer to OAM, and
the terms "in-band OAM" and "out-of-band OAM" are not to be used in future
documents.


   - Is such an overreaching scope of the OPSAWG WG in its charter?
   - I found a number of references to DetNet OAM that, regrettably,
   misinterpreted documents approved by DetNet WG and some already published
   as RFCs. I can only encourage an open communication between the proponents
   of this work and the DetNet WG rather than an attempt to force something
   foreign to the essence of Deterministic Networking and the application of
   OAM in DetNet.
   - It appears that the term "Combined OAM", introduced in this document,
   allows for a combination of "Non-Path Congruent OAM" with
   "Equal-QoS-Treatment OAM". If that is the case, what do you see as the
   value of using such "combined OAM"?
   - In my reading of Section 3 and references to RFC 7799, I find it
   getting close to benign misinterpretation of RFC 7799:
  - Firstly, RFC 7799 appropriately discusses OAM methods and metrics,
  i.e., elements of OAM. Hence, because of, what seems like, a
  misunderstanding of how OAM is composed, the document dismisses RFC 7799
  even though that is the fundamental document with 16 references by IETF
  documents and more by documents in other SDOs.
  - In the definition of the "Compound OAM" it is suggested that a
  combination of Active and Hybrid OAM methods or of Passive and Hybrid OAM
  methods are distinct examples of Compound OAM. If that is the intention,
  how to reconcile that with the definition of a Hybrid OAM method in RFC
  7799:

   Hybrid Methods are Methods of Measurement that use a combination of
   Active Methods and Passive Methods, to assess Active Metrics, Passive
   Metrics, or new metrics derived from the a priori knowledge and
   observations of the stream of interest.

It does appear, that unless this document updates or obsoletes RFC 7799, a
combination of Active and Hybrid or Passive and Hybrid methods will still
be a Hybrid OAM method. Actually, according to the following assesment:
[RFC7799] adds to the confusion by describing "passive methods" as "out of
band". Following the guidelines of this document, OAM may be qualified
according to the terms described in Sections 2 and 3 of this document, and
the term "out of band OAM" is not to be used in future documents.

updating RFC 7799 is the intention of this document. Or am I missing
something here?


As the conclusion. Although the document is well-written, I don't find it
addressing a real problem, nor offering a viable, useful solution. 

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Thank you Xiao! All good commends and addressed in the next revision.

Carlos.

> On Apr 11, 2024, at 11:43 PM, xiao.m...@zte.com.cn wrote:
> 
> I support wg adoption of this draft.
> 
> Responding to the call for discussion by the chairs, I would provide some 
> comments for the authors consideration.
> 
> 
> 
> 1. Abstract and Section 2,
> 
> In Abstract it says "
> 
> A case in point is the qualifiers "in-band" and
>"out-of-band" which have their origins in the radio lexicon and which
>have been extrapolated into other communication networks.".
> While in Section 2 it says "
> 
> Historically, the terms "in-band" and "out-of-band" were used
>extensively in telephony signaling [RFC4733] and appear also in radio
>communications.".
> Just curious about whether the term in-band/out-of-band comes from radio 
> communications or telephony signaling.
> 
> 2. Section 2, several characteristics including Path, Packet, and Packet 
> Treatment are used for OAM classification, it seems to me they're not in 
> parallel, e.g., the classification between Path-Congruent OAM and 
> Non-Path-Congruent OAM applies to only Dedicated-Packet OAM, but not 
> In-Packet OAM. It would help if some clarification can be added.
> 
> 3. Section 3 and 5, RFC 9322 allows adding an In situ OAM header to a copy of 
> data packet or a dedicated OAM packet (e.g. STAMP), to my understanding it 
> can be classified as Active OAM, if that's the case, the text in Section 5 
> needs to be tweaked, because in this case not only Source Node and Sink Node 
> are involved in Active OAM processing.
> 
> 
> 
> Best Regards,
> 
> Xiao Min
> 
> Original
> From: HenkBirkholz 
> To: OPSAWG ;
> Date: 2024年04月10日 19:06
> Subject: [OPSAWG]  WG Adoption Call for 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> > https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
> 
> ending on Thursday, May 2nd.
> 
> As a reminder, this I-D summarizes how the term "Operations,  
> Administration, and Maintenance" (OAM) is used currently & historically  
> in the IETF and intends to consolidate unambiguous and protocol agnostic  
> terminology for OAM. The summary includes descriptions of narrower  
> semantics introduced by added qualifications the term OAM and a list of  
> common capabilities that can be found in nodes processing OAM packets.
> 
> The chairs acknowledge a positive poll result at IETF119, but there has  
> not been much discussion on the list yet. We would like to gather  
> feedback from the WG if there is interest to further contribute and  
> review. As a potential enabler for discussions, this call will last  
> three weeks.
> 
> Please reply with your support and especially any substantive comments  
> you may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> ___
> 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



signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[xiao.min2]

I support wg adoption of this draft.
Responding to the call for discussion by the chairs, I would provide some 
comments for the authors consideration.

1. Abstract and Section 2,
In Abstract it says "
A case in point is the qualifiers "in-band" and
 "out-of-band" which have their origins in the radio lexicon and which
 have been extrapolated into other communication networks.".
While in Section 2 it says "
Historically, the terms "in-band" and "out-of-band" were used
 extensively in telephony signaling [RFC4733] and appear also in radio
 communications.".
Just curious about whether the term in-band/out-of-band comes from radio 
communications or telephony signaling.
2. Section 2, several characteristics including Path, Packet, and Packet 
Treatment are used for OAM classification, it seems to me they're not in 
parallel, e.g., the classification between Path-Congruent OAM and 
Non-Path-Congruent OAM applies to only Dedicated-Packet OAM, but not In-Packet 
OAM. It would help if some clarification can be added.
3. Section 3 and 5, RFC 9322 allows adding an In situ OAM header to a copy of 
data packet or a dedicated OAM packet (e.g. STAMP), to my understanding it can 
be classified as Active OAM, if that's the case, the text in Section 5 needs to 
be tweaked, because in this case not only Source Node and Sink Node are 
involved in Active OAM processing.

Best Regards,
Xiao Min

Original


From: HenkBirkholz 
To: OPSAWG ;
Date: 2024年04月10日 19:06
Subject: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear OPSAWG members,
 
this email starts a call for Working Group Adoption of
 
> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
 
ending on Thursday, May 2nd.
 
As a reminder, this I-D summarizes how the term "Operations,  
Administration, and Maintenance" (OAM) is used currently & historically  
in the IETF and intends to consolidate unambiguous and protocol agnostic  
terminology for OAM. The summary includes descriptions of narrower  
semantics introduced by added qualifications the term OAM and a list of  
common capabilities that can be found in nodes processing OAM packets.
 
The chairs acknowledge a positive poll result at IETF119, but there has  
not been much discussion on the list yet. We would like to gather  
feedback from the WG if there is interest to further contribute and  
review. As a potential enabler for discussions, this call will last  
three weeks.
 
Please reply with your support and especially any substantive comments  
you may have.
 
 
For the OPSAWG co-chairs,
 
Henk
 
___
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

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Giuseppe Fioccola]

Dear All,
I support the adoption of this draft since it aims to provide guidelines for 
OAM terminology, and I think this is quite useful. I’m interested in 
contributing and I would also suggest to involve IPPM WG for further review, 
considering the correlation with RFC 7799 .

Regards,

Giuseppe

-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, April 10, 2024 1:06 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03

Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-ques
> tion-mark-03.html

ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, Administration, 
and Maintenance" (OAM) is used currently & historically in the IETF and intends 
to consolidate unambiguous and protocol agnostic terminology for OAM. The 
summary includes descriptions of narrower semantics introduced by added 
qualifications the term OAM and a list of common capabilities that can be found 
in nodes processing OAM packets.

The chairs acknowledge a positive poll result at IETF119, but there has not 
been much discussion on the list yet. We would like to gather feedback from the 
WG if there is interest to further contribute and review. As a potential 
enabler for discussions, this call will last three weeks.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

___
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

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[mohamed . boucadair]

Hi all, 

This is really useful work. I support adoption. 

Some coordination with other WGs will be needed, but I'm confident 
Carlos/Adrian will drive that through.

I have comments about some of the proposed terms: consider path coupled/path 
decoupled OAM instead of path path-congruent terms + “User Data Embedded OAM” 
or “OAM-embedded User Data” instead of the ambiguous “in-packet OAM”. 

I trust that discussion to continue when (hopefully) the doc is adopted.

Thank you.

Cheers,
Med

> -Message d'origine-
> De : OPSAWG  De la part de Henk Birkholz
> Envoyé : mercredi 10 avril 2024 13:06
> À : OPSAWG 
> Objet : [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-
> whaaat-question-mark-03
> 
> 
> Dear OPSAWG members,
> 
> this email starts a call for Working Group Adoption of
> 
> >
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ietf.org%2Farchive%2Fid%2Fdraft-pignataro-opsawg-oam-whaaat-
> question-m
> > ark-
> 03.html=05%7C02%7Cmohamed.boucadair%40orange.com%7C443f572f51
> >
> af4bee4cbd08dc594e2f2f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> >
> 8483439534955276%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=WsZJskcEImRAO
> > mAS9feqGgSEAPV4R0Cz%2F5aPbpF1kOI%3D=0
> 
> ending on Thursday, May 2nd.
> 
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently &
> historically in the IETF and intends to consolidate unambiguous and
> protocol agnostic terminology for OAM. The summary includes
> descriptions of narrower semantics introduced by added qualifications
> the term OAM and a list of common capabilities that can be found in
> nodes processing OAM packets.
> 
> The chairs acknowledge a positive poll result at IETF119, but there
> has not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
> 
> Please reply with your support and especially any substantive comments
> you may have.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 


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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Thomas.Graf]

Dear OPSAWG,

I have read the document and support the adoption in OPSAWG. A OAM terminology 
is much needed.

Best wishes
Thomas

-Original Message-
From: OPSAWG  On Behalf Of Henk Birkholz
Sent: Wednesday, April 10, 2024 1:06 PM
To: OPSAWG 
Subject: [OPSAWG]  WG Adoption Call for 
draft-pignataro-opsawg-oam-whaaat-question-mark-03


Be aware: This is an external email.



Dear OPSAWG members,

this email starts a call for Working Group Adoption of

> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-ques
> tion-mark-03.html

ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, Administration, 
and Maintenance" (OAM) is used currently & historically in the IETF and intends 
to consolidate unambiguous and protocol agnostic terminology for OAM. The 
summary includes descriptions of narrower semantics introduced by added 
qualifications the term OAM and a list of common capabilities that can be found 
in nodes processing OAM packets.

The chairs acknowledge a positive poll result at IETF119, but there has not 
been much discussion on the list yet. We would like to gather feedback from the 
WG if there is interest to further contribute and review. As a potential 
enabler for discussions, this call will last three weeks.

Please reply with your support and especially any substantive comments you may 
have.


For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


smime.p7s
Description: S/MIME Cryptographic Signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Michael Richardson]

I read whaaat-question-mark a few weeks ago, and I never noticed the obtuse
filename last time.   I think the document is useful.  I would wish that it
might give ANIMA's ACP a clear name... we would up with "Virtual In-Band OAM"
which I think nobody was happy about (but was least hated).

Once adopted, please give it a sane filename.


--
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]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Justin Iurman]

Support adoption. I think this document is *very* useful (speaking as an 
IOAM contributor in ippm).


Cheers,
Justin

On 4/10/24 13:05, Henk Birkholz wrote:

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html


ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, 
Administration, and Maintenance" (OAM) is used currently & historically 
in the IETF and intends to consolidate unambiguous and protocol agnostic 
terminology for OAM. The summary includes descriptions of narrower 
semantics introduced by added qualifications the term OAM and a list of 
common capabilities that can be found in nodes processing OAM packets.


The chairs acknowledge a positive poll result at IETF119, but there has 
not been much discussion on the list yet. We would like to gather 
feedback from the WG if there is interest to further contribute and 
review. As a potential enabler for discussions, this call will last 
three weeks.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

___
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

Re: [OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Carlos Pignataro]

Thank you, Henk.

I support adoption of this document (as a co-author).

As spelled out in the Acknowledgements of this document, its genesis
started in this very mailing list with a need for clarification that seemed
deja vu.

As such, I feel updating RFC 6291 will take clarity to a next level.

Thanks,

Carlos.

On Wed, Apr 10, 2024 at 7:06 AM Henk Birkholz 
wrote:

> Dear OPSAWG members,
>
> this email starts a call for Working Group Adoption of
>
> >
> https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html
>
> ending on Thursday, May 2nd.
>
> As a reminder, this I-D summarizes how the term "Operations,
> Administration, and Maintenance" (OAM) is used currently & historically
> in the IETF and intends to consolidate unambiguous and protocol agnostic
> terminology for OAM. The summary includes descriptions of narrower
> semantics introduced by added qualifications the term OAM and a list of
> common capabilities that can be found in nodes processing OAM packets.
>
> The chairs acknowledge a positive poll result at IETF119, but there has
> not been much discussion on the list yet. We would like to gather
> feedback from the WG if there is interest to further contribute and
> review. As a potential enabler for discussions, this call will last
> three weeks.
>
> Please reply with your support and especially any substantive comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> ___
> 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

[OPSAWG]  WG Adoption Call for draft-pignataro-opsawg-oam-whaaat-question-mark-03

[Henk Birkholz]

Dear OPSAWG members,

this email starts a call for Working Group Adoption of


https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html


ending on Thursday, May 2nd.

As a reminder, this I-D summarizes how the term "Operations, 
Administration, and Maintenance" (OAM) is used currently & historically 
in the IETF and intends to consolidate unambiguous and protocol agnostic 
terminology for OAM. The summary includes descriptions of narrower 
semantics introduced by added qualifications the term OAM and a list of 
common capabilities that can be found in nodes processing OAM packets.


The chairs acknowledge a positive poll result at IETF119, but there has 
not been much discussion on the list yet. We would like to gather 
feedback from the WG if there is interest to further contribute and 
review. As a potential enabler for discussions, this call will last 
three weeks.


Please reply with your support and especially any substantive comments 
you may have.



For the OPSAWG co-chairs,

Henk

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg