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

Brian, thank you for your review. Qin, thanks for your responses. I have entered a No Objection ballot that captures the remaining open issue concerning one-way vs. two-way delay. One further comment below.

> On Oct 18, 2017, at 9:09 PM, Qin Wu <bill.wu@huawei.com> wrote:
> 
> -----邮件原件-----
> 发件人: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> 发送时间: 2017年10月19日 3:26
> 收件人: 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
> 
> On 17/10/2017 14:40, Qin Wu wrote:
> ...
> 
>>> 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 don't see how this specification can be used for interoperable implementations unless you define a specific meaning of 'jitter'.
> 
> If the network management system assumes RFC3393 but half the routers in the network implement G.1020, there is no interoperability.

I believe this is well-specified in draft-ietf-lime-yang-connectionless-oam:

grouping session-jitter-statistics {
    description
      "Grouping for per session jitter statistics";
    container session-jitter-statistics {
      description
        "Session jitter summarised information. By default,
         jitter is measured using IP Packet Delay Variation
         (IPDV) as defined in RFC3393 <https://tools.ietf.org/html/rfc3393>. When the other measurement
         method is used instead(e.g., Packet Delay Variation used in
         Y.1540, it can be indicated using protocol-id-meta-data
         defined in RPC operation of
         draft-ietf-lime-yang-connectionless-oam-methods <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-methods>. Note that
         only one measurement method for jitter is specified
         for interoperability reason.";

Alissa

> 
> [Qin]: Correct, Just to clarify, it is not our intent to encourage implementer to support various different mechanisms to measure jitter in one single solution.
> In one single solution, we will restrict to use one mechanism, one protocol to measure jitter, but flexibility we allow here, you might choose different time units,
> But again we might only allow one time unit in one single solution, introduce protocol-id parameter is used to allow future protocol and future mechanism to be created then we support different mechanism to measure 
> Jitter with different time unit.
> 
>> 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. 
> 
> Again - it is useful to specify one-way delay, for interoperability.
> (Whether the routers can measure one-way delay is another question; they might be forced to measure RTT and assume delay = RTT/2 .)
> 
> [Qin]: Agree, have a second thought, I think with protocol-id, we can decide which kind of delay we are meant to use? E.g.,if protocol-id is set to OWAMP defined in RFC4656, we will use one way delay, if protocol-id is set to TWAMP defined in RFC5357,We will use round trip delay, we allow such flexibility, I might be wrong, since earlier, I claim we only support one way delay, I need to confirm this from other authors.
> 
> Regards
>    Brian
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art