Subject: [lmap] call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Nov 2013 00:58:01 +0000

Today in the LMAP meeting we ran a hum on the question whether we should adopt draft-burbridge-lmap-information-model. The result was read as showing consensus in favor of the adoption, although there was at least one opposed opinion expressed by Benoit (as contributor). 

We would like to extend this call to the participants who could not attend the meeting. Please send your opinions on this question to the WG mail list before Friday 11/15. 

Thanks and Regards,

Dan

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 7 Nov 2013 21:27:11 +0000

Sorry I couldn't be there in person or participate in the discussion live.
After listening to the recorded session and carefully considering the voiced objections (which I would paraphrase as being along the line of: we should finish use cases before taking on a new WG work item; we already see loss of energy in doing use cases and would perhaps see a similar loss in energy on this if it's adopted now), I would like to see this adopted as a WG draft.
I believe the framework and information model are closely linked and I would like to see them worked at the same time. Working them simultaneously, IMO, can be very beneficial, which for me outweighs the potential described risks.
Barbara

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Romascanu, Dan (Dan)
> Sent: Wednesday, November 06, 2013 7:58 PM
> To: [email-masked]
> Subject: [lmap] call for consensus - adoption of draft-burbridge-lmap-
> information-model as WG document
> 
> 
> Today in the LMAP meeting we ran a hum on the question whether we
> should adopt draft-burbridge-lmap-information-model. The result was read
> as showing consensus in favor of the adoption, although there was at least
> one opposed opinion expressed by Benoit (as contributor).
> 
> We would like to extend this call to the participants who could not attend the
> meeting. Please send your opinions on this question to the WG mail list
> before Friday 11/15.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 11 Nov 2013 17:05:24 +0000

Dan, 

Comment 1. Is written from an ISP Operational team perspective (Scope says ISP use case so... )
Comment 2. Is future proofing the Registry concept but it also is in the draft a bit..

1)  ISP use case requirements - (The yet another test system overlay issue)

		ISP's have multiple IP based "testing systems" / "Measurement Agents" deployed today, many of which don't co-exist well.  So one ongoing fairly solid ISP requirement that the groups should strongly consider is the ability of a MA to be open flexible framework MA that can run both Op's ADHOC test, and performance testing without two MA's.  Example (a MA / probe that can run VoIP, VIDEO, LMAP, DNS testing, ..... vs. multiple probes doing one each.)

** Current draft that means adding the ability to 

ADHOC / Multi-user op's needs for considerations 
a) MA capability to both Push and Pull test results 
b) MA  Radius / Authentication to allow item a)
c) Multiple test capability (OAM, and throughput at the same time by different Op's teams)
d) Resource availability checking (when you can run more than one test at a time)
e) MA to MA test capability negotiation (if you are working with a customers or 3rd party probe)

2) Future proof the Registry / MA probe concept into Virtual Applications - (start thinking Virtualization Service Catalog)	

    As NFV (network functional virtualization) will likely become available by the time some of this is being implemented we should consider adding a "hypervisor" type to the Registry.  The thought here is that Virtual applications come in a default deployable set, *.OVF files for VMware, ... for KVM, and so on.    ** ONE KEY to service catalogs is a trusted source for the code, one should NEVER (NEVER - EVER) deploy a virtual appliance from a public source on their network... 
   
I think the registry could be a good solution to this issue - provided we place a high level or safety checks on anything getting loaded into the registry itself.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, November 06, 2013 6:58 PM
To: [email-masked]
Subject: [lmap] call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

Thanks and Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Nov 2013 21:39:31 +0100

> e) MA to MA test capability negotiation (if you are working with a customers or 3rd party probe)

How do a)-e) follow from the use case text?

> I think the registry could be a good solution to this issue - provided we place a high level or safety checks on anything getting loaded into the registry itself.

The registry is about metrics. I fail to understand what change is
requested here that affects the current LMAP documents.

/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/>

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 11 Nov 2013 20:46:35 +0000

Juergen,

   If you look at the bigger picture my comments are saying we should consider those 2 items as requirements of the use cases.
Or at least consider them as such... before running too far into any model that may break if critical requirements are missed.

The 2 I am suggesting here -

1) ISP's need a MA that can Stand by itself as an Overlay, but more importantly they may need one that operates more globally as a universal MA.
2) If we adopt a registry and we know virtualization is on it's way, then we need to take that into account (a virtual MA).

  I gave some context around those, but the major points are what they are.

