Re: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08

Dear Authors, WG Chairs, et. al,
please consider my comments as part of WGLC discussion.

   - Overview of the OAM Model
   - Why MEF-38 Service OAM Fault Management YANG Modules not only used as
      prototype but not even referenced?
      - "... for VPLS this can be per VPLS instance" Is this OAM model of
      service OAM of provided by the VPLS instance service or of
IP/MPLS underlay
      that provides transport for the VPLS instance? If the former,
then we have
      MEF-38. if the latter, then it is IP/MPLS network OAM, i.e.
connectionless.
      - "... connectivity verification(loopback) ..." OAM method to verify
      proper connectivity between MEPs of the specified MA rarely, if any,
      supported by the Loopback command. In order to detect in
mis-connection and
      in-defect and out-of-defect conditions, CV should operate as
proactive OAM
      command, e.g. CCM in CFM/Y.1731 or BFD-based CV for MPLS-TP as
described in
      RFC 6428.
      - "The generic YANG model defined here does not require explicit
      configuration of OAM entities prior to using any of the OAM tools."

I consider configuration of a remote MEP to be absolute pre-requisite to
using even Loopback or Linktrace commands. Similarly, configuration of MIPs
may be required as well.

   - Is "base mode for" synonymous to "default values"? The mentioning that
      explicitly would be helpful.
   -  3.5
   <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>.
   Test Point Locations
      - "routing instance vrf name if required" YANG Data Model for MPLS-TP
      OAM  <https://tools.ietf.org/html/draft-zhang-mpls-tp-yang-oam-03> does
      not require or even reference to VRF name
   - I don't see any reference to the above mentioned YANG Data Model for
   MPLS-TP OAM.
   - Nor I see substantive references to RFC 6428
   - There's no operational information specific to operation of
   connectivity verification mechanism in container oper, but only ones
   related to operation of continuity check. How MEP reports its state in
   regard to mis-connection defect (in-defect or out-of-defect)?
   - tlv-address should not be used as tp-address but as MPLS-TP
   Identifiers per RFC 6370 and RFC 6428.
   - FEC is not address of a single Test Point but group of IP packets
   which are forwarded in the same manner, over the same path, and with the
   same forwarding treatment.
   - cos-id in grouping cos is of type uint8 though TC filed mentioned as
   example is only three bits long. How these are mapped?
   - output from traceroute allows only MEP response while in linktrace
   MIPs that belong to the same MA should respond with LTR. LSP Ping does the
   same.

Nits:

   - [lime retrieval methods] - looks as meant to be reference but there's
   no a document it points to.
   - grouping cos still refers to EXP field in MPLS-TP even though the
   field has been renamed Traffic Class (TC) in 2009 by RFC 5462
   - s/Ma name format/MA name format/
   - s/Yang/YANG/ (several occasions of this)
   - in 4. 6 s/Augment/augment/
   -

I cannot support publication of this version of the document.

Regards,
Greg

On Thu, Jan 19, 2017 at 8:13 AM, Ron Bonica <rbonica@juniper.net> wrote:

> Folks,
>
> This message begins a WGLC on draft-ietf-lime-yang-oam-model-08. Please
> submit comments by February 3, 2017.
>
>                                            Ron
>
> _______________________________________________
> Lime mailing list
> Lime@ietf.org
> https://www.ietf.org/mailman/listinfo/lime
>