Re: [lmap] I-D Action: draft-ietf-lmap-information-model-12.txt

"Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylink.com> Wed, 16 November 2016 15:57 UTC

Return-Path: <Michael.K.Bugenhagen@centurylink.com>
X-Original-To: lmap@ietfa.amsl.com
Delivered-To: lmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530E7129639 for <lmap@ietfa.amsl.com>; Wed, 16 Nov 2016 07:57:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-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 0FW4Cjxq-ARN for <lmap@ietfa.amsl.com>; Wed, 16 Nov 2016 07:56:56 -0800 (PST)
Received: from lxdnp29m.centurylink.com (lxdnp29m.centurylink.com [155.70.32.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F055129545 for <lmap@ietf.org>; Wed, 16 Nov 2016 07:56:56 -0800 (PST)
Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by lxdnp29m.centurylink.com (8.14.8/8.14.8) with ESMTP id uAGFuoZj021330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2016 08:56:50 -0700
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id BAF541E0058; Wed, 16 Nov 2016 08:56:44 -0700 (MST)
Received: from lxdnp31k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A16D71E007E; Wed, 16 Nov 2016 08:56:44 -0700 (MST)
Received: from lxdnp31k.corp.intranet (localhost [127.0.0.1]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id uAGFui7m006617; Wed, 16 Nov 2016 08:56:44 -0700
Received: from vodcwhubex502.ctl.intranet (vodcwhubex502.ctl.intranet [151.117.206.28]) by lxdnp31k.corp.intranet (8.14.8/8.14.8) with ESMTP id uAGFuiTr006611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Nov 2016 08:56:44 -0700
Received: from PODCWMBXEX505.ctl.intranet ([fe80::f87e:fe44:ad72:b610]) by vodcwhubex502.ctl.intranet ([151.117.206.28]) with mapi id 14.03.0294.000; Wed, 16 Nov 2016 09:56:43 -0600
From: "Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylink.com>
To: "philip.eardley@bt.com" <philip.eardley@bt.com>, "j.schoenwaelder@jacobs-university.de" <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [lmap] I-D Action: draft-ietf-lmap-information-model-12.txt
Thread-Index: AQHSM8bRsvjT24vr006+fLPOTN+8+KDbYe+AgABsvwCAAAnHAIAAZL+A//+fS4A=
Date: Wed, 16 Nov 2016 15:56:43 +0000
Message-ID: <7FFD36A0-01E6-43C4-B3DB-094421BCCEB1@centurylink.com>
References: <147795313794.23217.15358328180744934565.idtracker@ietfa.amsl.com> <4D7F4AD313D3FC43A053B309F97543CF6469E5@njmtexg5.research.att.com> <76980d09da0a4bc2a0dcfd987be82e94@rew09926dag03b.domain1.systemhost.net> <20161116094216.GB51980@elstar.local> <217244c70df845bd82d4fa159f53ad50@rew09926dag03b.domain1.systemhost.net>
In-Reply-To: <217244c70df845bd82d4fa159f53ad50@rew09926dag03b.domain1.systemhost.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1c.0.161115
x-originating-ip: [155.70.16.191]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0CF1A9B0E664AD499B32D39233B9E2A0@centurylink.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/lmap/drspyNF2VDWoGwgJuAKiaf9nPEU>
Cc: "acmorton@att.com" <acmorton@att.com>, "lmap@ietf.org" <lmap@ietf.org>
Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-12.txt
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Large Scale Measurement of Access network Performance <lmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lmap>, <mailto:lmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lmap/>
List-Post: <mailto:lmap@ietf.org>
List-Help: <mailto:lmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lmap>, <mailto:lmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 15:57:00 -0000

Phil, Juergen,

I apologize ahead of time for the long-winded retrospect… but here’s something I’ve run across you may be able to consider in your framework.

        I reviewed the draft, and one thing that seems to be missing here is any “NAK” from the test server when it’s busy or overloading.

Given the MA’s can automatically delay testing due to “cross traffic” there should be some CAC state tracking so Op’s knows what is happening when tests don’t get run because the test server was busy.    This is kind of controller 101 for capacity planning, and ops’ traffic engineering for the testing, and of course logging.

    I’m not sure there is a “test server behavior” that tracks this in the information model, but all the current carrier grade systems (systems that telecoms use) have them.
It would be “nice” if the MA knew why a test server ignored a test (I’m assuming they only allow so many connections so a failed / timed out test can occur), but I’m not sure if there are any provisions for this.

   In the past I have seen “test software” (MA’s ) get turned up without telling the “op’s teams” who maintain the servers – which results in “HOT” servers that give bad results because they don’t have any CAC, or throttling on how many tests are concurrently run, and ended up as a congestion point.   – this fails the ISO9k & 7K testing standards for the most part.

      Given the criticality of this, it’s a best practice to communicate the test server NAK / Busy, .. to the MA’s so the system is more full proof.
   Especially when the customer, and the test server may be two different unaffiliated parties.

So – test system best practices would say -… make sure you have a CAC on the test servers and communicate that to the MA’s so they know what’s going on.

Best,
Mike








On 11/16/16, 9:42 AM, "lmap on behalf of philip.eardley@bt.com" <lmap-bounces@ietf.org on behalf of philip.eardley@bt.com> wrote:

    The Section 4 example is about timing of events & schedules - pipelining /serialise etc - which is useful.

    I meant something like: take some variant of the example in RFC7594 and explain how to use the information model
    <<   The Controller instructs one or more MAs and communicates the set of
       Measurement Tasks an MA should perform and when.  For example, it may
       instruct an MA at a home gateway: "Measure the 'UDP latency' with
       www.example.org; repeat every hour at xx.05".  The Controller also
       manages an MA by instructing it on how to report the Measurement
       Results, for example: "Report results once a day in a batch at 4am".
    >>

    Strictly speaking this is not needed, but I think it would be useful, as the information model is now quite abstract (eg measurement tasks and registries no longer immediately obvious - as they're just tasks & registires). If other people think this is pointless, then I'm ok.


    -----Original Message-----
    From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
    Sent: 16 November 2016 09:42
    To: Eardley,PL,Philip,TUB8 R <philip.eardley@bt.com>
    Cc: acmorton@att.com; lmap@ietf.org
    Subject: Re: [lmap] I-D Action: draft-ietf-lmap-information-model-12.txt

    Phil,

    I am not sure which example you find missing. There is an example for an execution in section 4. There is no concrete serialization example because the information model is abstract and does not define any serialization rules. A concrete example (in XML serialization) can be found in the YANG data model - and the grand plan was to have the JSON serialization of the same model in the RESTCONF document.

    /js

    On Wed, Nov 16, 2016 at 09:07:16AM +0000, philip.eardley@bt.com wrote:
    > Sorry for having been quiet on this recently. Thanks for all the work on this Juergen.
    >
    > I think it would be good to have a section that provides an example - to act as some kind of link from the architecture doc to the info model. The info model is now more generic (eg no specific measurement tasks) - so I think it would be useful to show a simple example with measurement & reporting.
    >
    > Thanks,
    > phil
    >
    > -----Original Message-----
    > From: lmap [mailto:lmap-bounces@ietf.org] On Behalf Of MORTON, ALFRED
    > C (AL)
    > Sent: 16 November 2016 02:38
    > To: lmap@ietf.org
    > Subject: Re: [lmap] I-D Action:
    > draft-ietf-lmap-information-model-12.txt
    >
    > Hi Juergen,
    >
    > In the latest Info Model...
    > > -----Original Message-----
    > ...
    > >
    > > There's also a htmlized version available at:
    > > https://tools.ietf.org/html/draft-ietf-lmap-information-model-12
    > >
    > [ACM]
    > The metric registry has become generic:
    >
    > 3.10.  Common Objects: Registry Information
    >
    >    Tasks and actions can be associated with entries in a registry.  A
    >    registry object refers to an entry in a registry (identified by a
    >    URI) and it may define a set of roles.
    >
    > 3.10.1.  Definition of ma-registry-obj
    >
    >      object {
    >          uri                 ma-registry-uri;
    >         [string              ma-registry-role<0..*>;]
    >      } ma-registry-obj;
    >
    >    The ma-registry-obj refers to an entry of a registry and it defines
    >    the associated role(s).  The ma-registry-obj consists of the
    >    following elements:
    >
    >    ma-registry-uri:          A URI identifying an entry in a registry.
    >
    >    ma-registry-role:         An optional and possibly empty unordered
    >                              set of roles for the identified registry
    >                              entry.
    > -=-=-=-=-=-=-=-=-
    >
    > It's not clear to me how the generic object works with respect to the performance metric registry. It was clear when the metric aspect was prominent (ma-metric-registry-obj).
    > This may be because the idea of an LMAP task registry has been mentioned, but I haven't seen any details about the LMAP task registry and maybe an example would help.
    > It would be good to see how the LMAP Task Registry and IANA Performance metrics registry are used together.
    >
    > Since I'm mostly interested in using LMAP for control and reporting of registered performance metrics, the composition of these measurement tasks should be as straightforward as possible.
    >
    > A follow-up question is how this will change the data model, which still appears to contain specific references to metrics.
    >
    > regards,
    > Al
    >
    >
    > _______________________________________________
    > lmap mailing list
    > lmap@ietf.org
    > https://www.ietf.org/mailman/listinfo/lmap
    >
    > _______________________________________________
    > lmap mailing list
    > lmap@ietf.org
    > https://www.ietf.org/mailman/listinfo/lmap

    --
    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
    Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
    Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

    _______________________________________________
    lmap mailing list
    lmap@ietf.org
    https://www.ietf.org/mailman/listinfo/lmap


This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.