Re: [lmap] lmap charter - draft 2

[Brian Trammell <[e-mail]>]

Hi, Phil, all,

Trying to catch up on the thread, but wanted to make this point quickly...

On Jun 3, 2013, at 6:55 PM, [e-mail] wrote:

> I'm keen for there to be a common (generic) information model
> Personally I don't want to standardise extensions to a host of protocols. I'd like to try and pick one. If this proves impossible, then maybe we do more than one, or at least others done elsewhere still have the same information model.

Seconding this. Without a common information model (and a reference architecture, so you have a point of common terminology for talking about the components of the measurement system within that information model), it's hard to see what benefit this effort would have for measurement interoperability.

I think the actual protocols used to do control are less important thereto, and where these protocols touch existing management infrastructure and/or must deal with the specifics of a given access technology, it makes sense that these should be based on existing management protocols from the appropriate forum. You really only need a control protocol that is access technology agnostic when you want to run measurements across different access technologies. As a researcher with access mainly to end systems, I find this a cool feature (and am indeed working on a platform at the moment that has this as a requirement), but I don't think it's necessary for the access measurement use cases we're focused on here.

However, I do think it necessary for the WG to produce at least one instance of a control protocol and report protocol, which could (1) be used in a "pure IP" situation (i.e., where the entity running the measurement does not have privileged access to the underlying access technology and no requirement to integrate tightly with it) and (2) provide a point of reference for other (possibly access technology and management infrastructure specific) protocols sharing the information model. I'm skeptical that just focusing on an information model without having control/report protocols on which to gain implementation experience will provide a generally useful result.

> Controller to Controller has not been suggested as in scope (in the charter, BoF, etc). I think the work should focus on the MA's interactions with the Controller and Collector. MA to MA is in scope of IPPM, don't think we should touch it in lmap.

Agree on all of these points.

Cheers,

Brian

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Bugenhagen, Michael K
>> Sent: 03 June 2013 16:13
>> To: 'Shane Amante'; STARK, BARBARA H
>> Cc: Romascanu, Dan (Dan); [e-mail]
>> Subject: Re: [lmap] lmap charter - draft 2
>> 
>> Dan, Shane, Barbara -
>> 
>>   I have been out of the office so I apologize for my input being a
>> bit late..
>> 
>> A few key points I think we need to consider for the charter involve
>> EMS systems, and what Interoperability protocols we need. -
>> 
>> 1)  Protocols / Interfaces -
>> 
>>  My conclusion - In order to ensure adoption we have to recognize that
>> MA's on ISP devices will very likely be managed by their existing
>> management protocols (DOCSIS, GPON and DSL existing management
>> protocols MUST be acceptable).   If we choose to ignore this when we
>> may be guilty of driving added cost into Internet services, which seems
>> foolish to me.  To me this means we have a standard information model,
>> and messaging, and choose a nice way making that portable and
>> implementable, and possibly identifying the better IETF protocols and
>> frameworks that require little extra tweaking to make them work.
>> 
>> 
>> 2)  Inter-operability (protocols)
>> 
>> 	Considering #1 and observing the existence of ISP EMS systems, it
>> seems the inter-operation space should be restricted to MA to MA, and
>> MA controller to MA controller like communication protocols.   If we
>> have a like information model, one can split the management protocol,
>> and the test protocols, the management protocol (EMS to MA need not
>> inter-operate), however controller to MA, and MA to MA Must....
>> Plus I did spec. in an older email that some sort of customer to MA /
>> ISP protocol needs to be standardized for interop as well.
>> 
>> 
>> 
>> Thanks,
>> Mike
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Shane Amante
>> Sent: Friday, May 31, 2013 4:46 PM
>> To: STARK, BARBARA H
>> Cc: Romascanu, Dan (Dan); [e-mail]
>> Subject: Re: [lmap] lmap charter - draft 2
>> 
>> Hi Barbara,
>> 
>> On May 31, 2013, at 3:08 PM, "STARK, BARBARA H" <[e-mail]> wrote:
>>>> Amongst the potential _IETF_ protocols that could fulfill the needs
>>>> of one or the other functions, the IETF should (attempt to) pick one
>>>> of its protocols & data-models for each.  I would not want to see
>> the
>>>> LMAP WG select multiple, overlapping _IETF_ protocols to perform a
>>>> single function, (e.g.: we should think long & hard and try to
>> select
>>>> either SNMP -or- NETCONF/YANG for the "Control Protocol").  The main
>>>> benefit with the above approach is for those who desire, like me, to
>>>> have a complete "LMAP solution", with all of the necessary protocols
>>>> and data-models, _available_ for them to deploy the IETF LMAP WG
>> will have produced such.
>>> 
>>> So you are opposed to LMAP being an agent of providing a useful SNMP
>> MIB for all of the existing network elements (and perhaps cable modems)
>> managed via SNMP?
>> 
>> No.  Please re-read my message, above, carefully.  I recommended the
>> IETF _should_, (I did not say: must), try to pick a single IETF
>> protocol for a particular function.  IMO, it is much, much too early --
>> the LMAP WG has not even been chartered! -- to declare a single,
>> specific IETF protocol or data-model as a de-facto winner.  This is why
>> I agree with the present charter when it states, for Control &
>> Reporting transport protocols: "to be selected, perhaps REST-style
>> HTTP(s) or IPFIX".  The charter is not mandating a choice right now,
>> but it is /eventually/, at least the way that I'm interpreting it.
>> Yes, it has made some suggestions, (e.g.: "perhaps"), but I interpret
>> that explanatory and not declarative.
>> 
>> -shane
>> 
>> 
>>> Here's my thought process relative to that...
>>> cost of replacing existing network elements whose main purpose is
>>> network connectivity just so it can also do some specific metrics;
>> and have corporate IT organization add a whole new system to the
>> management network (including developing interfaces from other OSs) vs.
>>> cost of having vendors develop software upgrades for existing network
>>> elements with new, additional management interface with different,
>> unfamiliar protocol to a brand new system that corporate IT would have
>> to add to the management network (including developing OS interfaces)
>> vs.
>>> cost of upgrading existing network element's SNMP management
>> interface
>>> and existing management systems
>> 
>>> To me the math is pretty clear. I know what I would recommend to my
>> employer.
>>> But if LMAP doesn't want to deliver something useful for the embedded
>> base of network elements and devices, and only wants to consider
>> greenfield deployments, I don't think that would stop the SNMP MIB from
>> being created somewhere else.
>> 
>>> So if that's where the consensus lies, then I guess if we could get
>> the Information Model done first, I would be ok. I'll bother the group
>> no further after that. Y'all can deliver anything you want, targeted
>> only to those who desire a complete greenfield "LMAP solution", that
>> has no consideration for re-use/upgrade of anybody's embedded base of
>> devices, network elements, and systems.
>>> Barbara
>> 
>> 
>> _______________________________________________
>> lmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lmap
>> _______________________________________________
>> lmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lmap
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap