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

Qin Wu <bill.wu@huawei.com> Thu, 26 October 2017 00:58 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C336139F18; Wed, 25 Oct 2017 17:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xf_Bl-Mqw_q; Wed, 25 Oct 2017 17:58:32 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBB241395F3; Wed, 25 Oct 2017 17:58:30 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYL29289; Thu, 26 Oct 2017 00:58:28 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 01:58:27 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.105]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 26 Oct 2017 08:58:22 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Alissa Cooper <alissa@cooperw.in>
CC: Greg Mirsky <gregimirsky@gmail.com>, "draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org" <draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "lime@ietf.org" <lime@ietf.org>
Thread-Topic: [Gen-art] [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09
Thread-Index: AQHTRKaA49fkPiL3ME2fuGmwswL1zaLmVrbggAABfwCAAOm9MIABsjUAgAHrTxCACVrbgIABJuvw
Date: Thu, 26 Oct 2017 00:58:22 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AC172F5@nkgeml513-mbx.china.huawei.com>
References: <150795599146.4998.1974521980268023090@ietfa.amsl.com> <B8F9A780D330094D99AF023C5877DABA9ABE743C@nkgeml513-mbx.china.huawei.com> <edb94719-d385-1b6f-ad04-2132db9c3111@gmail.com> <B8F9A780D330094D99AF023C5877DABA9ABF3D69@nkgeml513-mbx.china.huawei.com> <CA+RyBmW4pSb3yDf+YoJkAqU4p8iU7QQp25hGFvM3vohAs0Msbg@mail.gmail.com> <B8F9A780D330094D99AF023C5877DABA9AC024E6@nkgeml513-mbx.china.huawei.com> <64FD9878-6B7F-488E-B78B-9878EA286877@cooperw.in>
In-Reply-To: <64FD9878-6B7F-488E-B78B-9878EA286877@cooperw.in>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.163]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AC172F5nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59F13335.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c133fb2e94463d42e7a1d679dee4153a
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/VGG_02HfVfskU0NsL4_hqGIPuQU>
Subject: Re: [Gen-art] [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Oct 2017 00:58:35 -0000

发件人: Alissa Cooper [mailto:alissa@cooperw.in]
发送时间: 2017年10月25日 23:21
收件人: Qin Wu
抄送: Greg Mirsky; draft-ietf-lime-yang-connectionless-oam-methods.all@ietf.org; gen-art@ietf.org; lime@ietf.org
主题: Re: [Gen-art] [Lime] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09


On Oct 19, 2017, at 4:38 AM, Qin Wu <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> wrote:

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";
  }
”

Qin, although you use the term “time-resolution” above, it does not appear in the LIME YANG models. The term in the models appears to be time-interval-type.

I sense that this might be confusing (based on Greg’s message) because what is actually being defined by time-interval-type is the unit of measurement (e.g., ns, ms, s). I realize that in a sense this is an interval, but it might be clearer if the type were called time-unit-type. If I’m understanding it properly, then the definition that Greg is pointing to in the TICTOC doc is for something different (i.e., an actual interval, always measured in nanoseconds).

But it’s also possible that I’m the one who is confused ...

[Qin]: I agree with you the name “time-interval-type” is confusing which I was struggling as well when I posted  v-(10).
You are correct, we should change it to “time-unit-type”, I will fix this in the new version. Thanks for catching this.

Alissa


Thanks!

-Qin
发件人: Greg Mirsky [mailto:gregimirsky@gmail.com]
发送时间: 2017年10月18日 19:11
收件人: Qin Wu
抄送: Brian E Carpenter; 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: [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

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org<mailto:Gen-art@ietf.org>
https://www.ietf.org/mailman/listinfo/gen-art