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

[Greg Mirsky <[e-mail]>]

Hi Michael,
thank you for your thorough consideration and timely response to my
comments. Apologize for mixing some.
Please find my follow-up notes in-line and tagged GIM>>.

Regards,
Greg

On Tue, Feb 7, 2017 at 6:00 PM, wangzitao <[e-mail]> wrote:

> Hi Greg
>
>
>
> Thanks for your review and comments, please find my reply inline.
>
>
>
> Best Regards!
>
> -Michael
>
>
>
> *发件人:* Lime [mailto:[e-mail]] *代表 *Greg Mirsky
> *发送时间:* 2017年2月1日 2:07
> *收件人:* Ron Bonica
> *抄送:* [e-mail]; [e-mail]
> *主题:* 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].
>
GIM>> Ethernet SOAM YANG model is based on Y.1731 which is, in view of
many, is compatible with CFM and is CO. I think that relationship between
MEF-38 and LIME CO models must be discussed in the document.

>
>    - "... 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.
>
GIM>> If this is the example of Ethernet SOAM, then why not to refer to
MEF-38?

>
>    - "... 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.
>
GIM>> At least for MPLS-TP mi-connection defect been defined only when BFD
is used to perform CV. Please see sections 3.7. through 3.7.4 RFC 6428. I'm
not familiar with LBM/LBR being used to detect mis-connection defect.

>
>    - "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.
>
> GIM>> If MEP is not explicitly configured, at least in CFM and MPLS-TP,
then there's no automatic association with MD and  MA, nor notion of MEP
ID. If MIP is not enabled on the particular level, then it would not
respond to Linktrace. I don't see how without explicit configuration of MEP
and MIP operator will be able to use this model. Assuming that this model
does provide basic OAM functionality on its own, without requirement to
supplement it with "technology specific model". I believe that if there's
such dependency then the base model is not operationally useful.

>
>    - 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.
>
GIM>> Without output from LTM/LTR Local MEP would not learn identities of
intermediate MPs (MIPs). As result, operator would not be able to localize
the defect. I strongly believe that MIP must be part of the model if we
want the model be operationally useful.

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