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

[Qin Wu <[e-mail]>]

Hi, Greg:
Please find our response inline below.

-Qin
From: Lime <[e-mail]<mailto:[e-mail]>> on behalf of Greg Mirsky <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 7 February 2017 at 11:39 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lime] WGLC: draft-ietf-lime-yang-connectionless-oam-methods-00

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.
[Authors]>> Tend to agree that it will be nice to have one method model common to both CL and CO, but there was consensus to separate CL from CO after a long discussion. CO data and CL data follow different model structure, follow different namespace, using different addressing,  there will be a significant change to include CO at this point and if so, we can continue this methods draft to be CL?

  *   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.
[Authors]>> Will fix.

  *   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.
[Authors]>> Will see how to fix.

     *   " Ping and Traceroute ..." why only on-demand OAM being explicitly mentioned and no proactive CC like BFD?
[Authors]>> Will fix.  Methods are not specific to on-demand OAM.

  *   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."
[Authors]>> Will fix.

  *   Section 3.1

     *   s/icmp ping/ICMP ping/
     *   s/lsp ping/LSP ping/
     *   I think that each reference requires reference to defining RFC
[Authors]>> Will fix.

  *   Section 3.2

     *   what and when src-dst-address define destination-tp;
[Authors]>> This is from BFD requirement.  I believe the consensus for test-point was to remove this combination of (src, dst) from there.  If so, we can remove it here as well.
*

     *   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?
[Authors]>> This is again the FEC question.  We can change it to the same name as in base draft.
*

     *   What is tlv-address as destination-tp?
[Authors]>> This can be removed.  Remnants from previous version...I believe.
*

     *   What is meaning of source-interface if destination-tp is of type src-dst-address and thus already includes src-ip-address?
[Authors]>> will fix by removing src-dst-address as mentioned before.
*

     *   What is meaning of outbound-interface if destination-tp is of type src-dst-address and thus already includes Interface?
[Authors]>> will fix by removing src-dst-address as mentioned before.
*

     *   What is expected for src-test-point and dest-test-point respectively if these are src-dst-address type?
[Authors]>> will fix by removing src-dst-address as mentioned before.
*

     *   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.
[Authors]>> Don't understand the question fully...if the question is why to retrieve session-xxx statistics with each RPC call...it is not mandatory,it will happen after the test session gets completed...and also the 'new' methods(create/modify/delete) in the attachment allows options where the session statistics are NOT retrieved for each RPC but trigger something to be done off the box.

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