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

[Carlos Pignataro]

Hi, Henk,

Closing the loop, we have done it this way. The delta in the wg draft 
between-00 and-01 
<https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-oam-characterization-00=draft-ietf-opsawg-oam-characterization-01=--html>
 addresses all discussion thus far as part of the adoption call.

Thanks,

Carlos.

> On May 10, 2024, at 8:42 AM, Henk Birkholz  wrote:
> 
> Hi Carlos,
> hi Adrian,
> 
> please do it the other way around ☺️
> 
> The chairs ask the authors to first rename 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03 to 
> draft-ietf-opsawg-oam-characterization-00, keeping the content as is, and 
> resubmit. And then post a -01 that addresses all discussion so far, as these 
> represent WG feedback already.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> On 09.05.24 03:08, Carlos Pignataro wrote:
>> Thank you, Henk, for the descriptive and thorough wrap of this adoption call.
>> Like Adrian, I'm also inclined to align with your conclusions, including:
>>  * "draft-ietf-opsawg-oam-characterization" WFM -- even when it is much
>>_less_ expressive than the original, IMO ;-)
>>  * As the other one of the editors, ofc more than happy to commit to,
>>seek, and follow the WG on the 'pro-active alignment'.
>>(understanding we are at a starting point in which the relevant
>>lexicon is 'reactively misaligned', or otherwise we would not need
>>this draft.)
>> Net-net: All sounds good with thanks!
>> I can post a rev++ addressing all discussion thus far, and then an unchanged 
>> draft-ietf-opsawg-...-00
>> Thanks!
>> Carlos.
>> On Wed, May 8, 2024 at 4:14 AM Adrian Farrel > <mailto:adr...@olddog.co.uk>> wrote:
>>Thanks Henk,
>>Apologies for the fatuous original name of this draft (but it worked
>>to get everyone's attention ;-)
>>- Yes, your suggested new name works for me.
>>- Since you ask, as one of the editors, I commit to a "pro-active
>>alignment", making changes as requested by the WG, and paying
>>attention to any sources of similar terminology pointed out to us.
>>Ciao,
>>Adrian
>>-Original Message-
>>From: Henk Birkholz 
>>Sent: 08 May 2024 08:50
>>To: OPSAWG mailto:opsawg@ietf.org>>
>>Subject: [OPSAWG]Re:  WG Adoption Call for
>>draft-pignataro-opsawg-oam-whaaat-question-mark-03
>>Dear OPSAWG members,
>>this email concludes the 1st call for Working Group Adoption for
>>draft-pignataro-opsawg-oam-whaaat-question-mark-03.
>>We received a healthy number of replies, including a good discussion
>>about "yet another set of terminology" and its intrinsic
>>usefulness/feasibility in the IETF. A good example reflecting the
>>overall discussion is the existing terminology established in the
>>DetNet
>>WG and published in RFC 9551.
>>The chairs discussed the inputs and comments and believe this work
>>to be
>>feasible to be adopted as a working group I-D. This believe includes
>>the
>>expectation that no inconsistencies are introduced by this work and the
>>authors, editors, and contributors commit to a pro-active alignment
>>(scope and relationship of terms and their use in the respective
>>ecosystems) with other existing bodies of work that is brought to
>>attention in OPSAWG or otherwise.
>>Typically, we would now ask to rename and resubmit as is. Alas,
>>there is
>>the inconsistency between draft name and draft title. Some concern
>>about
>>that naming was raised during the WGLC. While the draft name was fine
>>for the individual submission, the chairs tend to agree that a more
>>expressive draft name would benefit the work. Could the authors please
>>work with the WG to come up with a better draft name? We can kick this
>>off with a proposal from chairs: how about
>>draft-ietf-opsawg-oam-characterization? Please bash, so we can move
>>forward. The chairs assume that this naming exercise can be resolved
>>quickly.
>>For the OPSAWG co-chairs,
>>Henk
>>On 10.04.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
>>  
>> <https://www.ietf.org/archive/id/draft-pignataro-opsawg-oam-whaaat-question-mark-03.html>
>>   

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

[Carlos Pignataro]

:-)

Henk, just submitted a draft-ietf-opsawg-oam-characterization-00 unchanged 
(except for filename and version) from the individual -03.

After approved, happy to submit a 01 with all the wg discussion captured and 
addressed.

Thanks,

Carlos.

