Subject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Apr 2014 11:58:19 +0000

Hi,

This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments to the WG mail list until Wednesday 4/16. If you believe that the document is ready for submission to the IESG as Informational RC a short message stating this will also be welcome.

The document is available at http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt.

Thanks and Regards,

Dan

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 11 Apr 2014 16:57:27 -0700

Dear Authors, et. al,
please kindly consider my notes to the -04 version as WGLC comments below:

   - Section 2

   - "The main work of the LMAP working group is to define the Control
   Protocol between the Controller and MA, and the Report Protocol between the
   MA and Collector." But the LMAP WG charter puts it differently:

The LMAP working group is chartered to specify an information model, the
associated data models, and select/extend one or more protocols for the
secure communication:
1. A Control Protocol, from a Controller to instruct Measurement Agents
what performance metrics to measure, when to measure them, how/when to
report the measurement results to a Collector,
2. A Report Protocol, for a Measurement Agent to report the results to the
Collector.
The data models should be extensible for new and additional measurements.
LMAP will consider re-use of existing data models languages.

As I read the charter, the LMAP WG defines informational models, not the
protocols themselves.

   - "Measurement Tasks may be Active (the MA generates Active Measurement
   Traffic and measures some metric associated with its transfer), Passive
   (the MA observes user traffic), or some hybrid form of the two."

Usually active and passive distinction being drawn at the level of
measurement methods that is more generic than measurement task. And I think
that term "Active Measurement Traffic" is ambiguous if you're trying to
characterize test traffic. In addition, a performance metric may be not
limited to only transfer of the test packets, but their processing as well.

   - "The MA is managed by a Controller using the Control Protocol."

Perhaps "A Controller manages the MA through use of the Control Protocol."

   - "The MA receives Instructions from the Controller about which
   Measurement Tasks it should perform and when."

I think that it is premature to be so specific about what information the
MA would receive from its Controller. I can imagine that MA receives
schedule with references to Measurement Methods that are in Performance
Registry and necessary Measurement Task parameters.

   - s/The Measurement chedule/The Measurement schedule/

   - "... or a Measurement Peer (or another Measurement Agent) sending
   Active Measurement Traffic to a MA."

Does that imply that MP can generate test traffic without instructions from
the Controller? Or this is to describe one-sided two-way active
measurements when MP reflects or responds to test packets?

   - Section 3

"Active Measurement Method (Task)" should be split into two separate topics
because Measurement Task is an instance of a Measurement Method.

"Active Measurement Traffic" suggest to change to "Measurement Traffic"
because there cannot be "Passive Measurement Traffic".

"Capabilities: Information about the Measurement Methods that the MA can
perform ..." is perhaps too specific without informational model of Control
Protocol being finalized. Could we say "Capabilities: Information that
characterizes performance measurement capabilities of the MA ...

   - Section 5.1

As a result of the bootstrapping process the MA learns the following
information:
That reads as part of MA informational model and probably not required in
the LMAP Framework document. Can we delete the list?

"... transferred via a protocol like TR-069" - needs reference

   - Section 5.2.1

"The Instruction defines the following:"  list that follows is too specific
for the framework document and may be more appropriate in specification of
the informational model or control protocol itself.

   - Section 5.2.2

"Capabilities are information about the MA that the Controller needs to
know in order to correctly instruct the MA, such as:"
I think that the list that follows and "such as" are more in place in the
informational model document or use "for example" clause.

   - Section 5.4

"The Report contains:'
How about "The Report may contain:" then "perhaps" can be removed from the
last bullet

Regards,
Greg

On Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

>  Hi,
>
>
>
> This is a 2nd WGLC for the LMAP Framework I-D. Please send your comments
> to the WG mail list until Wednesday 4/16. If you believe that the document
> is ready for submission to the IESG as Informational RC a short message
> stating this will also be welcome.
>
>
>
> The document is available at
> http://www.ietf.org/id/draft-ietf-lmap-framework-04.txt.
>
>
>
> Thanks and Regards,
>
>
>
> Dan
>
>
>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap
>
>

