Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07

Greg Mirsky <gregimirsky@gmail.com> Mon, 20 March 2017 17:17 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3415E13154D for <ippm@ietfa.amsl.com>; Mon, 20 Mar 2017 10:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 54ESN9gFqTdD for <ippm@ietfa.amsl.com>; Mon, 20 Mar 2017 10:17:15 -0700 (PDT)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48698131507 for <ippm@ietf.org>; Mon, 20 Mar 2017 10:15:38 -0700 (PDT)
Received: by mail-ot0-x232.google.com with SMTP id i1so136715572ota.3 for <ippm@ietf.org>; Mon, 20 Mar 2017 10:15:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HOZvd5ViYHRMst/45mwjb+XKWzRnzJ2HVtuNb7w815Y=; b=QbMpbSP4mjXmi5p1rNs9yqPVzTgMm2jcPf1Z9idNsgu8zmgbi/ildgyIbD7GjjjBOj 3RMZsZzuwLDoGwgmGmOQfVQxMy8CvC/88mbzVoM0MGVcbBvsJxYvwJRWMwqa1u+D3f6c M/BOXbBKhkLaz3vLzSNDG1ER34fnk3di/wshePpnrDBV20/up7cZRvZ8sNfjPm4+qgO9 WsTiKpRnd7vvkYFk0J6lI/vHLCPBdnNtxyE1rMOJEap9ycktCifBMIjcqZRGI8A4JW1B +jAmdp6eydhglfNzW0Vec1KyITuaCqO1CoR0jWvfqS78QFuLtXVlE5kJFAaiUaW3KdXl Mobw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HOZvd5ViYHRMst/45mwjb+XKWzRnzJ2HVtuNb7w815Y=; b=Nm9K+H5G0C90Uf84G1FaK3qlSTurgtnseFIEqO6Djsw0oaOSc15bXEIGth5mMrWEvd U3XHNgQPzK50hzcMUuHOGD48v2yNzOZeKSt8CvNJPjTsCATg2xJ+brurNw705BOz4DHC z4g6FYcrvGNztPUUCNFnxBoZ1QMxRUT8we9Ir8RSYRK4jvr/52rsHKoy63hCWDV1XsFX //O2kxdGCRPkbasPyfFYMXLaDtHspAIYAc7zEmLpnQRuHLwMmf7EDUS1oxdBjdVouVlN E9dHAxe9d12mQAjEQguAFisUFrjK3LcfEz/WyKu6/HtZjrwo84nW6KBUG6nUN5CSjvNT GELg==
X-Gm-Message-State: AFeK/H2av6ZUB6z5nHXKb7ZBgUZ7//S5lYqAMruc6goKLipLmJT/SZSnFEgm1Bop33zxs7uH0a441yrdQ79UbA==
X-Received: by 10.157.1.247 with SMTP id e110mr14621281ote.40.1490030137630; Mon, 20 Mar 2017 10:15:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.21.21 with HTTP; Mon, 20 Mar 2017 10:15:37 -0700 (PDT)
In-Reply-To: <HE1PR0701MB2890F93BC8B34C3F304BEBDED7380@HE1PR0701MB2890.eurprd07.prod.outlook.com>
References: <HE1PR0701MB2890F93BC8B34C3F304BEBDED7380@HE1PR0701MB2890.eurprd07.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 20 Mar 2017 12:15:37 -0500
Message-ID: <CA+RyBmWKrvJFRk9Dx+A6LYcN+2F_PoTnkjOU4a3cDHCAHfn8iw@mail.gmail.com>
To: Wei Luo S <wei.s.luo@ericsson.com>
Cc: "ippm@ietf.org" <ippm@ietf.org>, "draft-mirsky-ippm-twamp-light-yang@tools.ietf.org" <draft-mirsky-ippm-twamp-light-yang@tools.ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c03b82a0ee907054b2cadcd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/rN3Yjg0SkBn0wYkniVG9DaZ_9fI>
Subject: Re: [ippm] Some though on draft-mirsky-ippm-twamp-light-yang-07
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2017 17:17:19 -0000

Hi Wei Luo,
many thanks for your thorough review and the most helpful comments to the
TWAMP Light(Test) model. Please find my answers, notes in-line tagged GIM>>.

Regards,
Greg

On Sat, Mar 18, 2017 at 4:27 AM, Wei Luo S <wei.s.luo@ericsson.com> wrote:

> Hi Greg & Adrian,
>
>
>
> This is Wei Luo from Ericsson. I work on TWAMP light area in Ericsson. The
> current TWAMP Light YANG model is well defined. Thanks for your great job.
>
> But by working closely with our customers, we got some new user cases on
> TWAMP light. I believe these user cases are valuable and popular enough to
> be modeled in TWAMP Light YANG. I hope I can be a contributor  and co-work
> with you move this draft forward.
>
> I  drafted a new version of the TWAMP light YANG model based on version
> ietf-twamp-light@2017-02-13.yang. Could you please comments on it? Any
> discussion is welcome.
>
> The draft yang model and tree is attached. To make you find the updates
> quickly, I highlighted all the updates in file
> ietf-twamp-light-weiluo.pdf.
>
>
>
> The following are the list of main updates:
>
> *1. Add a new typedef: percent. This is a new type defined for packet loss
> ratio.*
>
> Consideration:
>
> 1). From the customer perspective, packet loss ratio is a more meaningful
> data. In most of the time, the absolute number is meaningless to user,
> especially they do the TWAMP test continuously. They are more care about
> the ratio than the absolute number. So adding it makes this model more
> friendly to customer;
>
> 2). From the service layer assurance(SLA) perspective, the packet loss
> ratio is a major measures. So with adding packet loss ratio in model, the
> TWAMP can work in SLA framework more smoothly.
>
> 3). It seems some similar protocol’s YANG model has the same definition,
> e.g. ‘Service OAM Performance Monitoring YANG Module’,
> https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_39.pdf.
>
GIM>> Indeed, packet loss more often expressed as packet loss ratio rather
than as the absolute number. It would be most helpful to hear from network
operators if they see introduction of Packet Loss Ratio into the TWAMP
model helpful.

*2. Add a new typedef: state-mode. It defines a common type for
> stateful/stateless reflector. This type will be used in both sender session
> and reflector session.*
>
> Consideration:
>
> If the reflector is stateful, the TWAMP light can measure more items, e.g.
> one way packet loss. So for sender, the stats calculation and show is
> different. When the reflector is stateless, it doesn’t need to calculate
> the one way packet loss. The one way packet loss is invalid and shouldn’t
> be presented to customer. When the reflector is stateless, the sender needs
> to calculate the one way packet loss. And the data should be present to
> customer. So this is used as a ‘when’ condition in the model’s RO tree.
>
GIM>> Yes, if Session-Sender is aware of the mode corresponding
Session-Reflector operates, the sender may avoid calculation of some
performance metrics, e.g., one-way packet loss. On the other hand, the
orchestrator is aware of the state-mode and should be capable to properly
use metrics reported by the Session-Sender.

> *3. Add a new typedef: send-mode. This is a new type for sender session.
> It makes the sender session can send packet continuously and monitor the
> network all the time.*
>
> Consideration:
>
> The user case is that: the user runs TWAMP light sessions to watch links
> quality continuously. The session number could be very big. These TWAMP
> sessions are managed by SLA framework or similar. SLA retrieves the stats
> from TWAMP periodically, e.g. 15mins. In other words, all the performance
> metrics are calculated based on the packets sent/received within 15mins.
> This makes the calculation become possible. With the periodical stats data,
> the Network Management software can do further actions if some abnormal
> stats observed.  This is a more general user case in customer site. While
> the non-continuous TWAMP sender session is generally used for debugging
> purpose on a link.
>
GIM>> I think that support of continuous measurement is in LMAP domain, not
for TWAMP Test data model. To conduct continuous measurement he LMAP
Controller, in my opinion, programs the Measurement Agent to perform TWAMP
Test session with certain set of parameters and repeat it without any
interval (interval = 0).

> *4. Add a new group: packet-loss-statistics. It grouping two packet loss
> statistics: loss-count and loss-ratio. This group will be used in RO stats
> tree.*
>
GIM>> I'd like to continue discussion.

> *5. Move leaf dscp out from grouping session-light-parameters. The leaf
> dscp is only valid when the dscp-handling-mode is use-configured-value. A
> when condition shall be added to it. So it can’t be in this group.*
>
GIM>> I'm concerned that then the model will not be able to support
concurrent TWAMP Test sessions between the same pair of Test Points (IP
address+port number) at different CoS markings.