> On May 10, 2024, at 9:08 AM, Henk Birkholz  wrote:
> 
> FYI, I found the I-D Action notif. My intricate web of shiny sieve filters is 
> to blame (which unfortunately inhibits me from shifting blame from me to 
> mailman anymore. Mailman is fine).
> 
> On 10.05.24 15:03, Henk Birkholz wrote:
>> Oh I see, DT tells me it is at -05 already.
>> Well, there was no notification on i-d-annou...@ietf.org AFAICS (but there 
>> were some mailman transition snafus recently, so I'll just account that 
>> under the German expression "tja"). I'd have commented on a -04 submission, 
>> if I would have seen an email.
>> Nothing to worry about, though, and no need to hassle already busy 
>> Secretariat with that. Just submit -03 as the new -00 and replay the diff 
>> between -03 to -05 as a new diff from -00 to 01 and we are good.
>> As Joe just highlighted, any pending submission of 
>> draft-ietf-opsawg-oam-characterization-00 can be canceled - and I just did 
>> that. So you are good to go.
>> Viele Grüße,
>> Henk
>> On 10.05.24 14:46, Adrian Farrel wrote:
>>> Hmmm, did Carlos jump the gun? Don't you hate enthusiastic people?
>>> 
>>> If so, do you want us to undo the changes? Options would be:
>>> - Ask the Secretariat to unpost the latest revision
>>> - Post a change-back version of the draft
>>> 
>>> Alternative is that "we" suck it up.
>>> - You post email to say, all changes made addressed only the adoption poll 
>>> comments
>>> - You accept the adoption and we follow up per Carlos' plan
>>> 
>>> Let us know.
>>> 
>>> Cheers,
>>> 
>>> A
>>> 
>>> 
>>> -Original Message-
>>> From: Henk Birkholz 
>>> Sent: 10 May 2024 13:43
>>> To: Carlos Pignataro ; adr...@olddog.co.uk
>>> Cc: OPSAWG 
>>> Subject: Re: [OPSAWG]Re:  WG Adoption Call for 
>>> draft-pignataro-opsawg-oam-whaaat-question-mark-03
>>> 
>>> Hi Carlos,
>>> hi Adrian,
>>> 
>>> please do it the other way around ☺️
>>> 
>>> The chairs ask the authors to first rename
>>> draft-pignataro-opsawg-oam-whaaat-question-mark-03 to
>>> draft-ietf-opsawg-oam-characterization-00, keeping the content as is,
>>> and resubmit. And then post a -01 that addresses all discussion so far,
>>> as these represent WG feedback already.
>>> 
>>> 
>>> For the OPSAWG co-chairs,
>>> 
>>> Henk
>>> 
>>> On 09.05.24 03:08, Carlos Pignataro wrote:
>>>> Thank you, Henk, for the descriptive and thorough wrap of this adoption
>>>> call.
>>>> 
>>>> Like Adrian, I'm also inclined to align with your conclusions, including:
>>>> 
>>>>* "draft-ietf-opsawg-oam-characterization" WFM -- even when it is much
>>>>  _less_ expressive than the original, IMO ;-)
>>>>* As the other one of the editors, ofc more than happy to commit to,
>>>>  seek, and follow the WG on the 'pro-active alignment'.
>>>>  (understanding we are at a starting point in which the relevant
>>>>  lexicon is 'reactively misaligned', or otherwise we would not need
>>>>  this draft.)
>>>> 
>>>> Net-net: All sounds good with thanks!
>>>> 
>>>> I can post a rev++ addressing all discussion thus far, and then an
>>>> unchanged draft-ietf-opsawg-...-00
>>>> 
>>>> Thanks!
>>>> 
>>>> Carlos.
>>>> 
>>>> On Wed, May 8, 2024 at 4:14 AM Adrian Farrel >>> <mailto:adr...@olddog.co.uk>> wrote:
>>>> 
>>>>  Thanks Henk,
>>>> 
>>>>  Apologies for the fatuous original name of this draft (but it worked
>>>>  to get everyone's attention ;-)
>>>> 
>>>>  - Yes, your suggested new name works for me.
>>>> 
>>>>  - Since you ask, as one of the editors, I commit to a "pro-active
>>>>  alignment", making changes as requested by the WG, and paying
>>>>  attention to any sources of similar terminology pointed out to us.
>>>> 
>>>>  Ciao,
>>>>  

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

[Carlos Pignataro]

Correct — the wg version is not approved. 

> On May 10, 2024, at 8:58 AM, Joe Clarke (jclarke)  wrote:
> 
> Doesn’t look like Henk approved the submission yet (and I did not).  So we 
> can cancel this submission, and you can repost.
>  
> Joe
>  
> From: Adrian Farrel mailto:adr...@olddog.co.uk>>
> Date: Friday, May 10, 2024 at 08:47
> To: 'Henk Birkholz'  <mailto:henk.birkholz@ietf.contact>>, 'Carlos Pignataro'  <mailto:cpign...@gmail.com>>
> Cc: 'OPSAWG' mailto:opsawg@ietf.org>>
> Subject: [OPSAWG]Re:  WG Adoption Call for 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
> 
> Hmmm, did Carlos jump the gun? Don't you hate enthusiastic people?
> 
> If so, do you want us to undo the changes? Options would be:
> - Ask the Secretariat to unpost the latest revision
> - Post a change-back version of the draft
> 
> Alternative is that "we" suck it up.
> - You post email to say, all changes made addressed only the adoption poll 
> comments
> - You accept the adoption and we follow up per Carlos' plan
> 
> Let us know.
> 
> Cheers,
> 
> A
> 
> 
> -Original Message-
> From: Henk Birkholz  <mailto:henk.birkholz@ietf.contact>> 
> Sent: 10 May 2024 13:43
> To: Carlos Pignataro mailto:cpign...@gmail.com>>; 
> adr...@olddog.co.uk <mailto:adr...@olddog.co.uk>
> Cc: OPSAWG mailto:opsawg@ietf.org>>
> Subject: Re: [OPSAWG]Re:  WG Adoption Call for 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
> 
> Hi Carlos,
> hi Adrian,
> 
> please do it the other way around ☺️
> 
> The chairs ask the authors to first rename 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03 to 
> draft-ietf-opsawg-oam-characterization-00, keeping the content as is, 
> and resubmit. And then post a -01 that addresses all discussion so far, 
> as these represent WG feedback already.
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> On 09.05.24 03:08, Carlos Pignataro wrote:
> > Thank you, Henk, for the descriptive and thorough wrap of this adoption 
> > call.
> > 
> > Like Adrian, I'm also inclined to align with your conclusions, including:
> > 
> >   * "draft-ietf-opsawg-oam-characterization" WFM -- even when it is much
> > _less_ expressive than the original, IMO ;-)
> >   * As the other one of the editors, ofc more than happy to commit to,
> > seek, and follow the WG on the 'pro-active alignment'.
> > (understanding we are at a starting point in which the relevant
> > lexicon is 'reactively misaligned', or otherwise we would not need
> > this draft.)
> > 
> > Net-net: All sounds good with thanks!
> > 
> > I can post a rev++ addressing all discussion thus far, and then an 
> > unchanged draft-ietf-opsawg-...-00
> > 
> > Thanks!
> > 
> > Carlos.
> > 
> > On Wed, May 8, 2024 at 4:14 AM Adrian Farrel  > <mailto:adr...@olddog.co.uk>
> > <mailto:adr...@olddog.co.uk>> wrote:
> > 
> > Thanks Henk,
> > 
> > Apologies for the fatuous original name of this draft (but it worked
> > to get everyone's attention ;-)
> > 
> > - Yes, your suggested new name works for me.
> > 
> > - Since you ask, as one of the editors, I commit to a "pro-active
> > alignment", making changes as requested by the WG, and paying
> > attention to any sources of similar terminology pointed out to us.
> > 
> > Ciao,
> > Adrian
> > 
> > -Original Message-
> > From: Henk Birkholz  > <mailto:henk.birkholz@ietf.contact>>
> > Sent: 08 May 2024 08:50
> > To: OPSAWG mailto:opsawg@ietf.org> 
> > <mailto:opsawg@ietf.org>>
> > Subject: [OPSAWG]Re:  WG Adoption Call for
> > draft-pignataro-opsawg-oam-whaaat-question-mark-03
> > 
> > Dear OPSAWG members,
> > 
> > this email concludes the 1st call for Working Group Adoption for
> > draft-pignataro-opsawg-oam-whaaat-question-mark-03.
> > 
> > We received a healthy number of replies, including a good discussion
> > about "yet another set of terminology" and its intrinsic
> > usefulness/feasibility in the IETF. A good example reflecting the
> > overall discussion is the existing terminology established in the
> > DetNet
> > WG and published in RFC 9551.
> > 
> > The chairs discussed the inputs and comments and believe this work
> > to be
> > feasible to be adopted as a working group I-D. This believe includes
> >

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

[Carlos Pignataro]

Thank you, Henk, for the descriptive and thorough wrap of this adoption
call.

Like Adrian, I'm also inclined to align with your conclusions, including:

   - "draft-ietf-opsawg-oam-characterization" WFM -- even when it is much
   _less_ expressive than the original, IMO ;-)
   - As the other one of the editors, ofc more than happy to commit to,
   seek, and follow the WG on the 'pro-active alignment'. (understanding we
   are at a starting point in which the relevant lexicon is 'reactively
   misaligned', or otherwise we would not need this draft.)

Net-net: All sounds good with thanks!

I can post a rev++ addressing all discussion thus far, and then an
unchanged draft-ietf-opsawg-...-00

Thanks!

Carlos.

On Wed, May 8, 2024 at 4:14 AM Adrian Farrel  wrote:

> Thanks Henk,
>
> Apologies for the fatuous original name of this draft (but it worked to
> get everyone's attention ;-)
>
> - Yes, your suggested new name works for me.
>
> - Since you ask, as one of the editors, I commit to a "pro-active
> alignment", making changes as requested by the WG, and paying attention to
> any sources of similar terminology pointed out to us.
>
> Ciao,
> Adrian
>
> -Original Message-
> From: Henk Birkholz 
> Sent: 08 May 2024 08:50
> To: OPSAWG 
> Subject: [OPSAWG]Re:  WG Adoption Call for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03
>
> Dear OPSAWG members,
>
> this email concludes the 1st call for Working Group Adoption for
> draft-pignataro-opsawg-oam-whaaat-question-mark-03.
>
> We received a healthy number of replies, including a good discussion
> about "yet another set of terminology" and its intrinsic
> usefulness/feasibility in the IETF. A good example reflecting the
> overall discussion is the existing terminology established in the DetNet
> WG and published in RFC 9551.
>
> The chairs discussed the inputs and comments and believe this work to be
> feasible to be adopted as a working group I-D. This believe includes the
> expectation that no inconsistencies are introduced by this work and the
> authors, editors, and contributors commit to a pro-active alignment
> (scope and relationship of terms and their use in the respective
> ecosystems) with other existing bodies of work that is brought to
> attention in OPSAWG or otherwise.
>
> Typically, we would now ask to rename and resubmit as is. Alas, there is
> the inconsistency between draft name and draft title. Some concern about
> that naming was raised during the WGLC. While the draft name was fine
> for the individual submission, the chairs tend to agree that a more
> expressive draft name would benefit the work. Could the authors please
> work with the WG to come up with a better draft name? We can kick this
> off with a proposal from chairs: how about
> draft-ietf-opsawg-oam-characterization? Please bash, so we can move
> forward. The chairs assume that this naming exercise can be resolved
> quickly.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> On 10.04.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
> To unsubscribe send an email to opsawg-le...@ietf.org
>
> ___
> OPSAWG mailing list -- opsawg@ietf.org
> To unsubscribe send an email to opsawg-le...@ietf.org
>
___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

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

[Carlos Pignataro]

{
  "emoji": "",
  "version": 1
}___
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

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

[Carlos Pignataro]

Henk,

Thanks! I am not aware of any IPR that pertains to 
draft-pignataro-opsawg-oam-whaaat-question-mark-03.

Best,

Carlos.

> On May 2, 2024, at 11:48 AM, Henk Birkholz  wrote:
> 
> Dear authors and contributors,
> 
> as a part of the adoption process, the chairs would also like to issue a 
> first IPR call on the content of adoption candidates (there will also be a 
> second IPR call after successful WGLC).
> 
> Please respond on-list as to whether or not you are aware of any IPR that 
> pertains to draft-pignataro-opsawg-oam-whaaat-question-mark-03.
> 
> If you are aware of IPR, please also indicate whether or not this has been 
> disclosed per IETF IPR rules (see RFCs 3669, 5378, and 8179).
> 
> 
> For the OPSAWG co-chairs,
> 
> Henk
> 
> p.s. today is a good day to respond to the 
> draft-pignataro-opsawg-oam-whaaat-question-mark-03 WG adoption call, if you 
> have not done so yet



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

[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

[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 <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 <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 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 add

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

[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

[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

Re: [OPSAWG] [IVY] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

Thank you, Jan! I appreciate the clarity and thorough explanation.

How is this problem statement you list below (my paraphrasing for
simplicity, please correct as needed):
   (1) "devices can report their energy and/or power usage"
   (2) "work belongs / is spread across multiple WGs and it is hard to
track")

Different than
   (1) scope of e-impact,
   (2) action that the IAB e-impact Program leads took at the interim [1],
to "Updating datatracker with all related drafts on this topic. And a wiki
page with drafts on this topic, along with status, next steps, etc."

Thanks!

[1]
https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/slides-interim-2024-eimpact-02-sessa-chair-slides-01

On Tue, Mar 26, 2024 at 5:46 AM Jan Lindblad (jlindbla) 
wrote:

> Carlos, all,
>
> I'm confused by this bullet point:
>
> *•  next steps? E.g. WG coordination/status, form a WG Design
> Team, call for a BOF?*
>
> Could you please clarify?
>
> I understood there's no WG (and hence no WG coordination nor status), in
> favor of the IAB Program. There cannot be a WG Design Team without a WG. I
> cannot find "design team" or 'BOF" (WG forming or not?) in the minutes of
> eimpact meetings ,
> maybe I missed it.
>
> Is this an effort parallel to eimpact or a shadow meeting?
>
>
> Since those were my words, maybe I should try to explain what they mean.
>
> There are a number of us IETF participants, from a rather long list of
> equipment providers as well as operators, that are working on solving very
> concrete and current issues with respect to energy management in network
> equipment. For example, we have noted that most devices can report their
> energy and/or power usage, but they all do that in different ways and with
> different precision. We see a real need to standardize this, in order to
> realize use cases many operators are asking for, somewhat urgently.
>
> In the bullet point above, the "WG coordination/status" intended to let
> everyone chime in with the list of relevant ongoing work they were aware
> of. As expected, we noted that the work we have in mind is currently spread
> out across half a dozen IETF working groups, so it's not easy to track or
> get an overview. The "form a WG Design Team" point meant to discuss the
> interest in the formation of a design team in an existing WG, such as
> OPSAWG. Some WGs have very wide charters, and therefore forming design
> teams around particular areas might be an effective way to progress. The
> "call for a BOF" point was there to gauge the interest in forming a new WG
> with a fairly narrow scope to progress some of the work, especially around
> management aspects of network equipment, such as common YANG modules or
> collection framework principles. Most people on the side meeting seemed to
> favor a BOF as the best way to progress this work. This conclusion or
> initiative is not coming out of IAB or E-impact.
>
> In this thread, there was some discussion around energy aware routing (and
> other protocol updates), and whether that would be a fruitful avenue for
> IETF work. While I'm not precluding that from the agenda at some point in
> the future, such topics have been absent from the discussions in any of the
> existing WGs, as far as I have seen (well, maybe CATS, ALTO and TVR have
> occasionally almost touched the subject), and certainly also in the design
> teams/BOFs discussions I have participated in so far. The focus has been on
> basic standardization of telemetry collection, metering and basic
> management that pretty much all devices already do, just in vendor specific
> ways.
>
> Best Regards,
> /jan
>
>
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

g list to e-impact, and other places where
>related discussions have been taking place, so that others can join.
>3. To create a github location where we can reference drafts and
>collecting work on a BOF proposal and draft charter for the WG (which as I
>stated above, should be narrowly scoped to only the work that is well
>understood and achievable in the short term).  If I can get this under the
>IETF github space, great, otherwise I can host a personal github.  I’m
>already checking with Mahesh on the feasibility of the github location
>being IETF hosted.
>4. Once the mailing list is up and running, the next step is to
>arrange a few virtual meetings to try and gain consensus on the proposed
>initial scope of the WG, and to start reviewing and pulling together the
>BOF proposal, and charter text.
>5. To submit a BOF request for IETF 120.  The key dates being:
>   1. Warn the IESG and Secretariat that we are hoping for a BOF by 22
>   nd April (note Mahesh is already aware and this has already been
>   informally flagged to the IESG)
>   2. Get the initial BOF submission in before 5th May
>   3. Refine the BOF proposal based on feedback received, and update
>   by 7th June
>   4. 14th June, we hear back whether the BOF has been approved for
>   IETF 120
>   5. Continue prepping slides, etc, for the BOF, running up to early
>   July
>6. In my experience, despite it being 4 months between IETF meetings,
>the time invariably disappears quickly, so I think that we need to
>frontload the BOF preparation effort to achieve consensus at IETF 120 for
>creating a working group.
>
>
> Anyone else in the side meeting, please feel free to add anything that I
> have missed, or correct me, if I have misrepresented anything.
>
> Carlos, hopefully you are also interested in participating in these
> efforts.  If you have any feedback on the planned approach I would be glad
> to hear it.
>
> Regards,
> Rob
>
>
>
> *From: *OPSAWG  on behalf of Carlos Pignataro <
> cpign...@gmail.com>
> *Date: *Monday, 25 March 2024 at 12:01
> *To: *Marisol Palmero Amador (mpalmero)  40cisco@dmarc.ietf.org>
> *Cc: *opsawg@ietf.org , e-imp...@ietf.org <
> e-imp...@ietf.org>, inventory-y...@ietf.org ,
> Alexander Clemm , Alberto Rodriguez-Natal (natal) <
> na...@cisco.com>, Ron Bonica , Mahesh Jethanandani <
> mjethanand...@gmail.com>, Ali Rezaki (Nokia) ,
> Suresh Krishnan (sureshk) , Jari Arkko <
> jari.ar...@gmail.com>
> *Subject: *Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage
> example
> +Jari
>
> Hello,
>
> *Suresh, Jari,*
>
> I'm confused by this bullet point:
> *•  next steps? E.g. WG coordination/status, form a WG Design
> Team, call for a BOF?*
>
> Could you please clarify?
>
> I understood there's no WG (and hence no WG coordination nor status), in
> favor of the IAB Program. There cannot be a WG Design Team without a WG. I
> cannot find "design team" or 'BOF" (WG forming or not?) in the minutes of
> eimpact meetings <https://datatracker.ietf.org/program/eimpact/meetings/>,
> maybe I missed it.
>
> Is this an effort parallel to eimpact or a shadow meeting?
>
> *Poweff authors,*
>
> Is Poweff still a Cisco-only effort, as recorded in
> https://youtu.be/m4vpThE5K9c?feature=shared=3534? Verbatim youtube
> transcript:
>
> *Many of the um products uh that we have uh mainly in **Cisco** right we
> are still looking into multivendor and this will be really good for um the
> participants to um provide feedback how this H um standardization of the
> data model might impact in your network equipment but um*
>
>
> Thanks!
>
> Carlos.
>
> On Fri, Mar 15, 2024 at 1:30 PM Marisol Palmero Amador (mpalmero)
>  wrote:
>
> Dear all,
>
> We have booked a side meeting in Brisbone,  IETF #119
> *Thursday 9:00 am local time*.
> *Headline*: Power Metrics: concrete usage example
>
>
> Please see the *agenda* that we are proposing:
>
> •  Overview of ongoing sustainability work in IETF (everyone
> contributes)
> •  Brief presentation of sustainability insights/poweff
> updates, incl. look at a more concrete example
> •  Any other short updates?
> •  next steps? E.g. WG coordination/status, form a WG Design
> Team, call for a BOF?
>
>
> As we would like to leave time to discuss and review **next steps**, for
> the overview we propose not more than 20 min.
> As authors from specific drafts, please let me know which draft(s) you
> would like to review, we would like to make sure that we could fit them
> into the 20 min
>
> Safe travels, and have a nice weekend
>
> Marisol Palmero, on behalf of the authors of sustainability insights&
> poweff drafts
>
> ___
> 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] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

Hi, Rob,

Thanks again for the thoughtful responses -- please also see inline.

[Hi, Suresh, please find one small parenthetical note for you inline as
well]

On Tue, Mar 26, 2024 at 6:28 AM Rob Wilton (rwilton) 
wrote:

> Hi Carlos,
>
>
>
> Thanks for the comments.  I’ve provided some comments (RW) inline …
>
>
>
> *From: *Carlos Pignataro 
> *Date: *Monday, 25 March 2024 at 21:09
> *To: *Rob Wilton (rwilton) 
> *Cc: *Marisol Palmero Amador (mpalmero)  40cisco@dmarc.ietf.org>, Ops Area WG , E-Impact IETF
> , inventory-y...@ietf.org ,
> Alexander Clemm , Alberto Rodriguez-Natal (natal) <
> na...@cisco.com>, Ronald Bonica , Mahesh
> Jethanandani , Ali Rezaki (Nokia) <
> ali.rez...@nokia.com>, Suresh Krishnan (sureshk) ,
> Jari Arkko 
> *Subject: *Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage
> example
>
> Hi, Rob,
>
>
>
> Thanks for the comprehensive email, and for your desire to support the
> industry towards improved energy efficiency!
>
>
>
> RW: Great!  I think that at least our broader goals are aligned here,
> although you seem to disagree on the particular path that I’m pushing for.
> I’m hoping that we can manage to get alignment, working towards the common
> good.
>
>
>

Rather than disagreeing, I must say I am confused.

I imagine you are subscribed to e-impact as well, since some feedback
towards the lack of value of WG formation from participants was sent there
but not Cc'ed to Opsawg.


>
>
> My first reaction is that this direction seems counter to and in conflict
> with the conclusion and decisions from the IAB Program eimpact “interim”
> from just a month before:
>
> · See Chair Slides
> <https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/slides-interim-2024-eimpact-02-sessa-chair-slides-01>,
> that codified: "*Metrics – Push through the WGs*” (etc. etc.)
>
> · See Minutes
> <https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/minutes-interim-2024-eimpact-02-202402161500-00>,
> that captured: "*Suresh agreed and mentioned that the reason for having
> the drafts here is that people to get higher level view since all working
> groups need to have a sustainability angle*"
>
> RW: Sorry, I had a conflict and couldn’t attend the e-impact interim.  My
> previous understanding was based on when this was discussed between the
> IESG and IAB retreat last summer was that the IAB program was for more
> future looking working, and incubating ideas that were not yet ready to be
> standardized but any actual work would happen in IETF WGs.
>

No worries, that's why I included excepts from the proceedings.


>
>
> A second thought is that, while on the surface getting a couple of
> document with ‘green metrics’ is useful and might seem net-positive,
> knee-jerk reacting on tactics misaligned with strategy can further fragment
> the Eimpact work (which already can be characterized as ‘having a hard time
> finding itself’ with work from 2022 and no output).
>
>
>
> RW: Sorry, but I don’t really follow.  Why would standardizing metrics and
> power controls now impact the overall strategy?  This is perhaps where I
> see things quite differently.  I see this as a simple split between what we
> can standardize now, relatively quickly, starting to reap the benefits now
> vs spending a long time discussing what we plan to do before taking any
> action.
>

Sorry if I was not clear -- my point is that a top-down approach on
analyzing what focus areas / work areas have the largest e-impact seems
valuable yet bypassed. Metrics was a key topic from the beginning, and
clearly something to solve. There does not seem to be full alignment on
e-impact on what metrics are more important.


>
>
>
>
> There are clear risks like (1) believing that metrics/models are the
> ultimate goal of “eimpact/green’ work, while (as mentioned on eimpact)
> there’s no analysis of the most useful focus area, and (2) forgetting what
> Suresh wrote that many WGs need ‘green’, and this would separate work in a
> corner, as opposed to embedding and integrating it.
>
>
>
> RW: I don’t believe that metrics/models are the ultimate goal at all, but
> they do seem like a useful first step.  Further, the purpose of this
> proposed WG isn’t really to create new work, but to better corral the
> existing work that folks are already trying to get started within the IETF
> now, and as I see it, struggling to get traction.
>
>
>

That can be said about every piece of e-impact work. I appreciate and value
you take real action in pushing forward a subset of that which falls under
Opsawg. Really. Other ADs in other areas are not doing the same, which
would add t

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

Hi, Suresh,

Thanks for the response, and apologies for my delay!

Please find my follow-up inline below, and in the meantime, one additional
question to you -- context (my emphasis):

   - I seem to have gotten the impression, from your words and IAB program
   lead slides, that there was no eimpact-related meeting in Brisbane, and the
   goal was to push drafts through the respective WGs and not through a
   WG-forming BOF:
  - https://youtu.be/bfpuL1mkr3U?feature=shared=9646
  -
  
https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/slides-interim-2024-eimpact-02-sessa-chair-slides-01
 - "Metrics – *Push through the WGs*"
 - "Benchmarking scenario or methodology standardization – *BMWG*"
 - "Carbon-aware routing – *IRTF? TVR?*"
 - "Do an interim session on backcasting what we need to do"
  -
  
https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/minutes-interim-2024-eimpact-02-202402161500-00
  - "Suresh mentioned that the dispatch function is certainly in scope
 and depending on the readiness for engineering the work will
end up in the
 IETF or the IRTF. "
  - But then, you were proponent of a side-meeting
  - https://wiki.ietf.org/en/meeting/119/sidemeetings
  - "Power Metrics: concrete usage example", "mpalm...@cisco.com,
 jlind...@cisco.com, sure...@cisco.com"
 -  that said " (4) next steps? E.g. *WG coordination/status, form
 a WG Design Team, call for a BOF?*"
  - Even though the IAB slides on IETF119 say:
  - "Short term focus on metrics, benchmarking with dispatch to *relevant
  IETF WGs*"
  
https://datatracker.ietf.org/meeting/119/materials/slides-119-iabopen-chair-slides-00
  - "*No in-person program meetings at IETF-119* But feel free to join
  the program mailing list: e...@iab.org and e-imp...@iab.org"
  
https://datatracker.ietf.org/meeting/119/materials/slides-119-ietf-sessa-119-internet-architecture-board-iab-report-00


*The question*: Are you in favor of running e-impact dispatching work to
existing WGs (as you said), or having a new "green" WG (as proponent)?

Please find follow-up responses inline below:


On Mon, Mar 25, 2024 at 10:02 PM Suresh Krishnan (sureshk) <
sure...@cisco.com> wrote:

> Hi Carlos,
>
>   Since your message was sent to Rob, I will let him respond, but I wanted
> to chime on some things you said about the e-impact program.
>

Thanks for this -- the salutation did not imply exclusivity.


>
>
> >  On 3/25/24, 5:09 PM, "Carlos Pignataro" cpign...@gmail.com wrote:
>
> > …
>
> >  A second thought is that, while on the surface getting a couple of
> document with ‘green metrics’ is useful and might seem net-positive,
> knee-jerk reacting on tactics misaligned with strategy can further fragment
> the Eimpact work (which already can be characterized as ‘having a hard time
> finding itself’ with work from 2022 and no output).
>
>
>
> The e-impact program was created at the end of August 2023, barely seven
> months ago (and not 2022 as you mentioned). Announcement here:
>
>
>
> https://www.iab.org/announcements/eimpact-program/
>

You are absolutely right, and my mis-writing, with apologies. I meant (and
should have written) the IAB e-impact Workshop, which gave way to the IAB
e-impact Program -- in lieu of forming a WG.


>
>
> You seemed to want to run this program as a WG with set outputs. I had
> responded to you on list to mention that it was not
>
>
>
> https://mailarchive.ietf.org/arch/msg/e-impact/nq7_ToPvRjIm612NwonOqDL-3zI/
>

To be clear, I do not want to run this program -- that is up to the program
leads.

However, the e-impact program chair (i.e., lead) slides show the
acknowledged need for some management, akin a WG. Quoting from
https://datatracker.ietf.org/meeting/interim-2024-eimpact-02/materials/slides-interim-2024-eimpact-02-sessa-chair-slides-01
:
"
● Updating datatracker with all related drafts on this topic
● And a wiki page with drafts on this topic, along with status, next steps,
etc.
"


>
> Quoting relevant part of my mail above:
>
>
>
> “IAB programs don’t have milestones like WGs specifically because of the
> unclear nature of the space they are exploring. If you recall the initial
> meeting with the IAB regarding creation of the program that you
> participated in, this was something that was very clearly stated by various
> members of the IAB. If the work that needs to be done is clear it will be
> dispatched to a WG, an RG or if no relevant space exists to a BoF or
> proposed RG.”
>
>
>
> >  A third thought is that we had asked for a (broader and more
>

Re: [OPSAWG] draft-pignataro-opsawg-oam-whaaat-question-mark

[Carlos Pignataro]

Many thanks Thomas and Alex, both for the support, as well as for the useful 
suggestions.

Alex, “on-path” is much more descriptive than “in-band” for sure!

Thomas, Alex, will send an iteration of the draft incorporating the Node Type 
suggestion.

Thanks!

Carlos.

> On Mar 18, 2024, at 2:55 AM, Alex Huang Feng  
> wrote:
> 
> Dear Carlos and Adrian,
> 
> As I said in the chat during the OPSAWG meeting, I also support this document.
> I don’t have a lot of specific examples of how the terminology are confusing, 
> but I am co-authoring draft-ietf-opsawg-ipfix-on-path-telemetry where it 
> started as an inband telemetry protocol and then we were asked to change this 
> terminology to “on-path telemetry protocol”. 
> Also I haven’t been able to find a clear formal definition of “on-path 
> telemetry protocol”.
> 
> Thanks for the document,
> Alex
> 
>> On 18 Mar 2024, at 15:32, thomas.g...@swisscom.com wrote:
>> 
>> Dear Carlos and Adrian,
>>  
>> As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value 
>> that you are defining OAM terminology. This is much needed. Count me on the 
>> list of people who misused the term inband previously.
>>  
>> I would appreciate of you could add also OAM node type. As an example in RFC 
>> 9398 for IOAM the following types are defined
>>  
>> IOAM encapsulation node
>> IOAM transit node
>> IOAM decapsulation node
>>  
>> It would be very useful to have an OAM protocol agnostic terminology.
>>  
>> Best wishes
>> Thomas
>>  
>> ___
>> 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] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

iguration or YANG RPCs to influence and optimise power usage on network 
> devices.  Longer term energy efficiency and Green networking goals are 
> intended to be out of scope for the proposed WG’s initial charter, and should 
> continue to be discussed as part of the E-Impact IAB program.  The exact 
> scope of the charter would be worked out between the interested parties in 
> the coming weeks.
> 
> I’m happy to try and help this work gain traction within the IETF.  I 
> appreciate that several of the proponents for this work are also from Cisco, 
> but I have no vested interest other than trying to help the industry take 
> small steps that may help improve energy efficiency in networks (e.g., 
> reporting power usage, and as Tony suggests by selectively powering off ports 
> or linecards) to try and help mitigate some of the impacts of the Internet on 
> climate change.
> 
> To that end the proposed next steps from that side meeting were:
> 
> For me to request the creation of new open “green-bof” mailing list from 
> Mahesh (hopefully should be done over the next few days).
> I asked for, and received, permission to subscribe those who attended the 
> side meeting, but once created, I also intended to circulate the existence of 
> the mailing list to e-impact, and other places where related discussions have 
> been taking place, so that others can join.
> To create a github location where we can reference drafts and collecting work 
> on a BOF proposal and draft charter for the WG (which as I stated above, 
> should be narrowly scoped to only the work that is well understood and 
> achievable in the short term).  If I can get this under the IETF github 
> space, great, otherwise I can host a personal github.  I’m already checking 
> with Mahesh on the feasibility of the github location being IETF hosted.
> Once the mailing list is up and running, the next step is to arrange a few 
> virtual meetings to try and gain consensus on the proposed initial scope of 
> the WG, and to start reviewing and pulling together the BOF proposal, and 
> charter text.
> To submit a BOF request for IETF 120.  The key dates being:
> Warn the IESG and Secretariat that we are hoping for a BOF by 22nd April 
> (note Mahesh is already aware and this has already been informally flagged to 
> the IESG)
> Get the initial BOF submission in before 5th May
> Refine the BOF proposal based on feedback received, and update by 7th June
> 14th June, we hear back whether the BOF has been approved for IETF 120
> Continue prepping slides, etc, for the BOF, running up to early July
> In my experience, despite it being 4 months between IETF meetings, the time 
> invariably disappears quickly, so I think that we need to frontload the BOF 
> preparation effort to achieve consensus at IETF 120 for creating a working 
> group.
>  
> Anyone else in the side meeting, please feel free to add anything that I have 
> missed, or correct me, if I have misrepresented anything.
>  
> Carlos, hopefully you are also interested in participating in these efforts.  
> If you have any feedback on the planned approach I would be glad to hear it.
> 
> Regards,
> Rob
>  
>  
> From: OPSAWG mailto:opsawg-boun...@ietf.org>> on 
> behalf of Carlos Pignataro mailto:cpign...@gmail.com>>
> Date: Monday, 25 March 2024 at 12:01
> To: Marisol Palmero Amador (mpalmero)  <mailto:mpalmero=40cisco@dmarc.ietf.org>>
> Cc: opsawg@ietf.org <mailto:opsawg@ietf.org>  <mailto:opsawg@ietf.org>>, e-imp...@ietf.org <mailto:e-imp...@ietf.org> 
> mailto:e-imp...@ietf.org>>, inventory-y...@ietf.org 
> <mailto:inventory-y...@ietf.org>  <mailto:inventory-y...@ietf.org>>, Alexander Clemm  <mailto:a...@clemm.org>>, Alberto Rodriguez-Natal (natal)  <mailto:na...@cisco.com>>, Ron Bonica  <mailto:rbon...@juniper.net>>, Mahesh Jethanandani  <mailto:mjethanand...@gmail.com>>, Ali Rezaki (Nokia)  <mailto:ali.rez...@nokia.com>>, Suresh Krishnan (sureshk)  <mailto:sure...@cisco.com>>, Jari Arkko  <mailto:jari.ar...@gmail.com>>
> Subject: Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example
> 
> +Jari
>  
> Hello,
>  
> Suresh, Jari,
>  
> I'm confused by this bullet point:
> •  next steps? E.g. WG coordination/status, form a WG Design 
> Team, call for a BOF?
>  
> Could you please clarify?
>  
> I understood there's no WG (and hence no WG coordination nor status), in 
> favor of the IAB Program. There cannot be a WG Design Team without a WG. I 
> cannot find "design team" or 'BOF" (WG forming or not?) in the minutes of 
> eimpact meetings <https://datatracker.ietf.org/program/eimpact/meetings/>, 

Re: [OPSAWG] side meeting #119: Power Metrics: concrete usage example

[Carlos Pignataro]

+Jari

Hello,

*Suresh, Jari,*

I'm confused by this bullet point:

*•  next steps? E.g. WG coordination/status, form a WG Design
Team, call for a BOF?*

Could you please clarify?

I understood there's no WG (and hence no WG coordination nor status), in
favor of the IAB Program. There cannot be a WG Design Team without a WG. I
cannot find "design team" or 'BOF" (WG forming or not?) in the minutes of
eimpact meetings ,
maybe I missed it.

Is this an effort parallel to eimpact or a shadow meeting?

*Poweff authors,*

Is Poweff still a Cisco-only effort, as recorded in
https://youtu.be/m4vpThE5K9c?feature=shared=3534? Verbatim youtube
transcript:

*Many of the um products uh that we have uh mainly in Cisco right we are
still looking into multivendor and this will be really good for um the
participants to um provide feedback how this H um standardization of the
data model might impact in your network equipment but um*


Thanks!

Carlos.

On Fri, Mar 15, 2024 at 1:30 PM Marisol Palmero Amador (mpalmero)  wrote:

> Dear all,
>
>
>
> We have booked a side meeting in Brisbone,  IETF #119
>
> *Thursday 9:00 am local time*.
>
> *Headline*: Power Metrics: concrete usage example
>
>
>
>
>
> Please see the *agenda* that we are proposing:
>
>
>
> •  Overview of ongoing sustainability work in IETF (everyone
> contributes)
>
> •  Brief presentation of sustainability insights/poweff
> updates, incl. look at a more concrete example
>
> •  Any other short updates?
>
> •  next steps? E.g. WG coordination/status, form a WG Design
> Team, call for a BOF?
>
>
>
>
>
> As we would like to leave time to discuss and review **next steps**, for
> the overview we propose not more than 20 min.
>
> As authors from specific drafts, please let me know which draft(s) you
> would like to review, we would like to make sure that we could fit them
> into the 20 min
>
>
>
> Safe travels, and have a nice weekend
>
>
>
> Marisol Palmero, on behalf of the authors of sustainability insights&
> poweff drafts
>
>
> ___
> 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] draft-pignataro-opsawg-oam-whaaat-question-mark

[Carlos Pignataro]

Many thanks Thomas and Alex, both for the support, as well as for the useful 
suggestions.

Alex, “on-path” is much more descriptive than “in-band” for sure!

Thomas, Alex, will send an iteration of the draft incorporating the Node Type 
suggestion. (BTW, I think you meant rfc9197 or rfc9359 instead of rfc 9398?)

Thanks!

Carlos.

> On Mar 18, 2024, at 2:55 AM, Alex Huang Feng  
> wrote:
> 
> Dear Carlos and Adrian,
> 
> As I said in the chat during the OPSAWG meeting, I also support this document.
> I don’t have a lot of specific examples of how the terminology are confusing, 
> but I am co-authoring draft-ietf-opsawg-ipfix-on-path-telemetry where it 
> started as an inband telemetry protocol and then we were asked to change this 
> terminology to “on-path telemetry protocol”. 
> Also I haven’t been able to find a clear formal definition of “on-path 
> telemetry protocol”.
> 
> Thanks for the document,
> Alex
> 
>> On 18 Mar 2024, at 15:32, thomas.g...@swisscom.com wrote:
>> 
>> Dear Carlos and Adrian,
>>  
>> As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value 
>> that you are defining OAM terminology. This is much needed. Count me on the 
>> list of people who misused the term inband previously.
>>  
>> I would appreciate of you could add also OAM node type. As an example in RFC 
>> 9398 for IOAM the following types are defined
>>  
>> IOAM encapsulation node
>> IOAM transit node
>> IOAM decapsulation node
>>  
>> It would be very useful to have an OAM protocol agnostic terminology.
>>  
>> Best wishes
>> Thomas
>>  
>> ___
>> 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] draft-pignataro-opsawg-oam-whaaat-question-mark

[Carlos Pignataro]

Many thanks Thomas and Alex, both for the support, as well as for the useful 
suggestions.

Alex, “on-path” is much more descriptive than “in-band” for sure!

Thomas, Alex, will send an iteration of the draft incorporating the Node Type 
suggestion. (BTW, I think you meant rfc9197 or rfc9359 instead of rfc 9398?)

Thanks!

Carlos.

> On Mar 18, 2024, at 2:55 AM, Alex Huang Feng  
> wrote:
> 
> Dear Carlos and Adrian,
> 
> As I said in the chat during the OPSAWG meeting, I also support this document.
> I don’t have a lot of specific examples of how the terminology are confusing, 
> but I am co-authoring draft-ietf-opsawg-ipfix-on-path-telemetry where it 
> started as an inband telemetry protocol and then we were asked to change this 
> terminology to “on-path telemetry protocol”. 
> Also I haven’t been able to find a clear formal definition of “on-path 
> telemetry protocol”.
> 
> Thanks for the document,
> Alex
> 
>> On 18 Mar 2024, at 15:32, thomas.g...@swisscom.com wrote:
>> 
>> Dear Carlos and Adrian,
>>  
>> As the author of draft-ietf-opsawg-ipfix-on-path-telemetry, I care and value 
>> that you are defining OAM terminology. This is much needed. Count me on the 
>> list of people who misused the term inband previously.
>>  
>> I would appreciate of you could add also OAM node type. As an example in RFC 
>> 9398 for IOAM the following types are defined
>>  
>> IOAM encapsulation node
>> IOAM transit node
>> IOAM decapsulation node
>>  
>> It would be very useful to have an OAM protocol agnostic terminology.
>>  
>> Best wishes
>> Thomas
>>  
>> ___
>> 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] New I-D -> Guidelines for Charactering "OAM"

[Carlos Pignataro]

Dear Greg,

Please see inline as *CMP2*.

On Mon, Jan 22, 2024 at 2:56 PM Greg Mirsky  wrote:

> Dear Carlos,
>
> thank you for sharing your thoughts and responding to my notes. I have
> added follow-up notes and questions below under the GIM2>> tag. But before
> I go to the specific topics of our discussion, it is essential
>
to bring forward the question of not how the 'OAM' abbreviation is expanded
> but how we interpret it, whether in the expanded or abbreviated form.
>

*CMP2: Correct, that's what RFC6291 does.*
*CMP2: And as one of the authors of RFC6291 supported this proposal, I feel
we are on a useful path.*
*CMP2: That said, I'll try to provide some follow-ups, and will let others
on the list chime-in, as the discussion seems to be getting circularly
convoluted.*

 RFC 7276 <https://datatracker.ietf.org/doc/rfc7276/> in the Abstract gives
> the following explanation of the scope of OAM:
>
>   Operations, Administration, and Maintenance (OAM) is a general term
>
>   that refers to a toolset for fault detection and isolation and for
>
>   performance measurement.
>
> Hence, based on that definition, we can expect that an OAM toolset
> includes tools that use different methods classified in RFC 7799
>

*CMP2: I do not see the "hence". That RFC defines OAM toolsets, not
methods. Yes, those toolsets can use methods that use frameworks that use
principles. Those methods can be written in Italian as well, without a
"hence".*


> , i.e., active, passive, and hybrid. Of course, some operators might build
> their OAM toolsets only using mechanisms of the same type, i.e., only
> active or hybrid. But such choices don't make OAM active or passive. Thus,
> I suggest that the document clarify that and refer to "an active OAM
> method" rather than "active OAM" (and so on for other types).
>

*CMP2: The main goal is that we have overloaded how we categorize and
describe OAM, and this proposal tackles the "[qualifier] OAM".*
*CMP2: Please note that RFC7799 gives two definitions to Hybrid, and thus
some disambiguation is already needed.*
*CMP2: To me, your suggestion could be useful but seems an Update to
RFC7799 what you are asking.*

>
> Regards,
>
> Greg
>
> On Tue, Jan 16, 2024 at 2:41 PM Carlos Pignataro 
> wrote:
>
>> 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 

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

[Carlos Pignataro]

ty
> 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 sources?
> > IEEE 802.1Q 2014 uses in-band/out-of-band
> >> 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).
> >> GIM>> The definition is for active OAM. Hybrid OAM, which, as I
> understand
> > it, is referr

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"

[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"

[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

[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

Re: [OPSAWG] Eric Rescorla's Discuss on draft-mm-wg-effect-encrypt-17: (with DISCUSS and COMMENT)

[Carlos Pignataro (cpignata)]

> On Feb 8, 2018, at 5:17 AM, Randy Bush <ra...@psg.com> wrote:
> 
>>> Unfortunately, the fundamental concern that motivated my DISCUSS
>>> remains: I do not believe that this document matches the consensus
>>> of the IETF community.
>> That's an interesting claim.
>> If the process has not been followed, this requires facts as opposed
>> to "believes".
>> We should make sure to make a distinction between the IETF community
>> views and your own views.

Eric: I’m also interested in understanding your claim regarding consensus — can 
you please expand?

> 
> 1984 7258

"  Making
   networks unmanageable to mitigate PM is not an acceptable outcome,
   but ignoring PM would go against the consensus documented here.  An
   appropriate balance will emerge over time as real instances of this
   tension are considered.”

> 7625 ... and dogged comments on this draft; though some of us
> have grew a bit weary of the denial game and allowed ourselves to be
> shut up.

Or a DDoS against the ideas on this document?

> 
> randy
> 

—
Carlos Pignataro, car...@cisco.com

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis.”


> ___
> 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] Adding Joe Clarke as a chair.

[Carlos Pignataro (cpignata)]

Congratulations Joe, this is excellent news for OPsAWG!

On May 24, 2017, at 7:45 AM, Warren Kumari 
> wrote:

Hi all,

Benoit and I have been discussing this for a while, and we'd like to announce 
that we are adding Joe Clarke as an OpsAWG chair.

Joe has both operations and management experience, and will be a good addition 
to help chair the OPsAWG WG.

W

--
I don't think the execution is relevant when it was obviously a bad idea in the 
first place.
This is like putting rabid weasels in your pants, and later expressing regret 
at having chosen those particular rabid weasels and that pair of pants.
   ---maf
___
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 poll for In-Situ OAM drafts

[Carlos Pignataro (cpignata)]

Hi, Linda,

Moving the discussion to i...@ietf.org<mailto:i...@ietf.org>, other aliases to 
Bcc.

Please see inline.

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Jan 30, 2017, at 4:39 PM, Linda Dunbar 
<linda.dun...@huawei.com<mailto:linda.dun...@huawei.com>> wrote:

Alvaro,

It is great to see a mailing list being created for interested parties to 
discuss.

Question on the objectives of the mailing list:
In-situ OAM (IOAM) provides real-time telemetry of individual data packets and 
flows. It is based on telemetry information which is embedded along within data 
packets

So the key differences between In-situ OAM and BFD is that BFD uses synthetic 
data packets (i.e. dedicated OAM packets), whereas In-situ OAM are encoded into 
the user data packets. Correct?


The key difference is about what the protocol is used for and not in the how. 
You quoted “provides real-time telemetry of individual data packets and flows”, 
and that has no intersection with BFD, which provides liveness verification on 
an end-to-end basis.

Does it mean “Telemetry information that doesn’t have user payload” is out of 
the scope?


The goal of the creation of the new list and early threads is to discuss the 
charter, including its scope.

Thanks!

— Carlos.

Thanks, Linda

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Alvaro Retana 
(aretana)
Sent: 2017年1月30日 14:10
To: Bert Wijnen (IETF) <berti...@bwijnen.net<mailto:berti...@bwijnen.net>>; 
rtg-...@ietf.org<mailto:rtg-...@ietf.org>
Cc: opsawg@ietf.org<mailto:opsawg@ietf.org>; 
opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Bert:

As Frank indicated, the new i...@ietf.org<mailto:i...@ietf.org> list will be 
used for discussion: https://www.ietf.org/mailman/listinfo/ioam

If you have suggestions about possible Chairs, or want to volunteer, please let 
me know.

The current intent is to charter a WG by IETF 98.  Given the discussions on 
this list, we believe there is interest in the problem space and in defining a 
solution.

Thanks!!

Alvaro.

On 1/24/17, 4:00 AM, "Bert Wijnen (IETF)" 
<berti...@bwijnen.net<mailto:berti...@bwijnen.net>> wrote:

- Where will you send the proposed charter for discussion?
   Both OPS and RTG area mailing lists (or maybe OPSAWG instead of OPS)?
- Are you gonna do a call for volunteers to co-chair the WG?
- It sounds like you are not gonna do a BOF first, right?
   that is OK with me.

___
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 poll for In-Situ OAM drafts

[Carlos Pignataro (cpignata)]

Thanks again, Tianran and Adrian.

Please find a couple additional comments inline.

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Dec 16, 2016, at 1:28 AM, Zhoutianran 
<zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> wrote:

Hi Adrian,

Thanks for your comments. The poll is to collect various opinions from the WG.
I have some preliminary reply in line.

Best,
Tianran
From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: Friday, December 16, 2016 6:09 AM
To: Zhoutianran; opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: RE: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi Tianran,

I'm fairly much in agreement that this is a topic that should be worked on in 
the IETF.

>> Agreed.


+1.

I am somewhat nervous about the overlap between this and OAM work undertaken in 
a number of working groups chiefly in the Routing Area, and I hope there can be 
some careful coordination.

>> I also asked the authors about this question. Especially there is an overlay 
>> OAM design team in routing area. Their drafts and outputs show they also 
>> want to standardize a common OAM header for various transport.


It is indeed a fair question and I appreciate seeing it explicitly. The common 
OAM header for OAM probes on disparate transports seems orthogonal to the 
in-situ OAM (iOAM) requirement and approach. The in-situ OAM work also has code 
at https://fd.io/.

My feeling is that we should start with the requirements draft at once. I am 
pretty sure that once inside the WG we can quickly get important input from 
operators and bash it into shape.

I think that the data format document may be close to being ready for adoption, 
but I think that there are some largish wrinkles that could do with being 
ironed out first. Chief among these are:
- A thorough investigation of the numeric impact on the amount of data that can 
be sent. In other words, the change to the effective MTU
- The Abstract specifically says how encapsulation will be managed for IPv6. 
Not only does the document later say that this is out of scope, but the 
mechanism proposed in the Abstract is one that worries me.
- I don't like that the OAM only works if every node on the path supports it. I 
would like for us to achieve some form of comfortable b/w compatibility.
- As an "experiment" I would like to understand how the experiment would be 
conducted and what would constitute success

Why do I think these points should be addressed before adoption? I am worried 
that without looking at them first there will be an assumption that the 
document's is already set and 'radical' changes cannot be made. I think that my 
points can be handled by:
- Adding a section on "MTU Concerns" that provides a pointer to the relevant 
part of the requirements draft, and offers up some basic maths on the expected 
size of OAM information in a packet.
- Removing the offending text from the Abstract
- Adding a section on b/w compatibility (maybe just as a placeholder) and 
cleaning up the text that requires every node on the path to support in-situ 
OAM.
- Adding a section scoping the experiment that the authors think they want the 
WG to perform.

>> Thanks for your comments and suggestions.

Indeed, thanks again Adrian.


As for the proof of transit work, I think it is a bit of a mess at the moment. 
It seems to be growing new approaches and options, each with drawbacks and 
issues. And I'm not clear on the objectives.  This might be handled as with the 
previous document by describing and scoping the experiment, but as currently 
written, it would appear that the intention is to research a number of 
potential approaches to proof of transit rather than to experiment with a 
particular protocol solution, and that might make the document better suited to 
the NMRG. So I would like to apply a bit more caution to that document.
>> In my opinion, the objective of the POT draft is to demonstrate a solution 
>> for an applicable use case with in-situ OAM.

That is correct.


In any event, during the process of adoption, do you think you could cut down 
the front page authors to a manageable number so that we know who is editing 
the work going forward?

>> I think 5 authors is preferred. But at least the authors can add “Ed.” tag 
>> after the editors.


This is solvable and we take guidance.

Thanks,

— Carlos.

Thanks,
Adrian

From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Zhoutianran
Sent: 07 December 2016 06:37
To: opsawg@ietf.org<mailto:opsawg@ietf.org>
Cc: opsawg-cha...@ietf.org<mailto:opsawg-cha...@ietf.org>
Subject: [OPSAWG] WG adoption poll for In-Situ OAM drafts

Hi All,

In Seoul, we got enough interest on the In Situ OAM work and positive resp

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

[Carlos Pignataro (cpignata)]

Hi Adrian,

Interesting thoughts, please see inline.

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Dec 15, 2016, at 5:09 PM, Adrian Farrel 
<adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote:

Hi Tianran,

I'm fairly much in agreement that this is a topic that should be worked on in 
the IETF.

I am somewhat nervous about the overlap between this and OAM work undertaken in 
a number of working groups chiefly in the Routing Area, and I hope there can be 
some careful coordination.


I believe the potentially perceived overlap is not real, and I’m not nervous 
about it.

I understand the word “OAM” is overlapping with work happening elsewhere inside 
and outside the IETF. However, when we look right underneath the thin surface, 
the overlap quickly tends to zero.

Looking at the OAM work in the RTG Area, and in particular the RTG-AD chartered 
Design Team, it seems to extend as far as defining an OAM protocol indication 
header pre-pended to specific OAM probe packets, modeled after the MPLS G-ACh.

On the other hand, the Operators and HW/SW Vendors from 
draft-brockners-inband-oam-requirements narrowscope the problem/opportunity 
area quite early:

Abstract

   This document discusses the motivation and requirements for including
   specific operational and telemetry information into data packets
   while the data packet traverses a path between two points in the
   network.  This method is referred to as "in-situ" Operations,
   Administration, and Maintenance (OAM)

My read of this is that:
1. There’s no overlap.
2. The problem and solution spaces fall squarely within the scope at 
https://datatracker.ietf.org/wg/opsawg/charter/

My feeling is that we should start with the requirements draft at once. I am 
pretty sure that once inside the WG we can quickly get important input from 
operators and bash it into shape.


I agree, and would add that all these documents have received substantial input 
from operators, which is another reason for getting even more at opsawg.

I think that the data format document may be close to being ready for adoption, 
but I think that there are some largish wrinkles that could do with being 
ironed out first. Chief among these are:

I believe that these are four great pieces of input, which should be ironed out 
with WG input as a WG document. And that:

- A thorough investigation of the numeric impact on the amount of data that can 
be sent. In other words, the change to the effective MTU

as an adoption poll, this is an area that would use WG input once adopted.

- The Abstract specifically says how encapsulation will be managed for IPv6. 
Not only does the document later say that this is out of scope, but the 
mechanism proposed in the Abstract is one that worries me.

This is a quick fix. But yes, needs to be fixed :-)

- I don't like that the OAM only works if every node on the path supports it. I 
would like for us to achieve some form of comfortable b/w compatibility.

I would state this quite differently. iOAM does not stop working in a 
brownfield, or when only some nodes support it.

It is, as such, a backwards compatible approach, in which legacy nodes are 
transparent.

But for new features we need to have new code, and here a good thing is that 
there is running code.

- As an "experiment" I would like to understand how the experiment would be 
conducted and what would constitute success


The experiment is ongoing in FD.io<http://FD.io> and other places, and 
hopefully the IETF does not fall behind. But this does beg another question for 
the WG, which is regarding the best intended status, and we would like WG input 
for it.

Why do I think these points should be addressed before adoption? I am worried 
that without looking at them first there will be an assumption that the 
document's is already set and 'radical' changes cannot be made.

The question on adoption as you know is whether the document provides a solid 
basis as a starting point, not if it is fixed.

I think that my points can be handled by:
- Adding a section on "MTU Concerns" that provides a pointer to the relevant 
part of the requirements draft, and offers up some basic maths on the expected 
size of OAM information in a packet.
- Removing the offending text from the Abstract
- Adding a section on b/w compatibility (maybe just as a placeholder) and 
cleaning up the text that requires every node on the path to support in-situ 
OAM.
- Adding a section scoping the experiment that the authors think they want the 
WG to perform.

These seem to be all good areas to work on and add. And in fact would love to 
have your text on the MTU area.


As for the proof of transit work, I think it is a bit of a mess at the moment. 
It seems to be growing new approaches and options, each with drawbacks and 
issues. 

Re: [OPSAWG] WG adoption poll for In-Situ OAM drafts

[Carlos Pignataro (cpignata)]

Hi, Bert,

Please find a couple of follow-ups inline.

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Dec 14, 2016, at 9:48 AM, Bert Wijnen (IETF) 
<berti...@bwijnen.net<mailto:berti...@bwijnen.net>> wrote:

i am not sure if it is wise to adopt these 3 drafts as WG documents at this
point in time. At our WG session in Seoul, (when the WG chairs did a humm for
this in the session), I spoke up and stated that during the week in Seoul
there had been several presentations on inband OAM and Telemetry.

Would it be possible for you to share pointers to  (at least a few of the 
several) specific presentations and Internet-Drafts that overlap with or 
complement this work?

Note that the title of this documents was renamed to “In-Situ” (with thanks to 
Erik Nordmark for the suggestion) so as to not confuse with the IETF definition 
of “inband”.

And I suggested that it might be wise to first analyze what is available and
already used or tested. Once we know that, we might be in a much better
position to determine which type of "inband OAM" or "Telemetry" mechanism makes
most sense.


Since specific pointers on what’s available is a pre requisite to understanding 
the landscape, see above.

My understanding of the humm in the WG was" "is this sort of work interesting
and do we as a WG want to work on thos". To that question, the humm seemed to
indicate that we indeed do fond the work relevant and interesting and that we
as the OPSAWG want to work on it. I took notes during our OPSAWG session in
Seoul, and I wrote down on this topic of inband OAM (and that has been posted
as draft minutes as well):

 Open question as where to land this work (OPS or TSV) ??

 Joel: the actual OAM methods vary on what the transport is.

 BW: there seem to be various telemetry ideas being presented at various 
places
 (WGs, RGs) should we get a summary of what is being discussed before we
  adopt a particular approach

“Telemetry” is such a broadly defined word that invariably, there will be 
“telemetry work” everywhere. When we focus and narrow scope on the actual 
specifics of in-situ OAM, that does not seem to be the case anymore.

I do not believe the question is “does the WG want to take on telemetry”.

 Daniel King: yes we have seen some in SDNRG
 Benoit: how do you get the data off the devices
 That is still to be decided
 Chairs: humm for: do we i(OPSAWG) want to work on telemetry
 conclusion: yes we do
 Benoit: there is a pub/subscribe which is related

So I find it a step too quick/fast to now determine which documents to adopt
as WG document. Let us get (from someone versen in the field of inband OAM
and telemetry) get a summary of the various types of work that has already been
presented/proposed in the IETF (and possibly at other places) and let us then
see if we can choose a way forward.


I believe it is a fair request to compare and contrast and understand a broader 
picture. But that request expects more specifics than a perhaps someone else 
should do it.

Given the very specific requirements detailed by operators and vendors in 
draft-brockners-inband-oam-requirements-02.txt, the fact that we had to create 
a new descriptor (i.e., “In-Situ”) for this approach, and lack of specifics, it 
seems to me that the area of in-situ OAM is non-overlapping with other 
“telemetry" potential work elsewhere.

Thanks,

— Carlos.

Bert

On 07/12/2016 07:36, Zhoutianran wrote:
Hi All,



In Seoul, we got enough interest on the In Situ OAM work and positive response 
on related drafts.
So this email starts a formal poll for adoption the following I-Ds.



https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt



To be efficient, we have the poll for three I-Ds in one thread. But you can 
give your opinion on each of them. And the result is per
I-D.



The question is:
Do you think that the WG should adopt all or some of these drafts?



It would be helpful if you could indicate whether you have read the drafts. If 
"yes", would you like to review the drafts and help
to improve the drafts? If "no", it is important that you provide reasons.



This poll will last for two weeks, ending on Tuesday, December 20.


Thanks,
Tianran & Warren



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


___
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 poll for In-Situ OAM drafts

[Carlos Pignataro (cpignata)]

Hi, Tianran & Warren,

Yes, the WG should adopt these documents, and yes I have read them (and wrote 
some of them) [NB: I am a co-author]

These documents provide a well organized description of an 
operator-acknowledged problem space / opportunity space, and then follows to 
defining both data structures as well as mechanisms for proof of transit of a 
path or a service chain.

The previous two IETF meetings showed both interest and support for this work, 
as they are a collaborative product (operators + vendors).

To maximize the chances of interoperability, which clearly matters for 
real-time in-situ telemetry as an end-to-end solution, these Internet-Drafts 
would be best served by being hosted in the WG with deep knowledge, expertise, 
and experience in operational areas in a tech agnostic way, and continue as a 
product of an even tighter collaboration.

Looking at https://datatracker.ietf.org/wg/opsawg/charter/, these documents 
seem to squarely fall within scope. And in particular, this bar seems passed:

   The OPSAWG will undertake only work items that are proved to have at
   least a reasonable level of interest from the operators and users
   community and have a committed number of editors and reviewers. It is

Thanks,

—
Carlos Pignataro, car...@cisco.com<mailto:car...@cisco.com>

“Sometimes I use big words that I do not fully understand, to make myself sound 
more photosynthesis."

On Dec 7, 2016, at 1:36 AM, Zhoutianran 
<zhoutian...@huawei.com<mailto:zhoutian...@huawei.com>> wrote:

Hi All,



In Seoul, we got enough interest on the In Situ OAM work and positive response 
on related drafts.
So this email starts a formal poll for adoption the following I-Ds.



https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt



To be efficient, we have the poll for three I-Ds in one thread. But you can 
give your opinion on each of them. And the result is per I-D.



The question is:
Do you think that the WG should adopt all or some of these drafts?



It would be helpful if you could indicate whether you have read the drafts. If 
"yes", would you like to review the drafts and help to improve the drafts? If 
"no", it is important that you provide reasons.



This poll will last for two weeks, ending on Tuesday, December 20.

Thanks,
Tianran & Warren
___
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] MD Type attack (Was: Question regarding Proof of Transit draft)

[Carlos Pignataro (cpignata)]

Hi Tal,

> On Jul 20, 2016, at 12:09 PM, Tal Mizrahi <ta...@marvell.com> wrote:
> 
> Hi Carlos,
> 
> It all goes back to the threat model; which threats you want to address, and 
> which ones you don't.
> 
> The way I see it, roughly speaking there are 3 classes of threats (there ae 
> probably other threats, but these are the basic ones):
> - Misroute / misconfiguration (not a security attack).
> - Attacker with no on-path access.
> - Man-in-the-middle (attacker *with* on-path access).
> 
> It looks like the third threat (man-in-the-middle) is currently not addressed 
> by POT.
> I certainly agree that this threat is the more difficult to implement of the 
> three.
> 
> It would significantly clarify the picture if you specified in the draft 
> which of the three classes you intend to address.
> 

That’s a good point, indeed. The MIIM is one we should expand upon.

Thanks!

— Carlos.

> Thanks,
> Tal.
> 
> 
>> -Original Message-
>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
>> Sent: Wednesday, July 20, 2016 11:51 AM
>> To: Tal Mizrahi
>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-
>> of-tran...@tools.ietf.org; s...@ietf.org; opsawg@ietf.org; n...@ietf.org
>> Subject: Re: MD Type attack (Was: Question regarding Proof of Transit draft)
>> 
>> Hi, Tal,
>> 
>>> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>> 
>>> Hi Carlos,
>>> 
>>> 
>>>> Let’s step back a little — the “vulnerability” you are describing
>>>> comes with the assumption that a MIIT attacker can intercept a
>>>> packet, extract a TLV from the MD Type 2, drop the packet; then
>>>> intercept another packet (with the knowledge that it took a different
>>>> path, so maybe the attacker is using inband OAM as well :-), and
>>>> insert (or modify) a TLV within the content of the MD Type 2 within the
>> content of NSH, within a specific packet.
>>>> 
>>>> This sounds quite sophisticated.
>>> 
>>> I am not sure I agree this is a 'sophisticated' attack.
>>> The attack does not require any cryptographic or algorithmic functionality,
>> and to that end it is very lightweight in terms of processing resources.
>> 
>> Sorry if I was not clear — I do not mean technological sophistication or
>> massive processing resources required. I mean access and operational one.
>> 
>>> 
>>> If this kind of attack is not within the scope here, then I would argue that
>> you don't need a cryptographic mechanism at all. All you need is a TLV that
>> specifies the list of nodes. However, I believe that you did want to try to
>> mitigate MITM attackers. Correct me if I am wrong.
>>> 
>> 
>> You seem to have missed quoting the important part of my response: "My
>> point is that what you seem to be describing is a generic threat use case and
>> not a specific vulnerability.”
>> 
>> Selectively dropping part of the response removes important context.
>> 
>>> I fully agree that the threat model needs to be well-defined.
>> 
>> The threat model for SFC MD, yes. Access to the POT comes with
>> assumptions.
>> 
>> Thanks,
>> 
>> — Carlos.
>> 
>>> I hope you will elaborate more on the threat model in the next version of
>> the draft.
>>> 
>>> Cheers,
>>> Tal.
>>> 
>>> 
>>>> -Original Message-
>>>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
>>>> Sent: Wednesday, July 20, 2016 11:34 AM
>>>> To: Tal Mizrahi
>>>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne);
>>>> draft-brockners-proof- of-tran...@tools.ietf.org; s...@ietf.org;
>>>> opsawg@ietf.org; n...@ietf.org
>>>> Subject: MD Type attack (Was: Question regarding Proof of Transit
>>>> draft)
>>>> 
>>>> Tal,
>>>> 
>>>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>>>> 
>>>>> Hi Sashank,
>>>>> 
>>>>>> [SD] The attack is valid only if the attacker can get away
>>>>>> bypassing a
>>>> service function/node.
>>>>>> For example, if the attacker bypasses a node and if POT determines
>>>>>> it did
>>>> not bypass is a valid attack on the system.
>>>>> 
>>>>> I would phrase it this way: *Given* a packet that did not go th

