Subject: RE: Last Call: <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

From: "Vengada Prasad Govindan (venggovi)" <[email-masked]>
Date: Thu, 12 Oct 2017 09:49:08 +0000

As a team member implementing OAM protocols consuming this model, I have read the draft and support progressing it.
Thanks
Prasad

-----Original Message-----
From: IETF-Announce [mailto:[email-masked]] On Behalf Of The IESG
Sent: Wednesday, October 11, 2017 7:12 PM
To: IETF-Announce <[email-masked]>
Cc: Carlos Pignataro (cpignata) <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]; Benoit Claise (bclaise) <[email-masked]>; [email-masked]
Subject: Last Call: <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

The IESG has received a request from the Layer Independent OAM Management in the Multi-Layer Environment WG (lime) to consider the following document: - 'Retrieval Methods YANG Data Model for Connectionless Operations,
   Administration, and Maintenance(OAM) protocols'
  <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2017-10-25. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   This document presents a retrieval method YANG Data model for
   connectionless OAM protocols.  It provides technology-independent RPC
   operations for connectionless OAM protocols.  The retrieval methods
   model presented here can be extended to include technology specific
   details.  This is leading to uniformity between OAM protocols and
   support both nested OAM workflows (i.e., performing OAM functions at
   different levels through a unified interface) and interacting OAM
   workflows ( i.e., performing OAM functions at same levels through a
   unified interface).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 20 Oct 2017 05:34:32 -0700

Dear All,
please kindly consider my comments on
draft-ietf-lime-yang-connectionless-oam-methods
presented below:

   - rpc continuity-check:
      - lacks ability to specify test packet generation interval;
      - rpc uses session-packet-statistics and session-error-statistics
      where all packet counters are uint32. Because continuity-check may run
      forever, if count set to -1, counters may overrun. How the
overrun reported
      in session-packet-statistics and session-error-statistics?

In summary, operation of continuity-check test in forever mode is
underdefined.

Regards,
Greg

On Wed, Oct 11, 2017 at 6:41 AM, The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Layer Independent OAM Management
> in
> the Multi-Layer Environment WG (lime) to consider the following document: -
> 'Retrieval Methods YANG Data Model for Connectionless Operations,
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-10-25. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
> _______________________________________________
> Lime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lime
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 23 Oct 2017 03:34:46 +0000

Thanks Greg for additional comments on draft-ietf-lime-yang-connectionless-oam-methods-09.
Similar to the change we proposed for draft-ietf-lime-yang-connectionless-oam-12,
We could set up-limit for statistics data, when up-limit gets reached, we can indicate overrun  count happens.
Thanks!

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月20日 20:35
收件人: [email-masked]; [email-masked]
抄送: Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Dear All,
please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam-methods presented below:

  *   rpc continuity-check:

     *   lacks ability to specify test packet generation interval;
     *   rpc uses session-packet-statistics and session-error-statistics where all packet counters are uint32. Because continuity-check may run forever, if count set to -1, counters may overrun. How the overrun reported in session-packet-statistics and session-error-statistics?
In summary, operation of continuity-check test in forever mode is underdefined.

Regards,
Greg

On Wed, Oct 11, 2017 at 6:41 AM, The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG has received a request from the Layer Independent OAM Management in

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2017-10-25. Exceptionally, comments may be
sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract

_______________________________________________
Lime mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lime

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 24 Oct 2017 05:56:04 -0700

Hi Qin,
thank you for your expedient response.
I don't think that any additional configuration parameter to limit
particular counter or all of them is required. I think that 4294967294 is
natural, intuitive limit for uint32 counters. My questions are rather how
overrun per counter is reported and what is the behavior of the counter
itself upon it has been read to fill in response to an RPC.

Regards,
Greg

On Sun, Oct 22, 2017 at 8:34 PM, Qin Wu <[email-masked]> wrote:

> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2017年10月20日 20:35
> *收件人:* [email-masked]; draft-ietf-lime-yang-connectionless-oam-methods@
> ietf.org
> *抄送:* Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise;
> [email-masked]
> *主题:* Re: [Lime] Last Call: <draft-ietf-lime-yang-
> connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for
> Connectionless Operations, Administration, and Maintenance(OAM) protocols)
> to Proposed Standard
>
>
>
> Dear All,
>
>       forever, if count set to -1, counters may overrun. How the overrun reported

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Oct 2017 02:46:35 +0000

Thanks Greg for feedback. We can remove such up-limit if you like.
Without up-limit for count, we can leave how to report overrun count to implementation details, e.g.,
The device set threshold for overrun value at the local device  based on count range defined in the model,
When it hits such threshold, it can report back to the management system by using notification, however this
Is performed is not scope of this draft.

Note that YANG model focusing on represent the data and define value and range of each parameter.
You can refer to similar example for count related parameters in RFC8194.

-Qin
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2017年10月24日 20:56
收件人: Qin Wu
抄送: [email-masked]; [email-masked]; Carlos Pignataro; Ron Bonica; [email-masked]; Benoit Claise; [email-masked]
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Hi Qin,
thank you for your expedient response.
I don't think that any additional configuration parameter to limit particular counter or all of them is required. I think that 4294967294 is natural, intuitive limit for uint32 counters. My questions are rather how overrun per counter is reported and what is the behavior of the counter itself upon it has been read to fill in response to an RPC.

Regards,
Greg

On Sun, Oct 22, 2017 at 8:34 PM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg for additional comments on draft-ietf-lime-yang-connectionless-oam-methods-09.
Similar to the change we proposed for draft-ietf-lime-yang-connectionless-oam-12,
We could set up-limit for statistics data, when up-limit gets reached, we can indicate overrun  count happens.
Thanks!

-Qin
发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2017年10月20日 20:35
收件人: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
抄送: Carlos Pignataro; Ron Bonica; [email-masked]<mailto:[email-masked]>; Benoit Claise; [email-masked]<mailto:[email-masked]>
主题: Re: [Lime] Last Call: <draft-ietf-lime-yang-connectionless-oam-methods-09.txt> (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard

Dear All,

  *   rpc continuity-check:

Regards,
Greg

Abstract