Re: [lmap] Follow-up on recent discussion about draft-ietf-lmap-framework-05.txt

["Marc Ibrahim" <[e-mail]>]

Hi,

 

Trevor has already proposed this kind of flag in a previous discussion about suppression. It was proposed to avoid suppressing main control tasks at MA.

I agree that this flag solves the problem of default suppression behavior.

 

I am just wondering if this flag should be present at the method or task level. 

 

BR,

 

Marc.

 

From: lmap [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Thursday, June 05, 2014 12:13 PM
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