Skip to main content

Minutes for LMAP at IETF-95
minutes-95-lmap-1

Meeting Minutes Large-Scale Measurement of Broadband Performance (lmap) WG
Date and time 2016-04-05 17:00
Title Minutes for LMAP at IETF-95
State Active
Other versions plain text
Last updated 2016-04-22

minutes-95-lmap-1
1) Agenda
        Focus is the information model and complimentary work around IPPM
        New work item for Special loop address

================================================================================

2) WG Status
 Noted completed RFCs in LMAP and related IPPM
 Noted Active WG items
 Noted non-chartered items
 Noted chairs being approach about group in EU (Smart2016) looking at creating
 database looking measurements being done to compare results and methodologies;
 wanted some information exchange and provided scope of their project. SMART
 representatives have been invited to IETF 95. Might make it to IETF 96 in
 Berlin Chairs have been invited to the SMART meeting in Brussels

 Al Morton: Was anything presented that could be looked; Chair nothing
 presented yet;

 Dan Romascanu: Have been asked not to share up to now.

 P. Earley: Actually they have a web site; will share site address

 Bert Wijnen:
  SMART contracted with a company to collect & centralize data.
  Project saves extensive metadata with results.
  Company executing the problem is interested in using standards.
  Bert will comment in the next SMART meeting to reach out / share more.

================================================================================

3) Registry for Performance Metrics Status (Al Morton)
 Provided status of the Registry draft updates
 Provided a status of the what is left to do in the draft
 Provided a status of the initial performance metric registry entries
 Provides a status of what is left to do in the draft
 Benefit of adhering to the registry are repeatable, comparable and meaningful
 tests No questions or comments

================================================================================

4) LMAP Information Model Status (Juergen Schoenwaelder)
 Juergen Schoenwaelder states 8 open issues in the LMAP Information Model and
 presents a proposal for each.

1st Issue : Overlapping schedules/actions
Juergen Schoenwaelder:
- will update the draft, to mention that new executions will be skipped while
old ones are running

2nd Issue : Redundant information in report model
Juergen Schoenwaelder:
 - will leave this optimisation for a future version of LMAP

3rd Issue : Conflicting actions & tasks
Juergen Schoenwaelder:
- will capture the conflicting schedule action and task

4th Issue : Result status
Juergen Schoenwaelder:
- will add a result status atribute to the report object, to indicate if the
execution of an action failed

5th Issue : Relation between result table & metrics
Juergen Schoenwaelder:
- an action might produce multiple result tables, as multiple metrics are
measured with an action's package stream. - need to convey which table refers
to which action - 2 options: a) strict association of 1 metric to 1 result
table. b) an additional structure in the information model to bind multiple
metrics to any table -Juergen’s preference is to bind 0 or more metrics to the
result table

Al Morton:
- affirms that 1 measurement stream would generate multiple metrics
- endorses the solution that creates an additional structure in the information
model to bind multiple metrics

Timothy Carrey:
- asks to put this new structure on the mailing list, before including in the
draft.

6th Issue : Default surpression:
- suggests streamlining the suppression implementation
- suggests removal of the ma-task-suppress-by-default attribute and its
emulation with the existent generic suppression, matching suppressions to
schedules / actions / tasks via tags

Phillip Eardly:
- poses the question if we are talking about just 2 well known suppressions
(controller timeout & default suppression) or if we have a need to grow to
dozen values? - Do we want a simple model or a flexible & more complex model.

**Chair consensus call on proposal: 3-5 voted for the proposal; 0 people are
against - rough consensus is for the proposal

Juergen Schoenwaelder:
- answers that conceptually the specific situations are equal, so generic model
is possible. - a generic model is a single model. a single model is simpler.

Timothy Carrey:
- first states that emulation of controller timeout & default suppression with
the generic suppression mechanism needs well known values as tags - later takes
this affirmation back. confirms that there is no need for a well known
centrally defined value to for suppression tags.

Dan Romascanu:
- polls on the suggested proposal (substitute default and controller
suppression with the generic suppression mechanism) - Juergens proposal is
accepted with rough consensus (3/5)


7th Issue : Action on storage exhaustion
Juergen Schoenwaelder:
- suggests 2 steps options:
- a) report on storage allocation
- b) define control to disable tests OR discard old data if storage exhausts

Storage Reporting and Control:
  Chair: Requested clarification on the threshold option
  Alissa Cooper: Is this needed for information model or is it implementation
  option Timothy Carey
        - states that in other standard bodies this condition and its
        mitigation was standardized. - 2 possibilities: stop measuring or
        dumping old data
  Al Morton:
        - emphasizes the rational to keep old data and stop new tests, instead
        of discarding old tests - results in more data to report, as the old
        data has been collected in regular conditions
  Juergen: Yes this makes sense.
  Chair: Needs option to do nothing
  Alissa/Tim: Have status; Valid option detection of problem keep data; fail
  the test and disable schedule Jergen will send to the mail list Mike
  Ackerman: Would like to have the policy controlable (enable/disable)

  Dan Romascanu:
        - resumes preliminar consensus of the WG, as detected in the discussion:
        - 1) report storage use and 2) stop tests when storage threshold is
        reached; keep old data gathered up to this event

8th Issue :  Restrict configuration of tasks
Juergen Juergen Schoenwaelder:
- task configuration might be harmful
- proposes separate permissions to configure a task vs. to schedule a task
- proposes the controller only reads preconfigured tasks and schedules their
execution

Timothy Carey:
- states that access rights to the ma-task-obj will be given anyways, even if
in separated moments. - suggests an authorisation mechanism based on the origin
of request and not on the element manipulated - compares to other standard:
this type of authorisation is not relevant for the 69? data model

Juergen Schoenewaelder:
- takes back the suggestion
- will tag security information in the yang data model

Configuration vs instructions: ma-task-obj
 Tim Carey: Access control for the TR-069 data model doesn't need any mechanism
 Juergen: Proposal to send to the data model for Yang

================================================================================

5. LMAP Information Model Issues (Tim Carey)
Tim Carey presents 4 flaws in the recent revision of the information model,
draft-ietf-lmap-information-model-09 and a solution to each.

1) end and duration attributes of the ma-schedule-object
Tim Carey:
- recaps that the ma-schedule-object has been augmented with ma-schedule-end
and ma-schedule-duration attributes - states that these 2 additional attributes
are redundant, because the ma-schedule-start event, already encodes the end or
the duration - clarifies that ma-event-object in reality represents the concept
of recurrence with start and end - proposes removing ma-schedule-end and
ma-schedule-duration from ma-schedule-object - proposes to rename
ma-schedule-object's ma-schedule-start attribute to ma-schedule-occurence

Juergen Schoenewaelder:
- points out that those 2 new attributes were introduced due to a demand seen
by Al Morton

Al Morton:
- states that a ma-schedule-object without  ma-schedule-end and
ma-schedule-duration will be enough - will work out a concrete example,
relating IPPM needs of multiple timestamps T1, T2, T3 and T4 to the LMAP
information

b) ma-surpression-obj has redundant encoding of the suppression end
Tim Carey:
- relates to the fact ma-event-object in reality represents the concept of
recurrence with start and end - so the planned end of suppression is already
encoded in its ma-suppression-start attribute - proposes to eliminate
ma-suppression-end from the ma-surpression-obj - proposes to rename the
attribute ma-suppression-start to ma-suppression-occurrence

Juergen Schoenewaelder:
- states that un-suppression is necessary
- ma-suppression-occurrence might encode a planned end of the suppression
- un-suppression is implemented with the additional ma-suppression-end attribute

Timothy Carey:
- agrees to Juergens comment
- withdraws proposal to eliminate ma-suppression-end from the ma-surpression-obj

c) ma-instruction-obj gained a list of ma-suppression-objs (multi instance
object) Dan Romascanu: - polls on the Timothy’s proposal to consider a single
suppression for the ma-instruction-obj - the proposal is accepted with rough
consensus (4/5 preferring a single suppression; 1/5 preferring multiple
suppressions)

d) mixing of occurrence and recurrence in the ma-event-object
Dan Romascanu:
- states that the issue should be taken to the mailing list, as time is over

================================================================================

6) Cycle-ID Discussion (Al Morton)
        Discussed how the cycle-id should be used.
        MA is responsible for generating the Cycle-ID so it can't be a Tag
        Tim Carey: Clarified Cycle# is generated by the MA not the Cycle-ID
        P. Eardley: Requested clarification of Cycle# between schedule
        occurrences Chair: Interested parties should get together to draft a
        proposal and send to the list

================================================================================

7) New work item (Special Loop Address)

Partha Turaga:
- presents suggestion to detect link failures between 2 routers
- the solution uses a special loop address that is always routed back to the
origin router - the test routine cycles a package between routers, till TTL
reaches 0; - choosing the TTL odd, the original origin router, receives a ICMP
message back - in case the message is not received, there was a package drop

Greg Mirskey: Provided comments regarding how BFD could be used; also
information that MPLS (MPLS self ping / MPLS echo) there is already mechanism
to do this Robert ?: Chair: Take the discussion to the list; need to figure out
how this works in the LMAP landscape Alissa: This is outside LMAP; need to
figure out where it needs to go - an send to that list

Chair: Noted that we will probably have an interim meeting.