Without consensus on requirements it's probably not worth trying to mash them into the current draft.
However those two items are a bit haunting (I don't think they'll go away).

Thanks,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 2:40 PM
To: Bugenhagen, Michael K
Cc: 'Romascanu, Dan (Dan)'; [email-masked]; 'Trevor Burbridge'; [email-masked]'; 'marcelo bagnulo braun'; 'Stark, Barbara'; Cook, Charles; 'MORTON, ALFRED C (AL)'; 'KEN KO'
Subject: Re: [lmap] Comments & opinions on Draft - RE: call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

On Mon, Nov 11, 2013 at 05:05:24PM +0000, Bugenhagen, Michael K wrote:
> Dan,
> 
> Comment 1. Is written from an ISP Operational team perspective (Scope 
> says ISP use case so... ) Comment 2. Is future proofing the Registry concept but it also is in the draft a bit..
> 
> 
> 		ISP's have multiple IP based "testing systems" / "Measurement 
> Agents" deployed today, many of which don't co-exist well.  So one 
> ongoing fairly solid ISP requirement that the groups should strongly 
> consider is the ability of a MA to be open flexible framework MA that 
> can run both Op's ADHOC test, and performance testing without two 
> MA's.  Example (a MA / probe that can run VoIP, VIDEO, LMAP, DNS 
> testing, ..... vs. multiple probes doing one each.)
> 

> I think the registry could be a good solution to this issue - provided we place a high level or safety checks on anything getting loaded into the registry itself.

The registry is about metrics. I fail to understand what change is requested here that affects the current LMAP documents.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Nov 2013 22:47:12 +0100

> 2) If we adopt a registry and we know virtualization is on it's way, then we need to take that into account (a virtual MA).

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?

- What registry are you talking about? It seems you are not talking
  about the IPPM metrics registry. So what do you have in mind?

Reading again your other email, if you are talking about an MA under
control of multiple controllers, then I am afraid LMAP 1.0 won't
address this (see the WG's charter). But MAs can of course implement
tests for multiple metrics.

/js

---

From: <[email-masked]>
Date: Tue, 12 Nov 2013 09:11:39 +0000

Michael
Not sure I fully get your comments, but I think at least some of these issues are covered by the framework document.
a) MA can do upload and download style tests
b) security clearly important
c) Instruction can include multiple tests, however only one Controller per MA (S4.2)
d) the start of a test may include a resource check (S5.3)
e) direct MA to MA coordination out of scope (S5.5 #1)

I haven't really thought about the impact of virtualisation on lmap, but I agree with your comments about security

Best wishes
phil

> From: Bugenhagen, Michael K
> [mailto:[email-masked]]
> Sent: 11 November 2013 17:05
> To: 'Romascanu, Dan (Dan)'; [email-masked]; Burbridge,T,Trevor,TUB8 R;
> Eardley,PL,Philip,TUB8 R; 'marcelo bagnulo braun'
> Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; 'KEN KO'; 'Stark, Barbara'
> Subject: Comments & opinions on Draft - RE: [lmap] call for consensus -
> adoption of draft-burbridge-lmap-information-model as WG document
> 
> Dan,
> 
> says ISP use case so... ) Comment 2. Is future proofing the Registry
> concept but it also is in the draft a bit..
> 
> 
> can run both Op's ADHOC test, and performance testing without two MA's.
> Example (a MA / probe that can run VoIP, VIDEO, LMAP, DNS testing,
> ..... vs. multiple probes doing one each.)
> 
> 2) Future proof the Registry / MA probe concept into Virtual
> Applications - (start thinking Virtualization Service Catalog)
> 
>     As NFV (network functional virtualization) will likely become
> available by the time some of this is being implemented we should
> consider adding a "hypervisor" type to the Registry.  The thought here
> is that Virtual applications come in a default deployable set, *.OVF
> files for VMware, ... for KVM, and so on.    ** ONE KEY to service
> catalogs is a trusted source for the code, one should NEVER (NEVER -
> EVER) deploy a virtual appliance from a public source on their
> network...
> 
> I think the registry could be a good solution to this issue - provided
> we place a high level or safety checks on anything getting loaded into
> the registry itself.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> should adopt draft-burbridge-lmap-information-model. The result was
> read as showing consensus in favor of the adoption, although there was
> at least one opposed opinion expressed by Benoit (as contributor).
> 
> We would like to extend this call to the participants who could not
> attend the meeting. Please send your opinions on this question to the
> WG mail list before Friday 11/15.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 12 Nov 2013 10:38:50 +0000

