Re: [lmap] Proposed changes to draft-ietf-lmap-framework-05.txt

[Greg Mirsky <[e-mail]>]

Hi Phil,
I'd add Configuration protocol (Section 5.2) to the list of issues to be
addressed based on comments to -05 version.

Regards,
Greg


On Fri, Jun 6, 2014 at 1:11 AM, <[e-mail]> wrote:

>  Just to highlight the proposed changes before I implement them:-
>
>
> * a "suppression flag"
> a Boolean true/false flag is all that is required – to the Measurement
> Task Configuration indicating whether that Task is to be suppressed by
> default (in other words, if the Controller sends a suppression message
> without specifying particular Tasks to be suppressed, then the MA would
> check the Boolean flag for each Task)
>
> * remove the definition of Active and Passive
>
> please shout if you're unhappy with these changes
>
> thanks
> phil
>
>  ------------------------------
> *From:* lmap [[e-mail]] On Behalf Of [e-mail] [
> [e-mail]]
> *Sent:* 05 June 2014 10:13
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
>   i think this is a very good suggestion. i agree this is the right way
> of separating policy and protocol
>
> as a side benefit, we can then drop the active vs passive distinction
> (and terminology) (and do some slight rephrasing in the privacy section,
> which is the main place that uses the terms)
>
> thanks
> phil
>
>  ------------------------------
> *From:* KEN KO [[e-mail]]
> *Sent:* 05 June 2014 00:03
> *To:* Greg Mirsky; Eardley,PL,Philip,TUB8 R
> *Cc:* [e-mail]
> *Subject:* RE: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
>   As I read this email thread which is similar to earlier ones discussing
> active vs. passive, I keep thinking about the only place the distinction is
> being used in the lmap framework, which is for suppression. And, I keep
> thinking that we are creating a distinction the details of which we cannot
> agree on, and that different test system operators  intend to use in
> different ways. And this leads me to think that there is a better way to
> provide the agreed suppression behavior while allowing test system
> operators to modify it as they wish.
>
>
>
> Default suppression behavior, as specified in framework-05:
>
>
>
> “Suppression means that the MA does not begin any new
>
> Active Measurement Task. The impact on other Measurement Tasks is
>
> not defined by LMAP; since they do not involve the MA creating any
>
> Active Measurement Traffic there is no need to suppress them, however
>
> it may be simpler for an implementation to do so.”
>
>
>
> We have arrived at this point because stakeholders could not agree on how
> to treat Passive Tasks. As a result, some operators may suppress Passive
> Tasks by default and others may let them continue, with variations between
> those two extremes. And yet, since we are still debating where to draw the
> line between Active and Passive, the matter is not settled.
>
>
>
> There is a better way. Simply add a field – a Boolean true/false flag is
> all that is required – to the Measurement Task Configuration indicating
> whether that Task is to be suppressed by default. It shortcuts the Active
> Passive arguments (at least, in lmap) and gives operators complete freedom
> over default suppression behavior.
>
>
>
> The description of a Measurement Method in a registry could contain a
> recommended value for the flag. However, operators would be free to use
> that value or override it in their deployments.
>
>
>
> Comments?
>
>
>
> Ken
>
>
>
>
>
> *From:* lmap [mailto:[e-mail]] *On Behalf Of *Greg Mirsky
> *Sent:* Wednesday, June 04, 2014 10:40 AM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [lmap] Follow-up on recent discussion about
> draft-ietf-lmap-framework-05.txt
>
>
>
> Hi Phil,
>
> thank you for your prompt response to my comments.
>
> if I compare common interpretations of "observe" and "collect":
>  ob·serve* verb* \əb-ˈzərv\
>
> : to watch and sometimes also listen to (someone or something) carefully
>
> : to see and notice (someone or something)
>
> : to make a comment about something you notice
>
> vs.
> col·lect* verb* \kə-ˈlekt\
>
> : to get (things) from different places and bring them together
>
> : to get (one or more things) from a place
>
> : to get (similar things) and bring them together as a hobby
>
> the latter seems as more suitable in characterization of role of MA(s) in
> executing Passive Measurement methods.
>
> RE: Measurement Domain. Given earlier discussion and suggestion to take
> holistic approach to MA/MP role, I believe we are at the point where
> discussion of Measurement Domain's definition and use is timely and
> appropriate.
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jun 4, 2014 at 8:34 AM, <[e-mail]> wrote:
>
>
>
>   Proposal:-
>
> In the Intro, add to the paragraph about Active & Passive Tasks:
>
> There may also be Measurement Tasks that are intermediate between Passive
> and Active ones; consideration is outside the initial LMAP work scope.
>
>
>
> In terminology, tweak the definitions:-
>
> Passive Measurement Task: A Measurement Task in which a Measurement Agent
> observes existing traffic but does not inject Active Measurement Traffic.
>
> GIM>> I think that "observes" is not the same as "collect information
> off". Can it be "... in which a Measurement Agent collects information off
> existing traffic ..."? I think that a Measurement Agent may coordinate its
> actions in performing Passive Measurement Task with other Measurement
> Agents/Peers. More on it below.
>
>
>
> [phil] I don't really understand what difference you're getting at - what
> meaning do you want to convey with "collect information" that differs from
> "observes"?
>
>
>
> Active Measurement Task: A Measurement Task in which a Measurement Agent
> sends Active Measurement Traffic to, or receives it from, one or more other
> Measurement Agents or Measurement Peers, and perhaps coordinates with them
> using protocols outside the initial LMAP work scope
>
>   GIM>> Is "Active Measurement Traffic" the same as "Test Traffic"? And
> I'd like to discuss new Measurement Domain object defined as:
>
>   The community of Measurement Agents and Measurement Peers that
> cooperate in performing a Measurement Task, whether Active or Passive,
> present a Measurement Domain. Coordination protocol(s) used within
> Measurement Domain are outside of the initial LMAP work scope.
>
>  Then in definitions of Active/Passive Measurement Task in the LMAP
> Framework we can use the Measurement Domain like:
> Passive Measurement Task: A Measurement Task in which a Measurement Agent
> collects information off existing traffic within its Measurement Domain.
>
>
>
> [phil] yes, Active Measurement Traffic is what you could call test traffic
> ["Active Measurement Traffic: the packet(s) generated in order to execute
> an Active Measurement Task."]
>
>
>
> [phil] re measurement domain - i can see this may be a useful concept, but
> i don't think we've needed this term yet in lmap. given how tricky agreeing
> terminology is, can we delay defining this term until we're sure we need it.
>
>
>
> thanks
>
> phil
>
>
>
> _______________________________________________
> lmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lmap
>
>