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

From: wangzitao <[email-masked]>
Date: Wed, 8 Feb 2017 02:00:41 +0000

Hi Greg

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

Best Regards!

-Michael

发件人: Lime [mailto:[email-masked]] 代表 Greg Mirsky
发送时间: 2017年2月1日 2:07
收件人: Ron Bonica
抄送: [email-masked]; [email-masked]
主题: 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 <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 9 Feb 2017 09:01:55 -0800

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 <[email-masked]> wrote:

> *发件人:* Lime [mailto:[email-masked]] *代表 *Greg Mirsky
> *发送时间:* 2017年2月1日 2:07
> *收件人:* Ron Bonica
> *抄送:* [email-masked]; [email-masked]
> *主题:* Re: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08
>
>
>
>    - 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.
>
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.
>
>    -  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
>
> [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.
>
>    - 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
>
>    - 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.
>
>    - 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/
>
>    -
> On Thu, Jan 19, 2017 at 8:13 AM, Ron Bonica <[email-masked]> wrote:
>
> Folks,
>
> [email-masked]

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 9 Feb 2017 20:13:27 +0100

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 <[email-masked]>
wrote:

Hi Greg

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

Best Regards!

-Michael

发件人: Lime
[mailto:[email-masked]]
代表 Greg
Mirsky

发送时间: 2017年2月1日
2:07

收件人: Ron Bonica

主题: 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. Test Point
Locations

"routing instance vrf
name if required" 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/

I
cannot support publication of this
version of the document.

Regards,

Greg

On
Thu, Jan 19, 2017 at 8:13 AM, Ron Bonica
<[email-masked]>
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

[email-masked]

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