Re: [Gen-art] [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Thanks Greg, As I said, Delay supports various time units which include Nanoseconds. Nanosecond time unit has been supported by using identity in connectionless-oam-method model
“
  identity seconds {
    base time-resolution;
    description
      "Time resolution in Seconds";
  }
  identity milliseconds {
    base time-resolution;
    description
      "Time resolution in Milliseconds";
  }
  identity microseconds {
    base time-resolution;
    description
      "Time resolution in Microseconds";
  }
identity nanoseconds {
    base time-resolution;
    description
      "Time resolution in Nanoseconds";
  }
”
Thanks!

-Qin
发件人: Greg Mirsky [mailto:gregimirsky@gmail.com]
发送时间: 2017年10月18日 19:11
收件人: Qin Wu
抄送: Brian E Carpenter; gen-art@ietf.org; draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org; lime@ietf.org
主题: Re: [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Hi Qin, et. al,
IEEE 1588-2008 in section 5.3.2 defines the TimeInterval type that represents time interval as
struct TimeInterval
{
Integer64 scaledNanoseconds;
};
The scaledNanoseconds member is the time interval expressed in units of nanoseconds and multiplied by
2+16.
Positive or negative time intervals outside the maximum range of this data type shall be encoded as the
largest positive and negative values of the data type, respectively.
For example, 2.5 ns is expressed as 0000 0000 0002 800016.

TICTOC WG is discussing proposed PTP YANG model which includes

     typedef time-interval-type {

       type int64;

       description

         "Derived data type for time interval,

         represented in units of nanoseconds and

         multipled by 2^16";

       reference

         "IEEE Std 1588-2008: 5.3.2";

     }
Would the it be re-usable in LIME?

Regards,
Greg

On Mon, Oct 16, 2017 at 6:40 PM, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:
-----邮件原件-----
发件人: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>]
发送时间: 2017年10月17日 3:20
收件人: Qin Wu; gen-art@ietf.org<mailto:gen-art@ietf.org>
抄送: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org<mailto:draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org>; lime@ietf.org<mailto:lime@ietf.org>
主题: Re: Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09

Qin,

Thanks for the reply, I have follow-up questions in line:

On 17/10/2017 00:52, Qin Wu wrote:
> Thank Brian for valuable review to this document, please see my reply below.
>
> -Qin
> -----邮件原件-----
> 发件人: Brian Carpenter [mailto:brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>]
> 发送时间: 2017年10月14日 12:40
> 收件人: gen-art@ietf.org<mailto:gen-art@ietf.org>
> 抄送: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org<mailto:draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org>;
> lime@ietf.org<mailto:lime@ietf.org>
> 主题: Genart telechat review of
> draft-ietf-lime-yang-connectionless-oam-methods-09
>
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
>
> Gen-ART *Last Call* review of
> draft-ietf-lime-yang-connectionless-oam-methods-09
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.
>
> For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-lime-yang-connectionless-oam-methods-09.txt
> Reviewer: Brian Carpenter
> Review Date: 2017-10-14
> IETF LC End Date: 2017-10-25
> IESG Telechat date: 2017-10-26
>
> Summary: Ready with issues
> --------
>
> Comment:
> --------
>
> The shepherd says:
>
>> This includes at least two different implementations of the model, as
>> well as product and demos at Bits-n-Bytes.
>
> Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving Awareness of Running Code: The Implementation Status Section"?
>
> Minor Issues:
> -------------
>
> In the following:
>
>          |  +--ro min-delay-value?         uint32
>          |  +--ro max-delay-value?         uint32
>          |  +--ro average-delay-value?     uint32
>          +--ro session-jitter-statistics
>          |  +--ro time-resolution-value?   identityref
>          |  +--ro min-jitter-value?        uint32
>          |  +--ro max-jitter-value?        uint32
>          |  +--ro average-jitter-value?    uint32
>
> what are the units for the delay-value and jitter-value elements, and what definition of 'jitter' is intended?
>
> [Qin]: Delay supports various time units such as s,ms,ns and etc.
> To represent this using YANG construct, we introduce a new parameter time-resolution-value as follows:
>    |     +--ro session-delay-statistics
>    |     |  +--ro time-resolution-value?   identityref
>    |     |  +--ro min-delay-value?         uint32
>    |     |  +--ro max-delay-value?         uint32
>    |     |  +--ro average-delay-value?     uint32
> With this time-resolution-value parameter, we can support various different time unit.

OK, because of my poor understanding of YANG, I still have to ask where the possible values of time-resolution-value are defined. Is there an enumeration somewhere that I have missed?
[Qin]:Instead of using enum, we are using identity to define possible values of time-resolution-value
"
  identity time-resolution {
    description
      "Time interval resolution";
  }
  identity seconds {
    base time-resolution;
    description
      "Time resolution in Seconds";
  }
  identity milliseconds {
    base time-resolution;
    description
      "Time resolution in Milliseconds";
  }
  identity microseconds {
    base time-resolution;
    description
      "Time resolution in Microseconds";
"
And then we can use identityref to refer to these values of time-resolution values we have actually defined.

> The same is applied to jitter. As clarified in the introduction, the
> definition of 'jitter' is used to monitor reachability of destinations, troubleshoot failures, monitor performance.

Yes, but what *is* jitter physically? There is no scientific definition of 'jitter' in the IETF. Do you mean IPDV as defined in RFC3393 or something else?

[Qin]:Jitter is packet jitter (https://en.wikipedia.org/wiki/Jitter). You are right, one typical example of packet jitter is IPDV defined in RFC3393, but we don't want to limit it to IPDV, we also allow support other protocol and other measurement methodology,
e.g., we could also consider to use MAPDV2 defined in [ITU-T G.1020], what protocol is used and what methodology is used can be indicated by the parameter 'protocol-id' parameter and 'protocol-id-meta-data' in this model.

I assume that by 'delay' you mean RFC7679 rather than RFC2681, but that seems straightforward,  and so do the other metrics used in session-packet-statistics and session-error-statistics.

[Qin]: Correct, it is one way delay instead of two way delay. Yes, the same is applied to session-packet-statistics and session-error-statistics.

Regards
    Brian

>
>   identity protocol-id-internet {
>     base protocol-id;
>     description
>       "Internet Protocols.";
>   }
>
> It isn't clear what "Internet Protocols" means. It seems totally non-specific.
>
>
> [Qin]: It is referred to a standard protocol (e.g., TCP/IP protocols,
> ICMP, IGMP,etc.,) We can make this clear by adding a few clarification text in the description of protocol-id-internet.
> Nits:
> -----
>
>   identity protocol-id-propreitary {
>     base protocol-id;
>     description
>       "Propreitary protocol (eg.,IP SLA).";
>
> s/propreitary/proprietary/
> s/Propreitary/Proprietary/
>
> [Qin]: Thanks and will get this fixed.
>

_______________________________________________
Lime mailing list
Lime@ietf.org<mailto:Lime@ietf.org>
https://www.ietf.org/mailman/listinfo/lime