Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Mon, 3 Feb 2014 21:35:44 +0000

Phil,

    I don't see the 2 critical actions detailed out at in this draft that  

1)  Would get the MA the "in use" information from the Line
2)  Would get the current speed profile / state of the service from the ISP.

   Is the intent to add those API / Interfaces later - I thought that would be part of the larger framework vs. smaller details that would come later in the game.

Thanks,
Mike

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 24, 2014 5:46 AM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap-framework-03.txt

Jason,

Thanks for your comments and careful reading In-line phil

> -----Original Message-----
> From: Weil, Jason [mailto:[email-masked]]
> Sent: 22 January 2014 19:37
> To: Eardley,PL,Philip,TUB8 R; [email-masked]
> Subject: Re: [lmap] FW: New Version Notification for draft-ietf-lmap- 
> framework-03.txt
> 
> Phil et al,
> 
> Overall I think the document is coming together nicely. I have 3 
> comments after reading the latest version with chair hat removed:
> 
> Section 5.1 - It is not clear what role and scope the Initial 
> Controller plays. Is this a new device type/function - does it need to 
> be described somewhere other than a cursory glance that is presented 
> here - or does this represent a device that is part of the bootstrap 
> operation that is out of scope? It is not very clear here. Maybe 
> rename to Bootstrap Controller instead?

I think you're right that this section isn't very clear. 
To my mind, we're simply trying to say that the bootstrap process isn't one we're going to define but it needs to get the MA-id, maybe a group-id and details of the various channels. And here are some options about how to get the info on the MA. i think it would be better to scrap the picture - as it will be read as implying we're defining things that we aren't.

One other possibility that we should mention:
The bootstrapping information might be configured on the MA. 
(Marcelo mentioned this during our editing, sorry I forgot to include it) 

> 
> Section 5.2.1 & 5.3 These sections seem to contradict each other 
> slightly.
> Suppression seems to imply that the Controller is capable of actively 
> managing the MA. This includes the challenges stated in Section 6.2.2.
> I am wondering if we should state optional or if required contingent 
> on transport protocol operation? Section 5.3 then goes on to say that 
> the MA acts autonomously once it receives the Measurement and Report 
> Schedules from the Controller. This sentence seems to contradict 5.2.1 
> operation.

You're right that the MA "acts autonomously" should have a supplement "until it gets a new Instruction (including perhaps an Instruction about Measurement Suppression)" 

I don't think suppression should be optional (to implement). It seems a very useful capability. 

I agree that if the MA is behind a NAT, then that presents issues for how lmap operates over the transport protocol - but I don't think they're different for suppression & the ordinary instruction. 

> 
> Section 6.2 - "A single site (home, branch office etc.) that is 
> participating in a measurement could make use of one or multiple 
> Measurement Agents in a single measurement."
> This concept needs more details if it is going to be included I 
> believe.
> How does a measurement task employ multiple MAs for a single test?
> Which MA is responsible for reporting the results? Is there some kind 
> of master/slave function implied here or is Group-ID tie these devices 
> together? Would all the MAs participating in this test group need to 
> be associated with the same controller and does that controller need 
> to be aware of the group? Does the Collector need to be aware of the 
> test group as well?

I think that's a mistake. It shouldn't mention the possibility of multiple MAs. 
If I remember a discussion quite a while ago, we agreed that if you want a multi agent test, then it would be up to you to define two Measurement Tasks and schedule them at the same time - but that wouldn't be a concern of lmap.

Thanks!
phil

