Subject: [lmap] "Solution candidates"

From: <[email-masked]>
Date: Tue, 5 Mar 2013 16:16:29 +0000

Hi
the LMAP agenda talks about Solution Candidates
                6a. IPFIX - Brian Trammell - 10+ min
                6b. NETCONF/YANG - Juergen Schoenwaelder - 10+ min
                6c. ALTO - Jan Seedorf - 5+ min

I wanted to start some discussion about what people think "candidate" means, how many candidates the IETF would standardise (assuming the IETF agrees to do work, so the answer is not 'none'), etc.

I think it's out of scope of the BOF to mandate one of the candidates, but I think it's worth discussing whether the prospective WG would be working on:- (1) one and only one, (2) one but enabling others to done later or elsewhere, (3) several.

There are 3 levels we might standardise:-

*         Information model: the abstract definition of the Test /Report Schedule (which is how the Controller instructs the Measurement Agent); and the abstract definition of the Report (which is how the Measurement Agent reports results to the Collector)

*         Data model: which instantiates the information model in a particular language.  It could be done using an existing IETF data modeling language, for example JSON or YANG or (for the Report) IPFIX. Or it could be done using a non-IETF standard like XML.

*         Protocol: how to deliver the Test /Report Schedule and the Report.  Possibilities using IETF protocols could include NETCONF [RFC6241] as discussed in [lmap-netconf] or a RESTful interface or (for the Report) IPFIX. Or a non-IETF protocol, for example from the Broadband Forum
some initial thoughts:

*         Information model: this seems important to standardise. So that there is a single understanding of the contents and structure of a Schedule, and of a Report. We'd like non-IETF bodies also to refer this Information model (to help ensure compatibility - for instance so that results are comparable between measurement systems from different vendors and perhaps from different bodies). So we should be standardising 'one and only one'.

*         Data model: pragmatically it would seem best to choose one, to avoid potential incompatibilites between several data models and to reduce the WG's effort. In theory we could choose a different data model language for the Schedule and the Report, although this may involve extra effort (for example, it's been suggested that the Report should include essentially an 'echo' of the Test Schedule)

*         Protocol: it would be nice to allow measurement platforms to use different protocols. There could be a wide diversity of Measurement Agents - for example, home gateways, routers in the ISP's network, set top boxes, tablets - so there probably needs to be a variety of protocols. For example, a DSL Home Gateway device might use a Broadband Forum TR69-based transport; an edge device might implement an IETF protocol. My tentative view is that the IETF should do one (or one for the Controller-MA and one for the MA-Collector, if it makes sense for them to be different); more than one might be OK if there's enough interest to do the extra work; and potentially other standards bodies would work on their own protocol.

thoughts?
thanks
phil

---

From: "MORTON JR., ALFRED (AL)" <[email-masked]>
Date: Tue, 5 Mar 2013 16:44:57 -0500

Hi Phil,

Your considerations on candidates all sound strikingly realistic to me,
thanks for sharing them.  Allow me to add a consideration that I've been
mulling for some time:

When we look at candidates for any of the 3 levels below, we need to
ask the most obvious question (prompted by the title of the BoF):
Will this model or protocol be suitable for Large-Scale use?

Given that we will define the information elements ourselves, we should
be able to avoid number-range limits and similar "gotchas" from the start.

There may need to be performance metrics on the models and protocols
so we can easily see the trade-offs. There are other factors sometimes
inferred from "complexity".

Some of the scale-aspects will be organization/operation-related.
Can the Controller-Collector-MA relationships easily be expanded or modified
or modularized as the measurement system grows?

I imagine there is valuable IETF experience to draw-on here.

regards,
Al

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 05, 2013 11:16 AM
To: [email-masked]
Subject: [lmap] "Solution candidates"

Hi

thoughts?
thanks
phil

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 6 Mar 2013 12:16:20 +0000

Hi,

The architecture hinted by Phil's 'levels' has the advantage of modularity. One information model can generate several data models using different DMLs. A DML does not necessarily work with one protocol only also there are some pairing preferences (SNMP/SMI, NETCONF/YANG, IPFIX/IEs).

We may reach sooner than later the conclusion that we need to prioritize - i.e start from one or a limited range of use cases, define, implement, deploy, and learn the lessons. Then go to the next set of use cases. And so on ...

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of MORTON JR., ALFRED (AL)
Sent: Tuesday, March 05, 2013 11:45 PM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] "Solution candidates"

Hi Phil,

regards,
Al

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, March 05, 2013 11:16 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [lmap] "Solution candidates"

Hi

thoughts?
thanks
phil