Re: [ippm] Vote at IPPM session

Greg,

You seem to be presenting a position akin “half-glass is completely empty and has absolutely nothing in it”, or “it is empty, that glass, on one haf” – which is more polarized than “the glass is half empty”.

For #2, please read the threads. And the new text discussed on this list, which is forthcoming (so allow for more *concrete* comments on the text itself).
In this, Adrian has a great suggestion: pointed, targeted, narrow-scoped and explicit questions are more useful.

For #3, if your concern that amounts to technical unsoundness is the 4 instances of “out-of-band”, seems like an easy thing to resolve.

Thanks!

-- Carlos.

From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thursday, April 27, 2017 at 12:59 PM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: Carlos Pignataro <cpignata@cisco.com>, IPPM Chairs <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Subject: Re: [ippm] Vote at IPPM session

Hi Adrian,
per my understanding WG adoption call is to answer three basic questions:

  *   is the document reasonably readable;
  *   does it solve outstanding operational problem, i.e. yet unaddressed or operationally burdensome scenario;
  *   is the document technically sound.
I certainly say 'yes' to #1. I cannot say 'yes' neither on # 2, nor on #3:

  *   On #2. It appears to me that we're discussing what iOAM does and what it should not do even though the stated scope of the document is the data types, not the mechanism of the protocol itself. Does that indicate that the scope is not yet clearly defined? And if the mechanism of in-situ OAM is in scope of the document, then I cannot find clear statement of the problem(s) it solves or was intended to solve. If anyone can help me with the answer, would be much obliged.
  *   On #3. References to non-existent "out-of-band OAM" don't make the document technically sound, rather contrary to that. As the allusion that active OAM is inherently out-of-band and thus active OAM methods are not suitable to address needs of network operators.

Regards,
Greg

On Thu, Apr 27, 2017 at 4:05 AM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
Carlos is right, but we got to this discussion because after Frank spoke in Chicago there were a number of scoping questions that remained unclear with possible misunderstandings and assumptions.

It should be clear from the email exchanges on this list so far that the type of solution we develop will be considerably dependent on the scope of the problem.

I don't believe we (well, not me anyway) are calling for a detailed requirements document. Not even a problem statement document. But we do need a clear scoping statement.

As it happens, Frank has done some good work to address this with his new text, and I think we are close to done.

The only issue might be one of language. Saying "requirements" conveys different meanings to different people.

Probably the best way to ensure Greg's concerns are answered is for Greg to ask specific targeted questions (such as, but not specifically, "Do you intend this technology to be used in kitchen appliances?"). Then Frank can suggest answers, others can chime in for consensus, and the result can be briefly captured in the document.

Ciao,
Adrian

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com<mailto:cpignata@cisco.com>]
Sent: 26 April 2017 15:21
To: Greg Mirsky
Cc: Adrian Farrel; IPPM Chairs; ippm@ietf.org<mailto:ippm@ietf.org>

Subject: Re: [ippm] Vote at IPPM session

Greg,

I agree that a shared understanding and alignment on the problem space is critically important. My understanding is that we have already been doing that extensively, including the work on potential charter text discussed in Opsawg. That was, for example, a discussion solely about the problem to be solved.

What concerns me is the strict serialization and waterfall you seem to be advocating for.

— Carlos.

On Apr 26, 2017, at 9:22 AM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:

Dear Carlos,
thank you for the reference.
I've never called for perfecting but for rough consensus on what problem we need to address. How, IMHO, is secondary. And that is what may be not working in this discussion - we've been presented answer to how do measurement before we have reached an agreement that there's a problem to be solved.

Regards,
Greg

On Wed, Apr 26, 2017 at 6:13 AM, Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
Dear Greg,

Something like https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-03?

For the record, my opinion: perfecting requirements is perhaps not the best use of WG cycles. However, placing requirements as a serialized requisite before progressing protocol work is certainly harmful in this case.

Thanks,

-- Carlos.

From: ippm <ippm-bounces@ietf.org<mailto:ippm-bounces@ietf.org>> on behalf of Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Date: Wednesday, April 26, 2017 at 5:22 AM
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: IPPM Chairs <ippm-chairs@ietf.org<mailto:ippm-chairs@ietf.org>>, "ippm@ietf.org<mailto:ippm@ietf.org>" <ippm@ietf.org<mailto:ippm@ietf.org>>
Subject: Re: [ippm] Vote at IPPM session

Hi Adrian, et. al,
I strongly believe that having agreed upon list of requirements that answer questions What? and Where? rather than How? is the most beneficial and not only for the discussion of applicability of in-situ OAM. What needs to be solved, measured that is not ameasureable by already existing OAM methods? I think that if we can compile such list, then it will be more clear what value may be added by developing new hybrid OAM method.

Regards,
Greg

On Wed, Mar 29, 2017 at 2:32 PM, Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>> wrote:
> > There were several questions related to scope and applicability in the WG
> discussion – and even more recently on the list. Those can easily be addressed by
> adding paragraph on applicability to draft-brockners-inband-oam-data – there
> isn’t a need for a dedicated requirements document.
>
> I tend to agree with this, although "a paragraph" seems a little thin to me. I think
> there were some valid points made in that discussion about the scope of the
> proposal that should be addressed: is IOAM meant for use tunnel-end-to-tunnel-
> end environment,  end-host-to-end-host, within a single network and/or across
> the Internet.  What I would suggest is adding a section to the data model draft on
> applicability and assumptions about the environment -- both about the devices
> adding IOAM signals to traffic as well as those consuming these signals from the
> wire and analyzing them (possibly with the cooperation of devices not on the
> wire) -- submitting a new revision, and we can run a more formal adoption call on
> that.

Although I was one of the people raising the "need" for the scope and requirements, I don't have a strong leading on whether this needs to be in a separate document on folded into the data format document. So Brian's proposal would work for me.

Thus, I'd love to see this scoping text drafted and floated to the list as an email or in a revision of the data format document.

Cheers,
Adrian

_______________________________________________
ippm mailing list
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm