Re: [Gen-art] [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> wrote:

> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> 发送时间: 2017年10月17日 3:20
> 收件人: Qin Wu; gen-art@ietf.org
> 抄送: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org;
> 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]
> > 发送时间: 2017年10月14日 12:40
> > 收件人: gen-art@ietf.org
> > 抄送: draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org;
> > 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
> https://www.ietf.org/mailman/listinfo/lime
>