Subject: Re: [lmap] IPFIX vs LMAP

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 1 Feb 2013 15:33:00 +0000

> So can't LMAP use YANG to specify the data format that will define and
> trigger execution of the tests, and IPFIX to report the results of the tests?
> 
> We are already facing a multiplication of protocols from the IETF and other
> SDOs, and this is not a good thing - not for operators, not for vendors.
> Reusing existing protocols and writing data models in already existing data
> modeling languages should be preferred, I believe.

If the data elements that are needed for configuration and control (triggering execution, etc.) could be identified, it's rather easy to put them into a format suitable for use with all sorts of protocols, including (but certainly not limited to) netconf, TR-069, OMA-DM, and SNMP.

If the data elements that need to be collected and reported could be identified, it's rather easy to figure out how to collect/report them using all sorts of protocols, including IPFIX and IPDR.

I absolutely agree that we should avoid defining yet another new protocol for these functions. If "near real time" triggering is needed from a "control" protocol (external to the protocol used to actually run a test), in conjunction with some clock synchronization, that might require some tweaking of an existing protocol -- I don't know yet, and would need more input from the people with expertise in running measurements.

I have no objection to or comment on an IETF recommendation regarding use of IPFIX for LMAP. But please expect other SDOs/SIGs to also make protocol recommendations. And the market-place will pick the winner(s). Service providers who already have an extensive embedded base of devices that use certain protocols for existing configuration, control, and data collection will likely prefer to continue to use those protocols, and just add the additional data elements -- especially where the measurement capabilities are added to these existing devices. As long as the data elements, measurements, and high level operational architecture (consisting of broadly-defined operational functions) are reasonably common, there will be multiple operational (configuration, data collection, etc.) protocol options available. There does seem to be strong agreement in orgs I'm familiar with that IETF has strong expertise in ippm for helping to identify measurements and related data elements. I think http://tools.ietf.org/html/draft-morton-ippm-lmap-path-00 is very helpful towards that goal.
Barbara