Re: [OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

[Carlos Pignataro (cpignata)]

Hi, Tal,

> On Jul 20, 2016, at 11:42 AM, Tal Mizrahi <ta...@marvell.com> wrote:
> 
> Hi Carlos,
> 
> 
>> Let’s step back a little — the “vulnerability” you are describing comes with 
>> the
>> assumption that a MIIT attacker can intercept a packet, extract a TLV from
>> the MD Type 2, drop the packet; then intercept another packet (with the
>> knowledge that it took a different path, so maybe the attacker is using 
>> inband
>> OAM as well :-), and insert (or modify) a TLV within the content of the MD
>> Type 2 within the content of NSH, within a specific packet.
>> 
>> This sounds quite sophisticated.
> 
> I am not sure I agree this is a 'sophisticated' attack.
> The attack does not require any cryptographic or algorithmic functionality, 
> and to that end it is very lightweight in terms of processing resources.

Sorry if I was not clear — I do not mean technological sophistication or 
massive processing resources required. I mean access and operational one.

> 
> If this kind of attack is not within the scope here, then I would argue that 
> you don't need a cryptographic mechanism at all. All you need is a TLV that 
> specifies the list of nodes. However, I believe that you did want to try to 
> mitigate MITM attackers. Correct me if I am wrong.
> 

You seem to have missed quoting the important part of my response: "My point is 
that what you seem to be describing is a generic threat use case and not a 
specific vulnerability.”

Selectively dropping part of the response removes important context.

> I fully agree that the threat model needs to be well-defined.

The threat model for SFC MD, yes. Access to the POT comes with assumptions.

Thanks,

— Carlos.

> I hope you will elaborate more on the threat model in the next version of the 
> draft.
> 
> Cheers,
> Tal.
> 
> 
>> -Original Message-
>> From: Carlos Pignataro (cpignata) [mailto:cpign...@cisco.com]
>> Sent: Wednesday, July 20, 2016 11:34 AM
>> To: Tal Mizrahi
>> Cc: Sashank Dara (sadara); Frank Brockners (fbrockne); draft-brockners-proof-
>> of-tran...@tools.ietf.org; s...@ietf.org; opsawg@ietf.org; n...@ietf.org
>> Subject: MD Type attack (Was: Question regarding Proof of Transit draft)
>> 
>> Tal,
>> 
>>> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi <ta...@marvell.com> wrote:
>>> 
>>> Hi Sashank,
>>> 
>>>> [SD] The attack is valid only if the attacker can get away bypassing a
>> service function/node.
>>>> For example, if the attacker bypasses a node and if POT determines it did
>> not bypass is a valid attack on the system.
>>> 
>>> I would phrase it this way: *Given* a packet that did not go through its
>> desired path, the attacker can easily make you think that it *did* go through
>> the desired path.
>>> Sounds like a very significant vulnerability.
>>> 
>>> If a packet did not go through the firewall (for one reason or another), the
>> attacker will make you think that it did go through the firewall.
>>> 
>> 
>> Let’s step back a little — the “vulnerability” you are describing comes with 
>> the
>> assumption that a MIIT attacker can intercept a packet, extract a TLV from
>> the MD Type 2, drop the packet; then intercept another packet (with the
>> knowledge that it took a different path, so maybe the attacker is using 
>> inband
>> OAM as well :-), and insert (or modify) a TLV within the content of the MD
>> Type 2 within the content of NSH, within a specific packet.
>> 
>> This sounds quite sophisticated.
>> 
>> Do you think that if an MIIT can have that surface of attack and
>> sophistication, they can mess up with other even more critical things?
>> Changing a Tenant ID, messing up with Policy Groups, etc?
>> 
>> My point is that what you seem to be describing is a generic threat use case
>> and not a specific vulnerability. Engineering is about trade-offs (i.e., 
>> solutions
>> that have practical performance) and about placing the solution in the most
>> effective place.
>> 
>> I’m not deflecting but at the same time, let’s understand the assumptions you
>> are making for this potential attack you describe, as part of the threat
>> analysis.
>> 
>> Thanks,
>> 
>> — Carlos.
>> 
>>> Cheers,
>>> Tal.
>>> 
>>> 
>>> From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
>>> Sent: Wednesday, July 20, 2016 4:31 AM
>>> To: Tal Mizrahi; Frank Brockners (fbrockne); draft-brockners-proof-of-
>> tran...@tools.ietf.org
>>> Cc: s...@ie

[OPSAWG] MD Type attack (Was: Question regarding Proof of Transit draft)

[Carlos Pignataro (cpignata)]

Tal,

> On Jul 20, 2016, at 6:30 AM, Tal Mizrahi  wrote:
> 
> Hi Sashank,
> 
>> [SD] The attack is valid only if the attacker can get away bypassing a 
>> service function/node.
>> For example, if the attacker bypasses a node and if POT determines it did 
>> not bypass is a valid attack on the system.
> 
> I would phrase it this way: *Given* a packet that did not go through its 
> desired path, the attacker can easily make you think that it *did* go through 
> the desired path.
> Sounds like a very significant vulnerability.
> 
> If a packet did not go through the firewall (for one reason or another), the 
> attacker will make you think that it did go through the firewall.
> 

Let’s step back a little — the “vulnerability” you are describing comes with 
the assumption that a MIIT attacker can intercept a packet, extract a TLV from 
the MD Type 2, drop the packet; then intercept another packet (with the 
knowledge that it took a different path, so maybe the attacker is using inband 
OAM as well :-), and insert (or modify) a TLV within the content of the MD Type 
2 within the content of NSH, within a specific packet.

This sounds quite sophisticated.

Do you think that if an MIIT can have that surface of attack and 
sophistication, they can mess up with other even more critical things? Changing 
a Tenant ID, messing up with Policy Groups, etc? 

My point is that what you seem to be describing is a generic threat use case 
and not a specific vulnerability. Engineering is about trade-offs (i.e., 
solutions that have practical performance) and about placing the solution in 
the most effective place.

I’m not deflecting but at the same time, let’s understand the assumptions you 
are making for this potential attack you describe, as part of the threat 
analysis.

Thanks,

— Carlos.

> Cheers,
> Tal.
> 
> 
> From: Sashank Dara (sadara) [mailto:sad...@cisco.com]
> Sent: Wednesday, July 20, 2016 4:31 AM
> To: Tal Mizrahi; Frank Brockners (fbrockne); 
> draft-brockners-proof-of-tran...@tools.ietf.org
> Cc: s...@ietf.org; opsawg@ietf.org; n...@ietf.org
> Subject: Re: Question regarding Proof of Transit draft
> 
> 
> 
> The POT replacement attack (1.) is not an attack on the integrity. It is an 
> attack on the path verification.
> This simple attack can cause the verifier to accept a packet that did not go 
> through the firewall SF (even though it should). I believe this is exactly 
> the problem you were aiming to address in this draft.
> 
> [SD] The attack is valid only if the attacker can get away bypassing a 
> service function/node.
> For example, if the attacker bypasses a node and if POT determines it did not 
> bypass is a valid attack on the system.
> 
> In the current state, there is no way an attacker can get away as we 
> determine the exact path the packet travelled (aim of the draft) .
> I reiterate that the verifier needs to handle what to do with the path 
> reconstructed !
> We could emphasize this in our next draft , but it would be beyond scope of 
> POT to determine what to do with the path constructed.
> IMO, It would be highly application specific.
> 
> 
> Regards,
> Sashank
> 
> 
> 
> Thanks,
> Tal.
> 
> From: Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
> Sent: Tuesday, July 19, 2016 6:00 PM
> To: Tal Mizrahi; Sashank Dara (sadara); 
> draft-brockners-proof-of-tran...@tools.ietf.org
> Cc: s...@ietf.org; 
> opsawg@ietf.org; n...@ietf.org
> Subject: RE: Question regarding Proof of Transit draft
> 
> Hi Tal,
> 
> thanks for the summary. We'll provide more details on 2. Per my earlier point 
> - 1. is an interesting discussion, given that we don't claim to provide 
> integrity protection for the packet payload. Or in other terms - to be exact: 
> What POT provides is a proof that the POT-header/meta-data transited all the 
> required nodes. There is no association (and thus proof) provided for the 
> additional data carried along with the POT-header - neither header nor 
> payload. As a consequence, attacks which change the packet payload won't be 
> detected/mitigated. We'll explicitly state this in the security 
> considerations in the next rev of the document.
> What we could consider is linking the RND number to CRC across the packet 
> payload or similar - but that way we'd restrict the applicability to 
> deployments where the packet payload isn't changed across the path (which 
> might not apply to certain deployment - e.g. WAN optimization / compression 
> schemes).
> Do you think it is worthwhile to provide a solution for a deployment which is 
> expected to not alter the packet payload?
> 
> Thanks,
> Frank
> 
> From: Tal Mizrahi [mailto:ta...@marvell.com]
> Sent: Dienstag, 19. Juli 2016 17:44
> To: Sashank Dara (sadara) >; Frank 
> Brockners (fbrockne) 