Hi Michael,

Thank you for your comments. As I can see the authors started to address them. 

My question (wearing the WG chair hat :-) ) - are you OK with the adoption of draft-burbridge-lmap-information-model as WG document? Saying 'no' means that you consider that the document needs quite serious changes before becoming a WG document, maybe that you have or you are aware about one ore more alternate proposals to be submitted. Saying 'yes' means the document is on the right direction, with changes and improvements that can be made in the following iterations. 

Thanks and Regards,

Dan

> Sent: Monday, November 11, 2013 7:05 PM
> To: Romascanu, Dan (Dan); [email-masked]; 'Trevor Burbridge';
> [email-masked]'; 'marcelo bagnulo braun'
> 		ISP's have multiple IP based "testing systems" /
> "Measurement Agents" deployed today, many of which don't co-exist well.
> So one ongoing fairly solid ISP requirement that the groups should
> strongly consider is the ability of a MA to be open flexible framework
> MA that can run both Op's ADHOC test, and performance testing without
> two MA's.  Example (a MA / probe that can run VoIP, VIDEO, LMAP, DNS
> Today in the LMAP meeting we ran a hum on the question whether we should
> adopt draft-burbridge-lmap-information-model. The result was read as
> showing consensus in favor of the adoption, although there was at least
> attend the meeting. Please send your opinions on this question to the WG
> mail list before Friday 11/15.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>

---

From: KEN KO <[email-masked]>
Date: Tue, 12 Nov 2013 11:49:05 +0000

Getting back to the original question as Dan asked it, I support adopting draft-burbridge-lmap-information-model as a WG document.

Thanks,
Ken

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 5:39 AM
To: Bugenhagen, Michael K; [email-masked]; 'Trevor Burbridge'; [email-masked]'; 'marcelo bagnulo braun'
Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; KEN KO; 'Stark, Barbara'
Subject: RE: Comments & opinions on Draft - RE: [lmap] call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

Hi Michael,

Thanks and Regards,

Dan

> Subject: Comments & opinions on Draft - RE: [lmap] call for consensus 
> - adoption of draft-burbridge-lmap-information-model as WG document
> 
> Dan,
> 
> Agents" deployed today, many of which don't co-exist well.

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 12 Nov 2013 15:47:59 +0000

Dan - 

  Thanks - you are of course correct, let me re-read and answer that one directly.
I'll get that out today....

Mike

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 4:39 AM
To: Bugenhagen, Michael K; [email-masked]; 'Trevor Burbridge'; [email-masked]'; 'marcelo bagnulo braun'
Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; 'KEN KO'; 'Stark, Barbara'
Subject: RE: Comments & opinions on Draft - RE: [lmap] call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

Hi Michael,

Thanks and Regards,

Dan

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Tue, 12 Nov 2013 15:43:25 +0000

Juergon - comments in line

>   universal MA" mean? What is a universal MA? What is more globally
<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>

>   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.

Thanks,
Mike

>
>   Reading again your other email, if you are talking about an MA under control of multiple controllers, then I am afraid LMAP 1.0 won't address this >  >  (see the WG's charter). But MAs can of course implement tests for multiple metrics.
>
>
>  /js
>
>  --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Nov 2013 20:11:06 +0100

> <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.

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.

> <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

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 12 Nov 2013 17:11:55 -0500

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"
<[email-masked]> wrote:

>> <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>                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>
>
>> <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.
>

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.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 13 Nov 2013 09:40:23 -0500

> > js wrote:

js wrote:

Al wrote:

I'll give this one try (one try only).

The current registry design(s) collects entries which are  
specific instances of metrics, with some input factors specified
and some left as free variables to the measurement system (like ipaddrs).
This registry has all the details that implementers need to build
systems that collect equivalent measurements. There is a clear use
for this registry in the LMAP models and protocols.

It would be possible to create a separate registry for 
measurement system implementations that include a sub-set of 
of the registered instances of metrics. The implementations could be virtual:
<mkb> wrote:
> 2) If we adopt a registry and we know virtualization is on it's way, 
> then we need to take that into account (a virtual MA).

There is no need to combine these two registries, or advantage that I see.
The "registry of implementations" just refers to the "metrics registry" 
when describing what an implementation can do. Virtual or real makes
little difference.

/Al

