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

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: Brian E Carpenter [mailto:[e-mail]] 
发送时间: 2017年10月17日 3:20
收件人: Qin Wu; [e-mail]
抄送: [e-mail]; [e-mail]
主题: 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:[e-mail]]
> 发送时间: 2017年10月14日 12:40
> 收件人: [e-mail]
> 抄送: [e-mail]; 
> [e-mail]
> 主题: 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.
>