[ippm] TWAMP YANG data models
Greg Mirsky <gregimirsky@gmail.com> Wed, 07 September 2016 16:27 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 81E1612B384 for <ippm@ietfa.amsl.com>; Wed, 7 Sep 2016 09:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] 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 R4DkR5w1bv4c for <ippm@ietfa.amsl.com>; Wed, 7 Sep 2016 09:26:58 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 C2C0C12B226 for <ippm@ietf.org>; Wed, 7 Sep 2016 09:26:58 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id l8so12298205ywb.0 for <ippm@ietf.org>; Wed, 07 Sep 2016 09:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=lcut9W6rbRrQY/sWrHeiesZVL7WW5Ovr4tRY2Ec+EmQ=; b=RbClhes0LXcqMbs7AI6h6DUkgNKiXhLaxNGkBSEjRS9RGMup5DXQrk9u355Ah8e5e5 0vKwEbaO2E02Dqkkc+pZT0ydI1difN33oqtVTxEmViyPA+qTpaDf79PUQeRCBgt6k6/L zEfD6RYWi55kUVgsbgVu2/KtwUm71svCM2UTsnjvJziX8a3BmAe27vaEjTNHcVdD1rWo wzlnNxGR9R3DVldPnDjEjeA4ZJwYuWZ6ciFhRabwNQY3R9jx+n4g3B7X3CunIgVS3LWS +g0dlcTJFhwP3RMaN+d9RncHql/6cVZlZVG95/CUmGIoS66R8wxYpifO4pNvsqQxIM2+ YiOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lcut9W6rbRrQY/sWrHeiesZVL7WW5Ovr4tRY2Ec+EmQ=; b=j6VMTC3Ch9FtaRYE7/qs6q70p+uDUhxBIljG8eHDUIiUN8QZlM5xrlGQrhpcmsG3Fc bC4tCwyFhUgPKZo0gcxHWQEjduAILiTb2znzTJph0cI8xD0ONY2d4ZlxQCJHItAYqrgS OrIlGp3KfhsugT9sO1I04ESe1d9Me08I67Ca6xfwGYt+uqlFdrn2q9mDFal4DjE9D9JG RqvJSc/PcC6dUlG8eIu8Q4YqFk8dXnrMjjEf3chOu5RZPIzz5FoSVvQPX5K1L6zepzO8 ol/KO0mcryDuTMG2s9HLQW0ZuATVGCMUQVpap9BwPFo+NJ2/B0OLEhaLX7Z3MIrV36bG PXow==
X-Gm-Message-State: AE9vXwPxDQZZbpnUlrCavuHOJMzC+lgYiihpZ4aX6BwXICcsu/MFmbXmON/S5btoSgIG38IIPT1uAIhAvKCG1g==
X-Received: by 10.129.30.214 with SMTP id e205mr37892416ywe.118.1473265618046; Wed, 07 Sep 2016 09:26:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.15.2 with HTTP; Wed, 7 Sep 2016 09:26:57 -0700 (PDT)
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 07 Sep 2016 09:26:57 -0700
Message-ID: <CA+RyBmWuJXZyxiPEZb8-s4H5MuELwKYG77Yg9tvEb0RMJGMExA@mail.gmail.com>
To: draft-ietf-ippm-twamp-yang@tools.ietf.org, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="001a1142e364d2f64e053bed6149"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/q2RSxgMwlw6ve44DGdHk_wiKF84>
Subject: [ippm] TWAMP YANG data models
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 07 Sep 2016 16:27:00 -0000
Dear Authors, All in our meeting in Berlin I've shared my concern with the draft-ietf-ippm-twamp-yang. These are my comments: - Figure 2 presents view of how YANG data model my be used. I believe that in SDN environment the Orchestrator may act more like described in draft-mirsky-ippm-twamp-light-yang-03 Figure 1 where Session-Sender and Session-Reflector are configured directly without Server and Control-Client by the single SDN controller/configuration client; - even though TWAMP-Control is optional, one possible solution to control TWAMP-Test, TWAMP-Test dataa model depends on TWAMP-Control data model. For example: leaf ctrl-connection-name { type string; config false; description "The name of the parent TWAMP-Control connection that is responsible for negotiating this TWAMP-Test session."; } in list test-session, which is in session-sender; - as I look into session-sender YANG model I don't see it contains sender-ip, sender-udp-port, reflector-ip, reflector-udp-port, and test-packet-dscp. I believe that without these session-sender cannot be used to instantiate TWAMP test session without the TWAMP-Control; - I think that the test session state information provided by maintenance-statistics should be extended, e.g. with the container current-stats as in draft-mirsky-ippm-twamp-light-yang-03; - purpose of parent_connection_XXX in session_reflector is not clear to me. According to the last paragraph of section 4.4 four-tuple {parent-connection-client-ip, parent-connection-client-tcp-port, parent-connection-server-ip, parent-connection-server-tcp-port} define the test session but that, in my view, is only in some scenarios when TWAMP-Test session instantiated via TWAMP-Control. I believe that in SDN environment, where TWAMP-Control use is not required, identities of Control Client and the Server are not used; - grouping maintenance-statistics used in both session-sender and session-reflector. If the purpose of the grouping to provide information about the measured parameters, then, in my view, it is too limited and should be extended. If the grouping is to provide information for debugging, then it seems as more proprietary rather than standard data. Regards, Greg
- [ippm] TWAMP YANG data models Greg Mirsky