Minutes for LMAP at interim-2014-lmap-1
Large-Scale Measurement of Broadband Performance
||Minutes for LMAP at interim-2014-lmap-1
LMAP Interim Meeting
IETF rules apply
WG Status - Use cases submitted - AD comments
- Framework through WGLC
Use case comments - AD Review
all but one addressed by Phil Eardley.
Need Reference to RFC 7258 "pervasive monitoring is an attack"
Framework AD preliminary comments -
Scope mentions that IPPM work is out of scope, but we also want
passive monitoring metric development should be described as out-of-scope.
marcelo asks to provide some pointers, perhaps some text.
IPFIX has information models, other trappings of
YANG - model is already present for passive, but not for active,
and this could be mentioned.
But take care of this comment at AD-review - draft moves forward.
IM presentation - Trevor
Purpose of the IM
Define a task.. Schedule, then do queues go in the middle
no calendar defaults
no negative enumerates
no end of month offsets
We already have "immediate" -
we have set time (offset) from immediate
Startup task only on MA re-start
Parallel tasks in schedule will run in parallel, unless MA
implementation prevents it.
Data persistence can be revealed from the Instruction number.
"Last Instruction Received" must match.
Do we need to standardize Condition Codes? Not clear,
pick up tomorrow. do we have a set, or structure of codes?
Overview of the IM/different sections of the IM
Changes in 02
-- added roles
-- still need t solve the issue of how one task sends information to
Channels and Downstream tasks
- channel granularity:
@juergen: provide flexibility; provide options in both task and schedule
@tim: shall we do it one-way?
Juergen: In the YANG model, this is done differently. Tasks config is
more static, channel is just one more option
Tim: Downstream task is part of the schedule seems weird, would make
more sense that is part of the task definition
Ken: put it as part of the schedule and for downstream tasks
Dan: use another terminology like "next scheduled task"
??: destination task?
Juergen: include option in the scheduled task in order to have more
Trevor: some people think we should leave as in 02 and some other people
think we should do it both (the scheduled task and the task config)
Greg: can reporting task be shared across multiple measurement tasks?
Trevor: I am happy to move the channel as a task option
Tim: Keep it simple, don’t give two ways of doing it, don’t have it in the
task config and in the scheduled
Ken: i think you must be able to define in the schedule, it may also be
in the task config
Trevor: no consensus in the room, how do we proceed?
Trevor: proposal: downstream task most people want to keep it in the
scheduled task and the channel to the task config level
Ken: reporting tasks are in the registry?
Trevor: measurement tasks are in the IANA registry, there is also a
Ken: I think management task should be defined in a public registry
Trevor: explicitly define data queue
Ken: the queue can be assumed to be properly dimensioned so we don’t
Trevor: Memory as a capability
Benoit: provide all info relevant when there is an error
Phil: the queue is a helpful description, but you can implement it as
you like and if there is a problem report the error condition
Tim: if it is for clarity, i wouldn’t make it a formal element
Phil: i prefer that
Ken: if we do this, they should be ingress queues
charles cook: is is possible for a task in one ma be directed to a task
in another ma
Benoit: i think the definition of the queue is going too far, if it helps
for explaining the text, go for it, but not include parameters
Trevor: I will informally mention the queue in the description and see
what people thinks
Task configs versus scheduled tasks
Ken: everything that is explicitly called in the scheduled task
overwrites the task config
Whatever the registry people goes for
Do we report the task config? Don’t include by default
What if the reporting task is suppressed? leave undefined
we remove the defaults values and allow wildcards
JSON example, should we remove it? keep it for a while
Do we need to define error codes? (multiple codes use the same ones?)
- will reporting tasks be defined in metrics registry
@marcelo: should be defined in the protocol specification
- queues b/w tasks and downstream-tasks:
@trevor: do we need queue objects and queue parameters or protocol specific?
@ken: don't parameterize a queue; log and report errors
@juergen; explicitly mention a queue; parameterize it or not
@benoit: hide queue-based details from non-implementors
@benoit: probably we need an implementation guidelines
- what happens if reporting task is suppressed
@ken: don't do anything
New Yang Model
Uses RESTCONF - request to check this with the Netconf WG,
to see if this is a reasonable spec.
Author indicates that RESTCONF has good tools for validating
messages, but YANG is the important thing. Can convert between
JSON and YANG, primitive code.
How do we decide what to do here? review all decks first.
Some proposals only work in PUSH model.
PUSH vs PULL is very critical to all devices behind the NAT/FW.
Default is that MA contacts the controller, and
otherwise there is a required persistent TCP connection
(which does not always work).
Need to have a pin-hole in the FW, Controller says to MA,
please query the Controller for new Instruction.
HOW the FW is left open for this Controller to MA comm.
is left to implementation.
TLS - There are concerns for running the many MA connections
Data model has been updated to reflect info model 02
everyone agrees to do http & json (restconf from
question is whether to do yang
Mike B (on phone) - json might be easier (?)
Trevor - xml & json are ~ the same
Juergen - did yang data model. default way is to do xml. i-d how to do in json.
vaibhav - backend scripts to generate json from sql backend datbase schema
trevro - is yang or json schema easier?
Arne - idea of standardising json schema was turned down at ietf.
marcelo - naming slide
marcelo - comm slide
marcelo - control - use post not get
marcelo - report - use put or post? proably post, for same reasons as control using post
marcelo - data mode
Vaibhav - imploementation. been working on json. next step is protocol on top.
Stephen - impact of tls, if many sessions in parallel
Marcelo - security analysis - usually tls + mutual auth. No performance analysis.
Trevor - SK latform uses. assume there;s nothing better.
Stepehn - if have to re-establish session, maybe have to use tickets for performance?
Protocol description from the Framework.
MA could generate a temporary ID using an ID plus time
or conditions, this ID would only persist until the Controller
tasks the MA to generate a new ID.
>>> but we currently have the MA getting it's ID from the Controller?