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

Alissa Cooper <alissa@cooperw.in> Wed, 25 October 2017 15:21 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: lime@ietfa.amsl.com
Delivered-To: lime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FCF13F3F9; Wed, 25 Oct 2017 08:21:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=f/3i/29c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C1mn57wm
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 rk6Rg1UcVz8Y; Wed, 25 Oct 2017 08:21:07 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1782D13F3F6; Wed, 25 Oct 2017 08:21:07 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 7F23022536; Wed, 25 Oct 2017 11:21:06 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 25 Oct 2017 11:21:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=+8v/Jw5Eyys5Y1Vm1SmOE0kkH/uFv5smbbK7NgdSxqc=; b=f/3i/29c vrU3gHutUCnbaxVTEZL3pyXCIHgXc7gWgoPMPvNDOzjJoV5BvFVkjPXGhkp7yV+M v+U4FzbKGz90IzHfqk9rmbZ33EYKL6wI3tnrqcxY1ELA5/PD2ix3wW6Q3D58tyeT /JuB0acyLlRRvAjQeRjVuc3HKe/1nWKYRn9FcZYoNpUfWucF9GrNlI8NByaNJn2w cbd66Vis2yhP0pNwI6kft33hN6Erew2ABPiVnBnOSTKWXIVEFUyssDEBwJ010RCB 3KbabD46QNl5Uq4FaT01g1+2Mo+tGiUMPex4vqWMhTOl2K+zxAwcxVpW4EMxWc+3 9AdCyGqOtZCSiw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+8v/Jw5Eyys5Y1Vm1SmOE0kkH/uFv 5smbbK7NgdSxqc=; b=C1mn57wmNFAB5Pky3CJ8J+hpeNug1ZvAC4ufBtCn5OJnd ipEg26OZ47ixtzeDO4/ZddEZP+dZOj7W8kuH7bLX+VJ5RO7GmSFBScw27KiL+QT/ eJmNXpaFZCI3EHBUIyRzy3EaUNflP6IGyjn2ljXI/7zGLFJQwuc9eifo1ging3Ec Ni5N4F9caQhUwQ8Pkp/VILtwtsQIhV11eayozbudvshsry3CDY9GTJ5uIxuGnVb5 q2kWgIkZ1n+uNRMPXJi6498d52sRILtsVD4E63LatdpOqxdEovk6FTtDQApZsyPv N9VBTFzOQPDmxHMMfSSJj8vcwf9ytDMkqH2slqqpQ==
X-ME-Sender: <xms:4qvwWdADxYTowaET-DgXET8EfR2H5CNOhQJkptESpUh7mDV3ZN4_zw>
Received: from sjc-alcoop-88113.cisco.com (unknown [128.107.241.191]) by mail.messagingengine.com (Postfix) with ESMTPA id AF8A57FAC6; Wed, 25 Oct 2017 11:21:04 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D83C87D6-88DA-4B22-B281-62A2C2A670A8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9AC024E6@nkgeml513-mbx.china.huawei.com>
Date: Wed, 25 Oct 2017 11:21:01 -0400
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>
Message-Id: <64FD9878-6B7F-488E-B78B-9878EA286877@cooperw.in>
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>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lime/yAh9IHi0c3TDHNMZA6naK4oJctU>
Subject: Re: [Lime] [Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09
X-BeenThere: lime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Layer Independent OAM Management in Multi-Layer Environment \(LIME\) discussion list." <lime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lime>, <mailto:lime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lime/>
List-Post: <mailto:lime@ietf.org>
List-Help: <mailto:lime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lime>, <mailto:lime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Oct 2017 15:21:10 -0000

> On Oct 19, 2017, at 4:38 AM, Qin Wu <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 ...

Alissa

> Thanks!
>  
> -Qin
> 发件人: Greg Mirsky [mailto:gregimirsky@gmail.com <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 <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 <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 <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 <https://www.ietf.org/mailman/listinfo/gen-art>