Subject: [lmap] Channels (WGLC comments on draft-ietf-lmap-framework-03)

From: <[email-masked]>
Date: Fri, 21 Feb 2014 17:04:22 +0000

Thanks Juergen and others for the comments on Channels.

I agree the terms aren't good and like your suggestions.
So we have Instruction Channel, Capabilities and Failure Information Channel, and Report Channel.

Also been a suggestion of 'Logging' rather than 'Failure' (I prefer the latter; Juergen prefers the former. I don't think this matters much - will just do a straw poll in London, hope this is ok.)

A Channel is one-way, hence the difference between the Instruction Channel (Controller to MA) and Capabilities and Failure Information Channel (MA to Controller).

As to the question of splitting the latter into two: a Capabilities Channel and a Failure Information Channel. I think a Channel is basically conceptual at this stage, so it doesn't matter. At the current level of analysis, it's from MA to Controller and both have info sent asynchronously (Capabilities info could also be sent in response to a request by the controller), so I don't see any point splitting it in two. Maybe when we design the protocol, it turns out that two different protocols are needed. Of course, people may be several steps ahead of me and know that it _will_ need two protocols (this would be interesting to learn about!)

The mention of 'suppression channel' is indeed a remnant - will delete.

Thanks
phil

> -----Original Message-----
> From: lmap [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: 07 February 2014 16:26
> To: [email-masked]
> Subject: [lmap] review of draft-ietf-lmap-framework-03
> 
> Hi,
> 
> I think the document is generally in a good shape. I do only have a 
> few technical comments:
> 
> a] I do not like the term MA-to-Controller channel. The situation is a
>    bit complicated to explain. So let me go through a couple of
>    definitions in order to explain why I think the terms we have are
>    confusing:
> 
>      A Control Protocol "delivering Instruction(s) from a Controller
>      to a Measurement Agent" and it "delivers Failure Information and
>      Capabilities Information from the Measurement Agent to the
>      Controller."
> 
>      A Control Channel is a channel "over which Instructions are
>      sent."  So this is really an instruction channel somewhat
>      mis-labelled as an Control Channel.
> 
>      A MA-to-Controller Channel is a channel over which Capabilities
>      and Failure Information is sent. I think it would be more
>      consistent to call it a Capabilities and Failure Information
>      Channel.
> 
>    So if we keep the separation of the channels as they are defined, I
>    would suggest to rename Control Channel to Instruction Channel and
>    MA-to-Controller Channel to Capabilities and Failure Information
>    Channel.
> 
>    That said, one can ask what the value is of defining two channels
>    for the Control Protocol. Since the Control Protocol carries three
>    different things, why are two of them in one channel and the third
>    in a separate channel? Would it not make sense to either have three
>    separate channels (Instruction Channel, Capabilities Channel,
>    Failure Information Channel) or, alternatively, to have just one
>    Control Channel? What is in the document right now does not seem to
>    be very consistent.
> 
>    <soap>
>      If I were to use lets say NETCONF, then Instruction and 
> Capabilities
>      would likely be carried over one "channel" while Failure 
> Information
>      would likely be carried over a separate notification "channel". I 
> am
>      mentioning this just as an example to demonstrate why the current
>      distinction seems somewhat arbitrary.
>    </soap>
> 
>    As far as I am concerned, my preference is that the terminology has
>    a since conceptual Control Channel that carries Instructions,
>    Capabilities, and Failure Information. I can also live with having
>    three distinct conceptual channels (Instruction Channel,
>    Capabilities Channel, Failure Information Channel) between the MA
>    and the Controller.
> 
> b] The figure on page 14 mentions a "Suppression Channel" which I
>    think is a leftover and should be removed. There is also text
>    talking about a different channel for Suppressions on page 14.
> 
> c] The definition of Capabilities mentions "interface type and speed
>    and its IP address" as examples. The text on page 16 says "Note
>    that Capabilities do not include dynamic information like the MA's
>    currently unused CPU, memory or battery life." For many devices,
>    the set of IP addresses assigned to an interface is pretty much
>    dynamic information, consider for example temporary IPv6 addresses
>    with Randomized Interface Identifiers. My proposal is to (a) add
>    text to the definition of Capabilities clarifying that Capabilities
>    do not include dynamic information and (b) to remove IP address
>    from the examples mentioned in the Capabilities definition.
> 
> d] I do not understand the {Comment} on page 20. Overlapping
>    measurement tasks may be fine, it really depends on what the tasks
>    actually do. I do not think a protocol document can resolve this.
>    I sugges to simply remove the {Comment}.
> 
> /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/>
> _______________________________________________
> lmap mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lmap

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 21 Feb 2014 18:25:00 +0000

