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

From: Qin Wu <[email-masked]>
Date: Tue, 7 Feb 2017 01:09:54 +0000

Support.
A few comments and suggested change to draft-ietf-lime-yang-connectionless-oam-methods-00:
1.s/[lime base model]/ [I-D.ietf-lime-yang-connectionless-oam]
2. Add a reference to [I-D.ietf-lime-yang-connectionless-oam in the Normative reference section.
3. Section 3.1
s/ captured under a separate module./captured under a separate module in the future work.
4. Remove " YANG module of OAM "at the end of section
5. Section 5 Security section, proposed text as follows:
"
The YANG modules defined in this memo are designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory to implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content.

Some of the RPC operations in the "ietf-connectionless-oam-methods" YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:

o continuity-check: Generates continuity check.
o path-discovery: Generates path discovery.
"
-Qin
-----邮件原件-----
发件人: Lime [mailto:[email-masked]] 代表 Ron Bonica
发送时间: 2017年1月26日 23:12
收件人: [email-masked]
主题: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-methods-00

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
[email-masked]
https://www.ietf.org/mailman/listinfo/lime

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 6 Feb 2017 22:09:08 -0800

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 <[email-masked]> 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
>