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.