> Channel, and Report Channel.

I prefer Juergen's other suggestion of a single Control Channel. [See text snipped below.]

> A Channel is one-way, hence the difference between the Instruction
> Channel (Controller to MA) and Capabilities and Failure Information Channel
> (MA to Controller).

I find this confusing. If the Controller wants to ask the MA to tell the Controller the MA's current Measurement Task Configurations and Measurement Schedules (for example, when a MA first communicates with a new Controller, the Controller may want to know about the existing Instructions so it can just send updates and not have to send the entire set of Instructions), 
1) Is it envisioned that this is possible? (I would actually consider it required of a Control Protocol.)
2) Since the set of current Instructions would go from the MA to the Controller, and the proposed "Instruction Channel" is only Controller to MA, does this mean that the existing set of Instructions get sent to the Controller via the Capabilities Channel? I'm having real trouble getting my head around this unidirectional concept. Client/server architecture I would understand. Grasping the applicability of separate "channels" based on the direction information is sent is causing my head to hurt.

>From Juergen's email:
<snip>

---

From: <[email-masked]>
Date: Fri, 21 Feb 2014 19:07:34 +0000

Yes, Capabilities includes the measurement methods that the MA can do.

the Instruction replaces (rather than adds to) the elements that it contains
(the 5 elements are: configuration of measurement tasks, report channels, periodic schedules, one-off schedules and suppression information.) 
So if an instruction contains config of measurement tasks, it replaces whatever measurement task config is in the MA.
This was felt to be simpler.

Will leave others to comment on the 1 vs 2 vs 3 channels issue. Happy to go with the consensus.

> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: 21 February 2014 18:25
> To: Eardley,PL,Philip,TUB8 R; [email-masked]
> Subject: RE: Channels (WGLC comments on draft-ietf-lmap-framework-03)
> 
> > Channel (Controller to MA) and Capabilities and Failure Information
> > Channel (MA to Controller).
> 
> I find this confusing. If the Controller wants to ask the MA to tell
> the Controller the MA's current Measurement Task Configurations and
> Measurement Schedules (for example, when a MA first communicates with a
> new Controller, the Controller may want to know about the existing
> Instructions so it can just send updates and not have to send the
> entire set of Instructions),
> 2) Since the set of current Instructions would go from the MA to the
> Controller, and the proposed "Instruction Channel" is only Controller
> to MA, does this mean that the existing set of Instructions get sent to
> the Controller via the Capabilities Channel? I'm having real trouble
> getting my head around this unidirectional concept. Client/server
> architecture I would understand. Grasping the applicability of separate
> "channels" based on the direction information is sent is causing my
> head to hurt.
> 
> From Juergen's email:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 21 Feb 2014 20:48:42 +0100