---

From: <[email-masked]>
Date: Mon, 14 Apr 2014 10:12:55 +0100

Hi,

There's a slight inconsistency between the framework and info model docs. The info model has the idea of configuration information, as well as "pre-configuration" information. Pre-configuration maps to the "bootstrap process"  (S5.1) in the framework, but configuration is missing.
This suggests that we should add a new protocol exchange to the framework, something like:

Section 5.2
Configuration protocol
The Configuration Protocol allows the Controller to update the MA about information that it obtained during the bootstrapping process: the MA-ID, the (optional) Group-ID and the Control Channel. The measurement system might use Configuration for several reasons. For example, the bootstrapping process could 'hard code' the MA with details of an initial Controller, and then the initial Controller could configure the MA with details about the Controller that sends Instruction Messages.
Note that an implementation may choose to combine Configuration information and an Instruction into a single message. Note also that the MA only has one Control Channel (and so is associated with only one Controller) at any moment.
+-----------------+                                      +-------------+
|                 |                                      | Measurement |
|  Controller     |======================================|  Agent      |
+-----------------+                                      +-------------+

Configuration information:               ->
(MA-ID),
(Group-ID),
(Control Channel)
                                         <-          Response(details)

Hopefully this makes sense - I discussed this with the framework & info model authors, who are ok with this change.

Thanks
phil

From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: 02 April 2014 12:58
To: [email-masked]
Subject: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week)

Hi,

Thanks and Regards,

Dan

---

From: <[email-masked]>
Date: Mon, 14 Apr 2014 11:45:51 +0100

Greg

Thank-you very much for the comments.
Some follow-ups in line

Best wishes
phil

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
> Sent: 12 April 2014 00:57
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected
> day-of-the-week)
> 
> Dear Authors, et. al,
> • Section 2
> • "The main work of the LMAP working group is to define the Control
> Protocol between the Controller and MA, and the Report Protocol between
> the MA and Collector." But the LMAP WG charter puts it differently:
> The LMAP working group is chartered to specify an information model,
> the associated data models, and select/extend one or more protocols for
> the secure communication:
> report the measurement results to a Collector, 2. A Report Protocol,
> for a Measurement Agent to report the results to the Collector.
> The data models should be extensible for new and additional
> measurements. LMAP will consider re-use of existing data models
> languages.
> As I read the charter, the LMAP WG defines informational models, not
> the protocols themselves.

[phil] 
I will insert mention of Information model - you're right, that's important work item. 

The Charter goes on to list the work items, including:
<<4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF).
 5. The Report protocol and the associated data model:...>>

I suspect we're actually in agreement on the basic point - the protocols will be defined as extensions /re-use of existing protocol(s) (not a completely new protocol).

> 
> • "Measurement Tasks may be Active (the MA generates Active Measurement
> measurement methods that is more generic than measurement task. And I
> think that term "Active Measurement Traffic" is ambiguous if you're
> trying to characterize test traffic. In addition, a performance metric
> may be not limited to only transfer of the test packets, but their
> processing as well.

This is only the 3rd para of the introductory outline section, to give the reader the impression what lmap is about. I don’t think we have to include all the details and possible variants, which could even be confusing at this early stage.
I don’t understand why the term "Active Measurement Traffic" may be ambiguous.

> 
> • "The MA is managed by a Controller using the Control Protocol."
> • "The MA receives Instructions from the Controller about which
> I think that it is premature to be so specific about what information
> the MA would receive from its Controller. I can imagine that MA
> receives schedule with references to Measurement Methods that are in
> Performance Registry and necessary Measurement Task parameters.

Yes, this could be better phrased. How about:

A Controller manages the MA through use of the Control Protocol. It sends an Instruction Message to the MA, which describes the Measurement Tasks it should perform and when.

