Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-methods-00

[Greg Mirsky <[e-mail]>]

Dear Authors, WG Chairs, et. al,
I've reviewed this draft as part of WG LC. Please find my comments,
questions below.

   - Firstly, why does the model being limited to methods of connectionless
   (CL) OAM? Were there attempt to have one model applicable to CL and
   connection-oriented (CO)? Besides difference in identifying Test Point (TP)
   in CO OAM domain vs. TP in CL OAM, I don't see anything else. Of course, CL
   doesn't use Connectivity Verification as it does not have notion of a
   connection between TPs.
   - Abstract

Please try to avoid using acronyms in Abstract.
"... support nested OAM workflows (i.e., performing OAM functions at
different or same levels through a unified interface)."

I agree that the first example, different OAM levels, is the case of nested
multi-layer OAM. But I think that the second example, same levels, is not.
The latter example is example of interworking between different OAM
technologies at the same OAM level.


   - Introduction
      - "Monitor networks connections ..." It is strange to find reference
      to connection in document that discusses CL OAM. Though often connection,
      i.e. , is being used as substitute for continuity, i.e. availability of a
      path between TPs, I encourage to be disciplined with
terminology. There are
      several examples to illustrate the difference between continuity and
      connectivity. One is from the field of electrical engineering:

Continuity - fact that you have electrons from A reaching B. Connectivity -
electrons from A are reaching B over red wire. And there no electrons on
red wire other than from A.

Or can quote RFC 6428:

   Continuity Check monitors a Label Switched Path for any loss of
   continuity defect.  Connectivity Verification augments Continuity
   Check in order to provide confirmation that the desired source is
   connected to the desired sink.


   - " Ping and Traceroute ..." why only on-demand OAM being explicitly
      mentioned and no proactive CC like BFD?
   - Section 3, last sentence may be re-phrased "This will allow the user
   to retrieve retrieved-data defined by the base data model [] using
   mechanism of his or her choosing."
   - Section 3.1
      - s/icmp ping/ICMP ping/
      - s/lsp ping/LSP ping/
      - I think that each reference requires reference to defining RFC
   - Section 3.2
      - what and when src-dst-address define destination-tp;
      - as I've noted in comments on CO and CL OAM YANG models, FEC, in
      general case, is group IP packets that are being forwarded and treated by
      the network in the same manner. How does FEC can be considered as
      destination-tp without specifying single IP address within that group?
      - What is tlv-address as destination-tp?
      - What is meaning of source-interface if destination-tp is of type
      src-dst-address and thus already includes src-ip-address?
      - What is meaning of outbound-interface if destination-tp is of
      type src-dst-address and thus already includes Interface?
      - What is expected for src-test-point and dest-test-point
      respectively if these are src-dst-address type?
      - What is benefit to retrieve session-xxx statistics with each
      query/RPC not after the test session being completed, i.e. to
have separate
      RPC for session-xxx statistics? Alternatively, you can include two
      timestamps in your data and then calculate all session-scope statistics
      off-node.

I don't support publication of this version of the draft.

Regards,
Greg

On Thu, Jan 26, 2017 at 7:12 AM, Ron Bonica <[e-mail]> wrote:

> Folks,
>
> This message begins a WG Last Call for draft-ietf-lime-yang-connectionless-oam-methods-00.
> Please submit your comments by February 9, 2017.
>
>                                                                        Ron
>
> _______________________________________________
> Lime mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lime
>