> Also been a suggestion of 'Logging' rather than 'Failure' (I prefer the latter; Juergen prefers the former. I don't think this matters much - will just do a straw poll in London, hope this is ok.)

It is 'Logging' vs 'Failure Information'. First, 'Logging' is shorter
and second I assume that say a failure to parse an instruction will
not be reported over this channel but lead to an error indication on
the Instruction Channel. But yes, I am guessing here, I do not think
this is really spelled out. If I am correct, then I would find the
name 'Failure Information" potentially misleading.

> A Channel is one-way, hence the difference between the Instruction Channel (Controller to MA) and Capabilities and Failure Information Channel (MA to Controller).

Is it stated anywhere that a channel is one-way? If that is the
assumption behind a channel, this needs to be made explicit. And I
assume 'one-way' as far as the information flowing over the channel is
concerned.

/js

---

From: "Sharam Hakimi" <[email-masked]>
Date: Fri, 21 Feb 2014 14:45:48 -0500

My two cents on this, I am not sure why reports have channels in the 5
elements Phil listed below. I believe it should be report destinations
and not channels. I think we need to have two Channels:

		Control
		Data

Then Instructions, and any control information (Bi-directional) will use
the control channel and reports will use the Data channel,
Bi-directional.

I also agree that defining directional paths/channels is very confusing.

Sharam

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 21, 2014 2:08 PM
To: [email-masked]; [email-masked]
Subject: Re: [lmap] Channels (WGLC comments on
draft-ietf-lmap-framework-03)

the Instruction replaces (rather than adds to) the elements that it
contains
(the 5 elements are: configuration of measurement tasks, report
channels, periodic schedules, one-off schedules and suppression
information.) 
So if an instruction contains config of measurement tasks, it replaces
whatever measurement task config is in the MA.
This was felt to be simpler.

Will leave others to comment on the 1 vs 2 vs 3 channels issue. Happy to
go with the consensus.

> > >    Control Channel? What is in the document right now does not
seem
> to

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 21 Feb 2014 21:20:04 +0000

> (the 5 elements are: configuration of measurement tasks, report channels,
> periodic schedules, one-off schedules and suppression information.) So if an
> instruction contains config of measurement tasks, it replaces whatever
> measurement task config is in the MA.

I do not understand this assumptive leap, and disagree with it.

I went back and re-read the emails discussing Instruction definition.
I saw the proposal that Instruction be defined as:
Instruction:
The description of Measurement Tasks for a MA to perform and the details of the Report(s) for it to send. It is the collective description of the set of Measurement Schedules, the set of Measurement Task configurations, the configuration of the Report Channel(s) and details of Suppression (if any). The Controller sends a message over the Control Channel to the MA, in order to update the Instruction or elements of it.

I'm ok with this definition.

This indicates to me that "Instruction" is all of these data sets, as they reside in the MA, and that it is possible to update specific "elements" without updating everything. Note that "elements" is not defined, and I did not see "elements" as necessarily being used to mean "the 4 elements of the Instruction are the set of Measurement Schedules, the set of Measurement Task configurations, the configuration of the Report Channel(s) and details of Suppression (if any)". My interpretation of "element" was that it referred to any subset of the Instruction.

There is nothing in the definition that suggests the set of Measurement Tasks cannot be updated, but must be replaced in its entirety when changing the slightest thing. I have no problem with the Control Protocol being able to behave in this manner, for those who wish to use it in this manner. But I do not believe that such inefficient behavior should be imposed on those who wish to be more efficient. Admittedly, it is simple, but deployers of MAs should be allowed to choose to use more intelligent Controllers that maintain knowledge of MA configurations and are capable of sending updates and not just replacement configurations. There is no need to require wholesale replacement, as the only permitted manner in which a Control Protocol can function. I believe that most of the protocols we are considering are perfectly capable of doing updates. What you propose is an unnecessary constraint.
Barbara

---

From: <[email-masked]>
Date: Mon, 24 Feb 2014 09:11:59 +0000

This is in -03 of the framework i-d and was in -02

> Sent: 21 February 2014 21:20
> > contains (the 5 elements are: configuration of measurement tasks,
> > report channels, periodic schedules, one-off schedules and
> suppression
> > information.) So if an instruction contains config of measurement
> > tasks, it replaces whatever measurement task config is in the MA.
> The description of Measurement Tasks for a MA to perform and the
> details of the Report(s) for it to send. It is the collective
> description of the set of Measurement Schedules, the set of Measurement
> Task configurations, the configuration of the Report Channel(s) and
> details of Suppression (if any). The Controller sends a message over
> the Control Channel to the MA, in order to update the Instruction or
> elements of it.
> 
> This indicates to me that "Instruction" is all of these data sets, as
> they reside in the MA, and that it is possible to update specific
> "elements" without updating everything. Note that "elements" is not
> defined, and I did not see "elements" as necessarily being used to mean
> "the 4 elements of the Instruction are the set of Measurement
> Schedules, the set of Measurement Task configurations, the
> configuration of the Report Channel(s) and details of Suppression (if
> any)". My interpretation of "element" was that it referred to any
> subset of the Instruction.
> 
> There is nothing in the definition that suggests the set of Measurement
> Tasks cannot be updated, but must be replaced in its entirety when
> changing the slightest thing. I have no problem with the Control
> Protocol being able to behave in this manner, for those who wish to use
> it in this manner. But I do not believe that such inefficient behavior
> should be imposed on those who wish to be more efficient. Admittedly,
> it is simple, but deployers of MAs should be allowed to choose to use
> more intelligent Controllers that maintain knowledge of MA
> configurations and are capable of sending updates and not just
> replacement configurations. There is no need to require wholesale
> replacement, as the only permitted manner in which a Control Protocol
> can function. I believe that most of the protocols we are considering
> are perfectly capable of doing updates. What you propose is an
> unnecessary constraint.
> Barbara

---

From: <[email-masked]>
Date: Mon, 24 Feb 2014 13:52:06 +0000

Barbara
Let's talk about this in London. Maybe able to do something without changing the protocol (at least if we assumed RESTful - don't know whether this is an acceptable assumption)