Re: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02

[Carlos Pignataro (cpignata)]

I agree -- I see no conflict with l2tpext work.

-- Carlos.

On Aug 19, 2013, at 12:54 PM, Ignacio Goyret i.goy...@alcatel-lucent.com 
wrote:

 I don't see any conflict with l2tpext wg work.
 -Ignacio
 
 At 07:43 8/19/2013, Ted Lemon wrote:
 I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which is 
 proposed for publication in the independent stream.   I think this document 
 does not conflict with the work that you are doing, but I would appreciate 
 it if you could take a quick look at the document and make sure that you 
 agree with me.
 
 http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02
 
 Thanks!
 



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

Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

[Carlos Pignataro (cpignata)]

Hello, Fan, Ramki,

Just because there is a hammer, it does not mean that every problem is a nail. 
Someone mentioned this on the presentation at Berlin.

Fan,

It really is all about scope and goals. You mention that ICMP is not 
appropriate, and then that it is appropriate. I suspect the real conclusion is 
context dependent. 

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Aug 6, 2013, at 8:18 AM, Fan, Peng fanp...@chinamobile.com wrote:

 Hi Ramki,
 
 Yes I agree with you on this point. This is also one of the reasons why ICMP 
 may not be a proper way to do performance measurement, especially when we 
 want to get results precise enough. In fact ICMP has been imposed on so many 
 functions that it is hardly as ordinary as internet traffic, and the 
 processing of ICMP is closely related with vendor implementation which may 
 not be adjustable by configuration. But alas we don't have structured IP OAM 
 tools like MPLS OAM or ETH OAM, and sometimes people just choose ICMP for its 
 convenience.
 
 Thanks,
 Peng
 
 -邮件原件-
 发件人: ramki Krishnan [mailto:r...@brocade.com]
 发送时间: 2013年8月6日 12:08
 收件人: Fan, Peng; opsawg@ietf.org
 主题: RE: [OPSAWG] Fwd: New Version Notification for
 draft-fan-opsawg-packet-loss-01.txt
 
 Hi Peng,
 
 What I am saying is that DDoS attack prevention is one of the primary 
 reasons.
 With that in mind, it may not be prudent for ICMP packets to experience the
 same forwarding and discarding courses (or drop probability) as the service
 traffic.
 
 Thanks,
 Ramki
 
 -Original Message-
 From: Fan, Peng [mailto:fanp...@chinamobile.com]
 Sent: Monday, August 05, 2013 8:54 PM
 To: ramki Krishnan; opsawg@ietf.org
 Subject: Re: [OPSAWG] Fwd: New Version Notification for
 draft-fan-opsawg-packet-loss-01.txt
 
 Hi Ramki,
 
 Thanks for commenting. Let me clarify your statement first. Are you saying 
 that
 the reason why ICMP is given a different treatment by routers is to prevent 
 DDoS
 attacks?
 
 There may be different reasons for which ICMP is treated specially, for 
 example
 routers may give high priority in processing and forwarding to packets of 
 network
 control protocols, e.g. ICMP, routing protocols, etc. This section is 
 explaining that
 if ICMP packets and service packets to be measured experience different
 treatments, then using ICMP to measurement packet loss is not advised. A 
 basic
 requirement for using ICMP (and other active measurement approaches) is to 
 let
 probing traffic and service traffic have the same drop probability, though 
 it is
 usually difficult to guarantee this.
 
 Regards,
 Peng
 
 -邮件原件-
 发件人: ramki Krishnan [mailto:r...@brocade.com]
 发送时间: 2013年8月6日 0:43
 收件人: Fan Peng; opsawg@ietf.org
 主题: RE: [OPSAWG] Fwd: New Version Notification for
 draft-fan-opsawg-packet-loss-01.txt
 
 Sorry, missed the section -- I am including it. My comments are on Section 
 5 a.
 
 If this method is to be used on a router, one is advised to make
 sure that the ICMP packets experience the same  forwarding and
 discarding
 courses as the service traffic (of  which the packet loss rate is to
 be measured) does, otherwise the measurement will not make sense.
 
 I wouldn’t quite agree with this. The reason it is done so today is to
 prevent ping flood type of DDoS attacks
 
 Thanks,
 Ramki
 
 -Original Message-
 From: opsawg-boun...@ietf.org [mailto:opsawg-boun...@ietf.org] On
 Behalf Of ramki Krishnan
 Sent: Sunday, August 04, 2013 4:23 PM
 To: Fan Peng; opsawg@ietf.org
 Subject: Re: [OPSAWG] Fwd: New Version Notification for
 draft-fan-opsawg-packet-loss-01.txt
 
 If this method is to be used on a router, one is
 advised to make sure that the ICMP packets experience the same
 forwarding and discarding courses as the service traffic (of  which
 the packet loss rate is to be measured) does, otherwise the measurement will
 not make sense.
 
 I wouldn’t quite agree with this. The reason it is done so today is to
 prevent ping flood type of DDoS attacks.
 
 Thanks,
 Ramki
 
 -Original Message-
 From: opsawg-boun...@ietf.org [mailto:opsawg-boun...@ietf.org] On
 Behalf Of Fan Peng
 Sent: Friday, July 05, 2013 7:56 AM
 To: opsawg@ietf.org
 Subject: [OPSAWG] Fwd: New Version Notification for
 draft-fan-opsawg-packet-loss-01.txt
 
 Dear all,
 
 We have updated a complete revision to the I-D regarding packet loss
 measurement , and would like to get feedback from you:
 
 IP Packet Loss Rate Measurement Testing and Problem Statement
 http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01
 
 The document aims to review methods for packet loss rate measurement
 and problems with them, and provide some guidelines when performing
 the measurement. The document is based on operational experience and
 needs especially when doing performance monitoring on the
 interconnecting link between two providers' networks. We also hope we
 can find after the discussion a measurement scheme that is convenient
 enough and provides consistent

Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

[Carlos Pignataro (cpignata)]

There are two other considerations:

1. ICMP packets might follow a different path than the application in the 
presence of ECMP
2. The ICMP responder might rate limit and drop if it's a router regardless of 
the drop characteristics of the path -- RFC 6192.

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Aug 6, 2013, at 4:33 PM, Anoop Ghanwani 
an...@alumni.duke.edumailto:an...@alumni.duke.edu wrote:




On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng 
fanp...@chinamobile.commailto:fanp...@chinamobile.com wrote:

A basic requirement for using ICMP (and other active measurement approaches) is 
to let probing traffic and service traffic have the same drop probability, 
though it is usually difficult to guarantee this.

It seems like this would be further complicated if something like ECN is in 
use.  While ECT packets would be marked with CE and thus not contribute to the 
loss rate, ICMP packets would end up being discarded.

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