Re: [Raw] Call for adoption of draft-theoleyre-raw-oam-support-01

[Greg Mirsky <[e-mail]>]

Hi Rick, Eve, et al.,
I've volunteered to review this draft, and I'd like to use this thread to
share my comments with you. My answers to three questions set forth by WG
Chairs are in-lined below tagged GIM>>, following my comments.

I enjoined reading the document - it is very well written, with an in-depth
understanding of OAM and the specifics of the wireless media. There's no
priority order in a way I've listed them.

   - the draft, as I understand, intended to define the OAM framework in
   RAW, list requirements for OAM in RAW, identify the RAW-specific scenarios.
   The document is on the Standards track, but Informational might be better
   suited as protocols and mechanisms to address the requirements likely will
   be specified in separate drafts.
   - Abstract may benefit from some update to closer align with the goal of
   the document explained in the Introduction section (I've applied minor
   editorial changes to the second from the end paragraph):

NEW TEXT:
   This document lists the requirements of
   the Operation, Administration, and Maintenance (OAM) features
recommended to construct a predictable communication
   infrastructure on top of a collection of wireless segments.  This
   document describes the benefits, problems, and trade-offs for using
   OAM in wireless networks to achieve Service Level Objectives.


   - I suggest using Service Level Objectives rather than Service Level
   Agreement. These are similar, but SLA exists in the form of a document,
   likely legal document between a Subscriber and an Operator. SLO, on the
   other hand, reflects what an Operator plans to achieve for the particular
   class of services.
   - several notes on the Terminology:
      - I would propose to change from "flow to be controlled" to "flow to
      be monitored"
      - OAM end-device is a useful term, but I didn't find it being used in
      the text. Instead, "maintenance endpoint" used in Section 5. I am used to
      MEP and MIP (used in Section 3.2) terminology, but that will require the
      definition of the Maintenence Domain. Alternatively, we can use
Test Point
      for MEPs and Monitoring Point for MIPs.
      - I think that the explanation provided for "defect" is closer to
      "quality degradation". A defect is usually is associated with a
state that
      has entry and exit criteria.
   - Section 2 is very useful; thank you. Do you think that changing the
   title to "Role of OAM in RAW" be helpful?
   - You may consider generalizing the second paragraph and refer to an
   orchestrator or SDN controller rather than to single out the PCE solution.
   - I'm not sure I fully agree with the following statement

OAM is in charge of controlling the replication/elimination processes.

I think that for the given RAW flow, PREOF on a node is controlled by the
central controller. OAM may be used to verify that PREOF is operating
properly on a node and within the domain.


   - The title of Section 3.1 gives me the opportunity to get on one of my
   favorite "OAM soap-box". There's a fine distinction between Continuity
   check and Connectivity verification. The former only concerns with the
   existence of a way to deliver a packet from node A to node B. The latter
   adds another condition - the absence of misconnection, i.e., no packets
   from nodes other than A, received on node B's interface. Of course, that is
   important if we consider the p2p connection-oriented communication model.
   - Multipath is undoubtedly an appropriate term to characterize a network
   that has more than one path between two nodes. An alternative might be the
   "meshed network".
   - Very interesting and appropriate discussion of a sufficient amount of
   OAM information in Section 3.3. It might deserve to be in the separate
   section and be expanded to how active OAM and on-path OAM (for example,
   iOAM, iPath, INT from P4) can be combined, complement each other.
   - you may find some OAM requirements in the expired document on OAM in
   overlay networks
   <https://www.ietf.org/archive/id/draft-ooamdt-rtgwg-ooam-requirement-02.txt>
   .

1) Is the RAW working group the correct WG for this work?
GIM>> I think yes
2) Are you as a WG participant ready and willing to review and raise
comments on the draft, if it is adopted?
GIM>> I do (for better for worse, for richer for poorer)
3) Does the draft meet the criteria outlined in the WG charter (this is
mostly a decision for the chairs, but we welcome feedback!)
GIM>> As I understand the stated scope of the draft "yes".

I have three questions I usually answer to myself when evaluating a
candidate document for WG adoption:

   1. Is the document reasonably well-written? Is it readable? - Yes
   2. Does the document address the real problem? - Yes
   3. Is the proposed solution to the problem plausible? - This document
   correctly identifies the problem and is very much needed to document the
   requirements to OAM in RAW.


Regards,
Greg

On Mon, Mar 30, 2020 at 3:13 AM Rick Taylor <[e-mail]>
wrote:

> Hi All,
>
> The authors of: draft-theoleyre-raw-oam-support-01 (have asked for a call
> for working group adoption of their draft.
>
> The link to the draft is:
> https://datatracker.ietf.org/doc/draft-theoleyre-raw-oam-support/
>
> This is your opportunity to express your opinion.
>
> A decision will be made on/after 13th April.
>
> Cheers,
>
> Rick and Eve
> Co-chairs
>
> --
> RAW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/raw
>