> *6. Add leaf 'session-packet-send-mode' to
> /twamp-light/twamp-light-session-sender/test-session*. This leaf specifies
> the sender session's packet send mode: continuous or non-continuous.*
>
GIM>> As discussed in #3, I think that it is already part of LMAP YANG
model.

> *7. Add leaf 'reflector-light-mode-state' to
> /twamp-light/twamp-light-session-sender/test-session*. This leaf indicates
> the the reflector's mode: stateful or stateless. If the reflector's mode is
> stateful. Two one way packet loss statistics can be got:
> one-way-packet-loss-far-end, one-way-packet-loss-near-end.*
>
> Consideration:
>
> Only valid data should be presented to user. Otherwise it could misleading
> user in some cases.
>
GIM>> A in response to #2.

> *8. Modify leaf
> /twamp-light/twamp-light-session-sender/test-session*/number-of-packets.
> Add a 'when' condition to this leaf. When send-mode is 'continuous', the
> leaf number-of-packets is meaningless. So add a 'when' condition to limit
> it.  Besides, added a default value ‘10’ to it. When the send-mode is
> 'non-continuous', the session can't work with an empty number-of-packets.*
>
GIM>> As I've noted in #3. Will add default.

> *9. Add leaf time out to
> /twamp-light/twamp-light-session-sender/test-session*. A timeout mechanism
> is needed when the sender session can't get all the reply packets for a
> long time.*
>
GIM>> Thank you, will add in the next update.

> *10. Modify leaf
> /twamp-light/twamp-light-session-sender/test-session*/interval. Change the
> units from ‘microseconds’ to ‘milliseconds’. Add a default value 1000. *
>
> Consideration:
>
>     1). The aim of TWAMP is to measure network quality, but not fast
> failure detection. So a millisecond packet interval is enough.
>
>     2). Interval is a necessary parameter for a session. A sender session
> can't work with an empty packet send interval. So added a default value to
> it.
>
GIM>> Thank you. We've made units of interval microseconds in the last
update already. I think that changing to milliseconds may be too
restrictive, limit use cases for TWAMP Test. Will add default value with
the next update.

> *11. Add leaf 'dscp' to
> /twamp-light/twamp-light-session-sender/test-session*. This is the leaf
> moved out from grouping session-light-parameters.*
>
GIM>> As noted in response #5, the change may limit ability to run
concurrent TWAMP Test sessions per CoS. I consider that to be valuable mode
but would like to hear from network operators if that is indeed useful
information.

> *12. Move leaves 'ref-wait', 'reflector-light-mode-state' and
> 'dscp-handling-mode' from /twamp-light/twamp-light-session-reflector to
> /twamp-light/twamp-light-session-reflector/test-session*. These three
> attributes should be session specific. Different session could have
> different values. They are not common attributes.*
>
GIM>> Agree, will make it in the next update.

> *13. Add leaf 'dscp' to
> /twamp-light/twamp-light-session-reflector/test-session*. This is the leaf
> moved out from grouping session-light-parameters. Besides the movement,
> added a 'when' condition to the leaf 'dscp'. This leaf is only valid when
> the dscp-handling-mode is 'use-configured-value'.*
>
GIM>> As response to #5.

> *14. Modify leaf
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/number-of-packets.
> Add a 'when' condition to this leaf. When send-mode is 'continuous', the
> leaf number-of-packets is meaningless.*
>
GIM>> Similar to #3.

> *15. Modify leaf
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/interval.
> Change the units from microseconds to milliseconds.*
>
GIM>> I think that microseconds is reasonable.

> *16. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and
> 'one-way-packet-loss-near-end' to
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats/.
> These are the new statistics for stateful reflector.*
>
GIM>> Thank you, will be coming in the next update.

> *17. Remove leaf loss-packet in
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/current-stats.
> The loss packeted is replaced with 'two-way-packet-loss' stated above.*
>
GIM>> Agree.

> *18. Modify leaf to
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/interval.
> Change the units from microseconds to milliseconds.*
>
GIM>> I think that will limit applicability of TWAMP Test.

> *19. Add leaves 'two-way-packet-loss', 'one-way-packet-loss-far-end' and
> 'one-way-packet-loss-near-end' to
> /twamp-light-state/twamp-light-session-sender-state/test-session-state*/history-stats*/.
> These are the new statistics for stateful reflector.*
>
GIM>> Agree.


> Thanks,
>
> Wei Luo
>