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

Hi Greg

Thanks for your review and comments, please find my reply inline.

Best Regards!

-Michael

发件人: Lime [mailto:lime-bounces@ietf.org] 代表 Greg Mirsky
发送时间: 2017年2月1日 2:07
收件人: Ron Bonica
抄送: lime@ietf.org; draft-ietf-lime-yang-oam-model.all@ietf.org
主题: 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?
                       [MQD] In this document, we adopt the concepts of CFM to structure the connection-oriented oam yang module. CFM [IEEE802.1Q] is our baseline. That’s why we reference [IEEE802.1Q].

     *   "... 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.
[MQD]: It is close to the former, we think RFC6136 is a good reference for  VPN instance https://tools.ietf.org/html/rfc6136#section-5.2.4.
Anyway this is just an example, we can remove it if it cause confusing.

     *   "... 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.
[MQD]: according to https://en.wikipedia.org/wiki/IEEE_802.1ag, MEP can send a Loopback to any MEP or MIP in the service.

     *   "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.

[MQD] This is generic YANG model or technology independent model, it defined base mode or default mode. Technology specific model will provide details configuration of a remote MEP or MIP.
That’s why the base model doesn’t require explicit configuration of OAM entities prior to using any of the OAM tools.

     *   Is "base mode for" synonymous to "default values"? The mentioning that explicitly would be helpful.
                        [MQD]: the base mode is equivalent to “default mode”, sure we will make this clear.

  *    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

[MQD]:Section 3.5 is not in the CO OAM model draft, therefore this comment is not applied.

  *   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
[MQD]: Will add it.

  *   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)?
 [MQD]: This comment is applied to CL OAM model draft, will  change it into CC specific operation information as you suggested.

  *   tlv-address should not be used as tp-address but as MPLS-TP Identifiers per RFC 6370 and RFC 6428.

[MQD]:tlv-addres is not defined in CO OAM model draft, therefore this comment is not applied to CO model.

  *   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.
  [MQD]: This comment is applied to CL OAM model draft. The intention of using FEC is to focus on addressing part, not forwarding treatment, will figure out use the different terminology  if it causes confusion.

  *   cos-id in grouping cos is of type uint8 though TC filed mentioned as example is only three bits long. How these are mapped?

[MQD]: Consider for technology independent and future technology, we defined this type as uint8 rather than 3 bits long, how these are mapped should

Be defined in the technology specific model.

  *   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.

[MQD]:This was discussed before, it was agreed to define linktrac MIP responding with LTR in the technology specific model.

Nits:

  *   [lime retrieval methods] - looks as meant to be reference but there's no a document it points to.

[MQD]: This comment is not relevant to this document, but Thanks.

  *   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/
[MQD]: thanks, will fix this.

  *
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<mailto: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<mailto:Lime@ietf.org>
https://www.ietf.org/mailman/listinfo/lime