Re: [lmap] lmap charter - draft 2

[<[e-mail]>]

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.

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.

Best wishes
phil

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