> 
> 
> Thanks,
> 
> Jason
> 
> 
> On 1/21/14 10:00 AM, "[email-masked]" <[email-masked]>
> wrote:
> 
> >We submitted a new version of the framework document.
> >
> >http://tools.ietf.org/html/draft-ietf-lmap-framework
> >
> >Here's a summary of the changes:
> >   o  alignment with the Information Model
> >      [I-D.burbridge-lmap-information-model] as this is agreed as a WG
> >      document
> >
> >   o  One-off and periodic Measurement Schedules are kept separate, so
> >      that they can be updated independently
> >
> >   o  Measurement Suppression in a separate sub-section.  Can now
> >      optionally include particular Measurement Tasks &/or Schedules
> to
> >      suppress, and start/stop time
> >
> >   o  for clarity, concept of Channel split into Control, Report and
> MA-
> >      to-Controller Channels
> >
> >   o  numerous editorial changes, mainly arising from a very detailed
> >      review by Charles Cook
> >
> >best wishes,
> >phil, al, marcelo, trevor, paul, aamer
> >
> >_______________________________________________
> >lmap mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/lmap
> 
> 
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject 
> to copyright belonging to Time Warner Cable. This E-mail is intended 
> solely for the use of the individual or entity to which it is 
> addressed. If you are not the intended recipient of this E-mail, you 
> are hereby notified that any dissemination, distribution, copying, or 
> action taken in relation to the contents of and attachments to this E- 
> mail is strictly prohibited and may be unlawful. If you have received 
> this E-mail in error, please notify the sender immediately and 
> permanently delete the original and any copy of this E-mail and any 
> printout.
_______________________________________________
lmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lmap

---

From: Charles Cook <[email-masked]>
Date: Wed, 05 Feb 2014 10:40:37 -0700

Phil,

I like the improvements over the previous version.  I did not have many
additional comments on this draft.  Attached is my marked up review. 

The main comments I had are as follows In summary:

  * *Conflict Resolution: *  If two or more Measurement Tasks overlap in
    their schedule, how should the MA behave?  If two or more
    Measurement Tasks are scheduled to start at the same time, the first
    one listed in the set of Measurement Schedules can be run first. 
    When complete, the conflicting Measurement Task can be run.  If the
    Measurement Schedules overlap, but are not scheduled to start at the
    same time, run the one scheduled to start first to completion, and
    then run the overlapping Measurement Schedule.  The Results Report
    should contain a start and stop time stamp that can be used in post
    processing.  Note:  Some Measurement Tasks may be able to run in
    parallel without impacting the Results of other Measurement Tasks. 
    In this case, scheduling conflicts are not an issue.  But these will
    need to be will defined ahead of time. 
  * *MA Performing Pre-processing:*  I don't think that the MA should
    perform pre-processing unless specifically instructed to do so in a
    Measurement Method.  The MA should provide enough detail in the
    Measurement Result to enable post processing.  Any Measurement
    Methods with pre-processing will need to be very carefully
    constructed to ensure that the results are repeatable/comparable.
  * *MP Registration and Suppression:*  MPs also need to Register with
    the Controller so that the Controller knows they exist.  The
    Controller will also need to know the capabilities of the MP, and
    also have the ability to Suppress/Unsuppress the MP as needed.  I
    didn't see this in the draft.  We just need to add it.
  * *Underlying Transport Protocol:*  Push and/or Pull:  The LMAP
    Framework identifies Push and Pull as possible underlying transport
    protocols, but does not specify a requirement.  A discussion is
    needed to determine if one or both of these are required for the
    Framework.  It sounds like Push is preferred in general, but Pull
    may be needed in order to perform a Measurement Task when the MA or
    MP is behind a NAT.  Additional details are needed.  For example
    should a Controller, in addition to Pushing out Instructions,
    provide a mechanism for an MA to Pull an Instruction if the MA is
    behind a NAT?  If a MA or MP is behind a NAT, should it execute a
    keep-alive so that the Controller knows where it is at?

Great work.

Charles

On 1/21/2014 8:00 AM, [email-masked] wrote:
>       optionally include particular Measurement Tasks &/or Schedules to
>    o  for clarity, concept of Channel split into Control, Report and MA-
>       to-Controller Channels
>

-- 

Charles Cook 
Principal Architect
Network
5325 Zuni Street; Suite 224
Denver, CO  80221
Tel:  303.992.8952  Fax:  925.281.0662
[email-masked]