phil

> Sent: 24 February 2014 09:12
> Subject: Re: [lmap] Channels (WGLC comments on draft-ietf-lmap-
> framework-03)
> 
> > description of the set of Measurement Schedules, the set of
> > Measurement Task configurations, the configuration of the Report
> > Channel(s) and details of Suppression (if any). The Controller sends
> a
> > message over the Control Channel to the MA, in order to update the
> > Instruction or elements of it.
> >
> > defined, and I did not see "elements" as necessarily being used to
> > mean "the 4 elements of the Instruction are the set of Measurement
> > There is nothing in the definition that suggests the set of
> > Measurement Tasks cannot be updated, but must be replaced in its
> > entirety when changing the slightest thing. I have no problem with
> the
> > Control Protocol being able to behave in this manner, for those who
> > wish to use it in this manner. But I do not believe that such
> > inefficient behavior should be imposed on those who wish to be more
> > efficient. Admittedly, it is simple, but deployers of MAs should be
> > allowed to choose to use more intelligent Controllers that maintain
> > knowledge of MA configurations and are capable of sending updates and
> > not just replacement configurations. There is no need to require
> > wholesale replacement, as the only permitted manner in which a
> Control
> > Protocol can function. I believe that most of the protocols we are
> > considering are perfectly capable of doing updates. What you propose
> > is an unnecessary constraint.
> > Barbara
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 24 Feb 2014 14:12:57 +0000

> Barbara
> Let's talk about this in London. Maybe able to do something without changing
> the protocol (at least if we assumed RESTful - don't know whether this is an
> acceptable assumption)
> 
> phil

Hi Phil,
That sounds good. I had not read in to the existing language that there would be a firm constraint on the Control Protocol and the MA, Controller, and Control Protocol MUST NOT allow for updating of portions of an Instruction, and MUST restrict the Controller and MA interaction to require sending of an Instruction in its entirety.

I suspect that some of this comes from continued misunderstanding by some of us that every time "Instruction" is used in framework, it refers to the entirety of the information and can never be used to refer to just a part of it. I admit that I was personally unclear on this. While this sort of language (restricting and limiting Control Protocol capabilities) has indeed been in several drafts of framework, I only now am really understanding its implications. And disagreeing with those implications. I continue to believe that it would be better if unnecessary restrictions were not imposed in framework.
Barbara
 
> > > > the Instruction replaces (rather than adds to) the elements that
> > > > it contains (the 5 elements are: configuration of measurement
> > > > tasks, report channels, periodic schedules, one-off schedules and
> > > suppression
> > > details of the Report(s) for it to send. The Instruction is sent by a
> > > Controller to a Measurement Agent.