> Sent: Tuesday, November 12, 2013 2:11 PM
> Cc: Cook, Charles; MORTON, ALFRED C (AL); [email-masked]; 'Trevor
> Burbridge'; 'Romascanu, Dan (Dan)'; 'KEN KO'; 'marcelo bagnulo braun';
> STARK, BARBARA H; [email-masked]'
> Subject: Re: [lmap] Comments & opinions on Draft - RE: call for consensus
> > <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>		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>		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>	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>
>

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Wed, 13 Nov 2013 17:21:14 +0000

Dan,

   I support the document as a draft, but also acknowledge that this document should be the collector of significant set of attributes that have yet to be defined, so the need for the document is paramount, the contents within it today are largely subject to change.

Either way we need an information model so I support it.

Sorry I took me an extra day to reply -They upgraded my laptop so life is now good again.. 
:)

   Too cut some of the chatter I'll follow up directly with the authors of the draft on some items that I think should be reconsidered.

Thanks,
Mike

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, November 12, 2013 4:39 AM
To: Bugenhagen, Michael K; [email-masked]; 'Trevor Burbridge'; [email-masked]'; 'marcelo bagnulo braun'
Cc: 'MORTON, ALFRED C (AL)'; Cook, Charles; 'KEN KO'; 'Stark, Barbara'
Subject: RE: Comments & opinions on Draft - RE: [lmap] call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

Hi Michael,

Thanks and Regards,

Dan

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 14 Nov 2013 12:31:22 +0000

Juergen,

    I'm trying to tell you that the Operations groups in the industry are putting probes on the Modems to troubleshoot all the services.
If the new LMAP probe can't co-exist with an existing probe that is deployed everywhere that would be highly problematic for some ISP's.   

  My 15+ years of Operations troubleshooting experience is often "asked" for in standards discussions -not always appreciated though..

:)

Hope that clears up why I'm recommending we make sure isn't a complete testing overlay that can't exist with other existing overlays.
   In other words - If an ISP has a testing / MA / Probe control plane that's can't co-exist with this new one... one will lose out.

Thanks,
Mike

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 3:47 PM
To: Bugenhagen, Michael K
Cc: 'Romascanu, Dan (Dan)'; [email-masked]; 'Trevor Burbridge'; [email-masked]'; 'marcelo bagnulo braun'; 'Stark, Barbara'; Cook, Charles; 'MORTON, ALFRED C (AL)'; 'KEN KO'
Subject: Re: [lmap] Comments & opinions on Draft - RE: call for consensus - adoption of draft-burbridge-lmap-information-model as WG document

Reading again your other email, if you are talking about an MA under control of multiple controllers, then I am afraid LMAP 1.0 won't address this (see the WG's charter). But MAs can of course implement tests for multiple metrics.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Nov 2013 13:42:12 +0100

Mike,

I appreciate your input I just have trouble to get at the core of it
and hence we need several iterations. I now understand that you say
"it is essential that LMAP probes can co-exist with existing probes
already deployed out there" (trying to get rid of double negations).
Correct me if this is wrong.

If this is your point, I fully agree. Now the engineering question of
course is: what does 'can co-exist' mean? What should LMAP try to
avoid because this would make co-existance difficult? What should LMAP
consider to make co-existance easier? Can we turn the rather
high-level statement into more concrete requirements? Or is there
anything specific in the I-Ds that makes you believe LMAP probes
would not be able to co-exist?

/js

---

From: Steve Miller <[email-masked]>
Date: Thu, 14 Nov 2013 09:50:34 -0500

I guess I'm not clear on how the LMAP WG can really accomplish this.

   From what I've seen so far, having a LMAP MA coexist on existing hardware would be no big deal.  I certainly understand that cablemodems and home routers tend to be seriously low-end devices but I've implemented this sort of thing on such low-end devices before -- sure, you can implement tests that run the device out of resources, but the sorts of things I'd expect people to do routinely shouldn't come close.

   I don't see how we can tell someone how to integrate this into whatever hardware and OS they're using, that seems well into the weeds of implementation details.  If some company has an existing solution that works well for them and that they've gotten the firmware people to put in the devices that company uses, more power to them, no need to change over in a big hurry.  The reasons for changing to using LMAP would seem to be the usual ones: you don't have to have a staff that wrangles the hardware vendor to do what you want (or in my case, a staff that writes the MA code), you don't have to have custom infrastructure (or as much of it, at least) on the collector side, if you're in a regulated industry and your regulator says "use this standard!" you can use it. (-:

	-Steve