Re: [lmap] Comments & opinions on Draft - RE: call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

"Weil, Jason" <jason.weil@twcable.com> Tue, 12 November 2013 22:12 UTC

Return-Path: <jason.weil@twcable.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 19D6D21E813C for <lmap@ietfa.amsl.com>; Tue, 12 Nov 2013 14:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level:
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tofgjEJANNPD for <lmap@ietfa.amsl.com>; Tue, 12 Nov 2013 14:12:07 -0800 (PST)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id CF87A21E80E4 for <lmap@ietf.org>; Tue, 12 Nov 2013 14:12:06 -0800 (PST)
X-SENDER-IP: 10.136.163.15
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.93,688,1378872000"; d="scan'208";a="48214383"
Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Nov 2013 17:11:16 -0500
Received: from PRVPEXVS17.corp.twcable.com ([10.136.163.95]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Tue, 12 Nov 2013 17:11:58 -0500
From: "Weil, Jason" <jason.weil@twcable.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Bugenhagen, Michael K" <Michael.K.Bugenhagen@centurylink.com>
Date: Tue, 12 Nov 2013 17:11:55 -0500
Thread-Topic: [lmap] Comments & opinions on Draft - RE: call for consensus - adoption of draft-burbridge-lmap-information-model as WG document
Thread-Index: Ac7f9DOYkitTBtXkS7+7cDmKkY9kZg==
Message-ID: <CEA7FC63.21661%jason.weil@twcable.com>
In-Reply-To: <20131112191106.GA7537@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 12 Nov 2013 14:17:40 -0800
Cc: "Cook, Charles" <Charles.Cook2@centurylink.com>, "'MORTON, ALFRED C (AL)'" <acmorton@att.com>, "lmap@ietf.org" <lmap@ietf.org>, 'Trevor Burbridge' <trevor.burbridge@bt.com>, "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>, 'KEN KO' <KEN.KO@adtran.com>, 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, "'Stark, Barbara'" <Barbara.Stark@bellsouth.com>, "'philip.eardley@bt.com'" <philip.eardley@bt.com>
Subject: Re: [lmap] Comments & opinions on Draft - RE: call for consensus - adoption of draft-burbridge-lmap-information-model as WG document
X-BeenThere: lmap@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 12 Nov 2013 22:12:11 -0000

I am wondering if we may be discussing two different issues here. It feels
like part of this discussion is about the MA Function in the LMAP
Framework and another part of this discussion is concerning a hardware
device housing one or more MA Functions. An ISP speccing a device through
the BBF may/should be concerned with the question of how multiple MAs
under the same org and management system will interact with each other.

It might be useful to reiterate some language from the charter regarding
our current scope as well:

1. No requirement for coordination of overlapping LMAP domains:
"It is assumed that different organization's LMAP measurement domains can
overlap, and that active measurement packets appear along with normal user
traffic when crossing another organization's network. There is no
requirement to specify a mechanism for coordination between the LMAP
measurements in overlapping domains (for instance a home network with MAs
on the home gateway, set top box and laptop). In principle, there are no
restrictions on the type of device in which the MA function resides."


2. Service parameter discovery and sharing is out of scope
"Discovering the service parameters on the MAs or sharing the service
parameters between MAs are out of the scope."


3. LMAP should coordinate with other SDOs on the Information model.
"The LMAP working group will coordinate with other standards bodies
working in this area (e.g., BBF, IEEE 802.16, ETSI) regarding the
information model, and with other IETF working groups in the areas of data
models, protocols, multiple interface management, and measurement of
performance metrics.



Thanks,

Jason

On 11/12/13 2:11 PM, "Juergen Schoenwaelder"
<j.schoenwaelder@jacobs-university.de> wrote:

>On Tue, Nov 12, 2013 at 03:43:25PM +0000, Bugenhagen, Michael K wrote:
>> Juergon - comments in line
>>
>>
>> >  I am still trying to understand what you are suggesting.
>> >
>> > - What does "ISP's need a MA that can Stand by itself as an Overlay"
>> >   mean?
>> > - What does "ISP's ... need one that operates more globally as a
>> >   universal MA" mean? What is a universal MA? What is more globally
>> >   here?
>> >
>> <mkb> Both of these are answered here -
>> <mkb>
>> <mkb> Three large factors on this one -
>> <mkb>        - Opex (operational system cost)
>> <mkb>                Simply put to contain OPEX costs ISP's who also offer VoIP, and
>>Video Over IP like having one test solution. (Brix, Spirent, ....)
>> <mkb>        - Test probe deployment Collision space (if the probes don't know
>>about each other and don't co-exist well)
>> <mkb>                In general most ISP's have three Op's groups (Broadband,
>>VoIP, and Video over IP) - often each one has it's own system and probes.
>> <mkb>                This occurred due to the timeline  of when broadband was a
>>product, then VoIP (new NOC), then Video (yet another NOC and test
>>system).
>> <mkb> - NFV future virtualization
>> <mkb>                Virtualization will enable the convergence of items like probes
>>on the ISP edge equipment where this testing needs to occur.
>> <mkb>
>> <mkb> Summation - A stand alone system to do LMAP is quickly
>>deployable, but drives added cost and Observing the convergence of IP
>>Testing system
>> <mkb> functionality to contain Broadband testing, VoIP testing, and
>>Video over IP testing vs. One system for each ...   It's advisable for
>>LMAP to be <mkb> constructed as both a standalone testing overlay, and
>>part of a converged MA to all the functions.
>> <mkb>        I think that's not a problem scope wise provided we recognize it
>>so the IPPM group can make tests modular in nature vs. probe specific.
>> <mkb>
>
>I still do not understand very well. If your concern is that MAs are
>separate devices that I can tell you that this concern is not
>justified. An MA is a function, how it is packaged into devices is
>left to implementors.
>
>> > - What registry are you talking about? It seems you are not talking
>> >   about the IPPM metrics registry. So what do you have in mind?
>>
>> <mkb> I'm suggesting we re-align the IPPM metrics registry to fix some
>>of the large problems being faced by the industry to ensure the registry
>>success.
>> <mkb> I think the needs may have changed in the years the registry is
>>being worked, and feel we should re-assess the functional role the
>>registry plays.
>> <mkb> Personally I haven't been able to match a critical need from the
>>ISP, or Internet user domain with the registry that will make it a wild
>>sucsses, <mkb> but I think it's do-able.
>
>I assume IPPM folks can make sense out of your request.
>
>/js
>
>--
>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 E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.