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:gregimirsky@xxxxxxxxx]
发送时间: 2017年10月24日 20:56
收件人: Qin Wu
抄送: ietf@xxxxxxxx; draft-ietf-lime-yang-connectionless-oam-methods@xxxxxxxx; Carlos Pignataro; Ron Bonica; lime-chairs@xxxxxxxx; Benoit Claise; lime@xxxxxxxx
主题: 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.
On Sun, Oct 22, 2017 at 8:34 PM, Qin Wu <bill.wu@xxxxxxxxxx> 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
Dear All,
please kindly consider my comments on draft-ietf-lime-yang-connectionless-oam-methods
presented below:
-
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.
On Wed, Oct 11, 2017 at 6:41 AM, The IESG <iesg-secretary@xxxxxxxx> 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,
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
ietf@xxxxxxxx mailing lists by 2017-10-25. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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.
_______________________________________________
Lime mailing list
Lime@xxxxxxxx
https://www.ietf.org/mailman/listinfo/lime
|