> • s/The Measurement chedule/The Measurement schedule/ • "... or a
> Measurement Peer (or another Measurement Agent) sending Active
> Measurement Traffic to a MA."
> Does that imply that MP can generate test traffic without instructions
> from the Controller? Or this is to describe one-sided two-way active

Yes, MP responding to test packet(s) from the MA. is this re-phrase clearer?

<<and/or another Measurement Agent (or a Measurement Peer, in response to packet(s) from a MA) sending Active Measurement Traffic to a MA>>

> • Section 3
> "Active Measurement Method (Task)" should be split into two separate
> topics because Measurement Task is an instance of a Measurement Method.

Ok

> because there cannot be "Passive Measurement Traffic".

I prefer to have the reminder that it's Active. 

> 
> "Capabilities: Information about the Measurement Methods that the MA
> can perform ..." is perhaps too specific without informational model of
> Control Protocol being finalized. Could we say "Capabilities:
> Information that characterizes performance measurement capabilities of
> the MA ...

How about:
Capabilities: Information about the performance measurement capabilities of the MA, in particular the Measurement Methods that it can perform, and the device hosting the MA, for example its interface type and speed, but not dynamic information.

> • Section 5.1
> That reads as part of MA informational model and probably not required
> in the LMAP Framework document. Can we delete the list?
> 

Ok

•
> Section 5.2.1 "The Instruction defines the following:"  list that
> follows is too specific for the framework document and may be more
> appropriate in specification of the informational model or control
> protocol itself.
> • Section 5.2.2
> I think that the list that follows and "such as" are more in place in
> the informational model document or use "for example" clause.
> • Section 5.4
> "The Report contains:'
> How about "The Report may contain:" then "perhaps" can be removed from
> the last bullet 

I rather agree with your comments about the various lists being too specific for the framework. Will think about. 

Regards, Greg
> 
> On Wed, Apr 2, 2014 at 4:58 AM, Romascanu, Dan (Dan)
> <[email-masked]> wrote:
> Hi,
> 
> This is a 2nd WGLC for the LMAP Framework I-D. Please send your
> comments to the WG mail list until Wednesday 4/16. If you believe that
> the document is ready for submission to the IESG as Informational RC a
> short message stating this will also be welcome.
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Apr 2014 13:00:45 +0200

> A Controller manages the MA through use of the Control Protocol. It sends an Instruction Message to the MA, which describes the Measurement Tasks it should perform and when.

Instruction Message is defined as the "message that carries an
Instruction from a Controller to a Measurement Agent." As such, it
should be plural: ... It sends Instruction Messages to the MA, ...
Or even better, get rid of "Messages" since this does not matter at
this level of abstraction.

  A Controller manages the MA through use of the Control Protocol. It
  sends Instructions to the MA, which describe the Measurement Tasks
  it should perform and when.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: <[email-masked]>
Date: Mon, 14 Apr 2014 13:27:09 +0100

Wfm, with the delta that the Instruction is singular (it is the collection of info about Tasks to perform etc)

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: 14 April 2014 12:01
> To: Eardley,PL,Philip,TUB8 R
> Cc: [email-masked]; [email-masked];
> [email-masked]
> > > I think that it is premature to be so specific about what
> > > information the MA would receive from its Controller. I can imagine
> > > that MA receives schedule with references to Measurement Methods
> > > that are in Performance Registry and necessary Measurement Task
> parameters.
> >
> sends an Instruction Message to the MA, which describes the Measurement
> Tasks it should perform and when.
> >
>

---

From: <[email-masked]>
Date: Mon, 14 Apr 2014 15:19:10 +0100

Several of Greg's comments on Section 5 were on the lines "the list that follows is too specific for the framework document and may be more appropriate in specification of the informational model"

I agree with this. In particular, the relationship between the different items seems much more appropriate for the information model i-d. For example, things like "a name for this Measurement Task configuration" seem more appropriate for the info model i-d - the "name" stuff really explains how the different information elements link together, and it seems better to define this once (in the info model).  However, we need a certain level of detail in the framework, in order to show what lmap is doing.

