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

[Huub van Helvoort <[e-mail]>]

All,

I agree with all the remarks made by Greg.

Note that LBM/LBR and LTM/LTR are on-demand tools and will never
be used to pro-actively detect mis-connection defects.

See G.8013/Y/1731 clauses 7.2 and 7.3

Best regards, Huub.


On 09/02/2017 18:01, Greg Mirsky wrote:

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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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.

•  https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5" target="_blank" rel="nofollow">3.5. Test Point Locations

• "routing instance vrf name if required" https://tools.ietf.org/html/draft-zhang-mpls-tp-yang-oam-03" target="_blank" rel="nofollow">YANG Data Model for MPLS-TP OAM  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" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/lime

 

_______________________________________________
Lime mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lime" rel="nofollow">https://www.ietf.org/mailman/listinfo/lime

-- 
================================================================
Always remember that you are unique...just like everyone else...