So, we could introduce the list of the bullets with a comment something like:-

This is the list of the aims about the types of information in the Instruction. It is not a list of information elements (these will be defined in draft-ietf-information-model).

In London, we agreed to add the stuff about Data Transfer Tasks, which appear in -04. For consistency with the split between Measurement Schedules, Tasks and Methods, we should have a similar split between Data Transfer Schedules, Tasks and Methods.

Side-note: Section 2 (Outline of lmap) should also mention the Data Transfer stuff.

--

So we might end up with something like:-

As a result of the bootstrapping process the MA learns information with the following aims ([draft-ietf-information-model] defines the consequent list of information elements):

   o  its identifier, MA-ID

   o  (optionally) a Group-ID.  A Group-ID would be shared by several

      MAs and could be useful for privacy reasons. For instance, reporting the Group-ID and not the MA-ID could hinder tracking of a mobile device

   o  the Control Channel, which is defined by:

      *  the address of the Controller (such as its FQDN (Fully

         Qualified Domain Name) [RFC1035<http://tools.ietf.org/html/rfc1035>])

      *  security information (for example to enable the MA to decrypt

         the Instruction Message and encrypt messages sent to the

         Controller)

...

The Instruction defines information with the following aims ([draft-ietf-information-model] defines the consequent list of information elements):

   o  the Measurement Task configurations, each of which needs:

      *  the Measurement Method, specified as a URN to a registry entry.

         The registry could be defined by the IETF

         [I-D.manyfolks-ippm-metric-registry<http://tools.ietf.org/html/draft-ietf-lmap-framework-04#ref-I-D.manyfolks-ippm-metric-registry>], locally by the operator

         of the measurement system or perhaps by another standards

         organisation.

      *  any Input Parameters that need to be set for the Measurement

         Method, such as the address of the Measurement Peer (or other

         Measurement Agent) that are involved in an Active Measurement

         Task

      *  if the device with the MA has multiple interfaces, then the

         interface to use (if not defined, then the default interface is

         used)

   o  configuration of the Measurement Schedules, each of which needs:

      *  the timing of when the Measurement Tasks are to be performed.

         Possible types of timing are periodic, calendar-based periodic,

         one-off immediate and one-off at a future time

   o  configuration of the Report Channels, each of which needs:

      *  the address of the Collector, for instance its URL

      *  security for this Report Channel, for example the X.509

         certificate

   o  configuration of the Data Transfer Tasks, each of which needs:

      *  the Data Transfer Method, and any information it needs about Input Parameters or interface selection

   o  configuration of the Data Transfer Schedules, each of which needs:

      *  the timing of when the Data Transfer Tasks are to be performed.

      A Data Transfer Task may concern the reporting of Measurement

      Results (when the timing could be every hour or immediately, for

      instance).  Alternatively, a Data Transfer Task may concern the MA

      informing the Controller about its Capabilities or any Failures.

   o  Suppression information, if any (see Section 5.2.1.1<http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-5.2.1.1>)

do you think this gets the balance better between what should appear in the framework vs in the information model?
thanks,
phil

Hi,

Thanks and Regards,

Dan

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 15 Apr 2014 22:29:05 -0700

Hi Phil,
thank you for your kind consideration of my comments. I've clipped ones
we've agreed on already. Please find couple follow ups in-lined and tagged
by GIM>>.

Regards,
Greg

On Mon, Apr 14, 2014 at 3:45 AM, <[email-masked]> wrote:

> [...]

>
> I suspect we're actually in agreement on the basic point - the protocols
> will be defined as extensions /re-use of existing protocol(s) (not a
> completely new protocol).
>

GIM>> Yes, agree. It might be good to state that in the framework document
explicitly.

> This is only the 3rd para of the introductory outline section, to give the
> reader the impression what lmap is about. I don’t think we have to include
> all the details and possible variants, which could even be confusing at
> this early stage.
> GIM>> To me "Measurement Traffic" is what Active Performance Measurement
inserts and measures on, what actually differentiates Active Measurement
methods from Passive Measurement. Saying "Active Measurement Traffic", for
me, non-native English speaker, implies that there may be such thing as
"Passive Measurement Traffic".

> A Controller manages the MA through use of the Control Protocol. It sends
> an Instruction Message to the MA, which describes the Measurement Tasks it
> should perform and when.
>

GIM>> Yes, agree. Perhaps can use plural in "Instruction Messages".

> > • "... or a
GIM>> "responding to" definitely clarifies things here.

>
> <<and/or another Measurement Agent (or a Measurement Peer, in response to
> packet(s) from a MA) sending Active Measurement Traffic to a MA>>
>
> >
GIM>> M-m-m

> Capabilities: Information about the performance measurement capabilities
> of the MA, in particular the Measurement Methods that it can perform, and
> the device hosting the MA, for example its interface type and speed, but
> not dynamic information.
>
GIM>> Would " the device hosting the MA, for example its interface type and
speed, but not dynamic information" be capacity of the MA rather than
capability in regard to performance measurement?

> [...]
> I rather agree with your comments about the various lists being too
> specific for the framework. Will think about.
>
>
>
> Regards, Greg
> >

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 15 Apr 2014 22:47:08 -0700

Hi Phil,
and again, appreciate your thoughtful consideration of my notes to the
document.
I agree with the your proposed way of handling lists that will be specified
in the informational model(s). I think that providing examples and
references to possible solutions in the framework will be informative and
not too restrictive at the same time.

Regards,
Greg

On Mon, Apr 14, 2014 at 7:19 AM, <[email-masked]> wrote:

> Several of Greg’s comments on Section 5 were on the lines “the list that
> appropriate in specification of the informational model”
>
>
>
> I agree with this. In particular, the relationship between the different
> items seems much more appropriate for the information model i-d. For
> example, things like "a name for this Measurement Task configuration" seem
> more appropriate for the info model i-d - the “name” stuff really explains
> how the different information elements link together, and it seems better
> to define this once (in the info model).  However, we need a certain level
> of detail in the framework, in order to show what lmap is doing.
>
>
>
> This is the list of the aims about the types of information in the
> Instruction. It is not a list of information elements (these will be
> defined in draft-ietf-information-model).
>
>
>
> In London, we agreed to add the stuff about Data Transfer Tasks, which
> appear in -04. For consistency with the split between Measurement
> Schedules, Tasks and Methods, we should have a similar split between Data
> Transfer Schedules, Tasks and Methods.
>
>
>
>          Qualified Domain Name) [RFC1035 <http://tools.ietf.org/html/rfc1035>])
>
>
>
>          [I-D.manyfolks-ippm-metric-registry <http://tools.ietf.org/html/draft-ietf-lmap-framework-04#ref-I-D.manyfolks-ippm-metric-registry>], locally by the operator
>
>    o  Suppression information, if any (see Section 5.2.1.1 <http://tools.ietf.org/html/draft-ietf-lmap-framework-04#section-5.2.1.1>)
>
>
>
> do you think this gets the balance better between what should appear in
> the framework vs in the information model?
>
> thanks,
>
> phil
>
>
>
>
>
>
>
>
>
> *From:* lmap [mailto:[email-masked]] *On Behalf Of *Romascanu, Dan
> (Dan)
>
> *Sent:* 02 April 2014 12:58
> *To:* [email-masked]
> *Subject:* [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected
> day-of-the-week)
>
>
>
> Hi,
>
>
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 16 Apr 2014 09:55:29 -0400

Hi Greg,

There's one case where I agree with you, the word "Active" in the

> (the MA observes user traffic), or some hybrid form of the two."

But here (and probably other places)
> because there cannot be "Passive Measurement Traffic".
[phil] I prefer to have the reminder that it's Active.
GIM>> M-m-m

I agree with Phil, the adjective is a useful for clarity.

Al

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, April 16, 2014 1:29 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week)

Hi Phil,
thank you for your kind consideration of my comments. I've clipped ones we've agreed on already. Please find couple follow ups in-lined and tagged by GIM>>.
Regards,
Greg

On Mon, Apr 14, 2014 at 3:45 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Greg

Best wishes
phil
[...]

GIM>> Yes, agree. It might be good to state that in the framework document explicitly.

This is only the 3rd para of the introductory outline section, to give the reader the impression what lmap is about. I don’t think we have to include all the details and possible variants, which could even be confusing at this early stage.
I don’t understand why the term "Active Measurement Traffic" may be ambiguous.
GIM>> To me "Measurement Traffic" is what Active Performance Measurement inserts and measures on, what actually differentiates Active Measurement methods from Passive Measurement. Saying "Active Measurement Traffic", for me, non-native English speaker, implies that there may be such thing as "Passive Measurement Traffic".

How about:
Capabilities: Information about the performance measurement capabilities of the MA, in particular the Measurement Methods that it can perform, and the device hosting the MA, for example its interface type and speed, but not dynamic information.
GIM>> Would " the device hosting the MA, for example its interface type and speed, but not dynamic information" be capacity of the MA rather than capability in regard to performance measurement?
[...]
•

Regards, Greg
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi,
>
> [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 16 Apr 2014 19:54:55 +0200

> I agree with Phil, the adjective is a useful for clarity.

Suppose a function A is marking certain frames in a video stream (or a
multmedia stream to be more general) and another functions B derives
statistics from the observed marked stream(s). Is this active of
passive measurement? Are A and/or B active of passive? Note that the
stream may be originated by a regular application (controller by a
human user). Is the marked stream measurement traffic (because it
is marked)?

I believe there can be valid things may not clearly active or passive
and we should be careful to not over constrain things.

/js

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 16 Apr 2014 11:17:15 -0700

Hi Jurgen,
this is very interesting scenario. I believe that marking or coloring of
data traffic will still be considered as passive measurement method.
The Coloring
based IP Flow Performance Measurement
Framework<http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework-01>been
discussed by IPPM WG as passive PM.

Regards,
Greg

---

From: Sharam Hakimi <[email-masked]>
Date: Wed, 16 Apr 2014 18:41:36 +0000

I think Active is when the test device ( in this case MA or MA with its peer) generates traffic in order to make the measurement. When another device other than the measurement device generates traffic and the measurement device is just listening on the network then it would be a passive measurement. This is regardless of the processing the passive device does on the captured data.

Thanks,
Sharam

From: lmap [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Wednesday, April 16, 2014 2:17 PM
To: Juergen Schoenwaelder; MORTON, ALFRED C (AL); Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Cc: Mach Chen
Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week)

Hi Jurgen,
this is very interesting scenario. I believe that marking or coloring of data traffic will still be considered as passive measurement method. The Coloring based IP Flow Performance Measurement Framework<http://tools.ietf.org/html/draft-chen-ippm-coloring-based-ipfpm-framework-01> been discussed by IPPM WG as passive PM.

Regards,
Greg
On Wed, Apr 16, 2014 at 10:54 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587<tel:%2B49%20421%20200%203587>         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 16 Apr 2014 14:46:18 -0400

Greg,

Although this may have been discussed as a passive technique,
coloring (marking user traffic) is not purely passive, and this falls
in the hybrid category (part of the stream is dedicated to measurement).
The v6PDM proposal falls in this category, too.

I dug up IPPM's previous discussion of the taxonomy of hybrid types,
https://www.ietf.org/mail-archive/web/ippm/current/msg02952.html
and this (coloring/PDM) would be another type to add.

Al

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 16, 2014 2:17 PM
To: Juergen Schoenwaelder; MORTON, ALFRED C (AL); Greg Mirsky; [email-masked]; [email-masked]; [email-masked]
Cc: Mach Chen
Subject: Re: [lmap] 2nd WGLC for draft-ietf-lmap-framework (corrected day-of-the-week)

Hi Jurgen,

Regards,
Greg

/js