Subject: [lmap] Information Model - Interface classification

From: <[email-masked]>
Date: Thu, 13 Mar 2014 09:24:57 +0000

We discussed at IETF 89 the possibility of classifying interfaces and being able to use such classes in the Task or Channel configuration. For example, instead of having to specify ppp0 we might be able to say "active WAN". Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc.

While this seems sensible, does anyone know of existing interface ontologies that are used elsewhere in the IETF or wider industry that we could learn from or reference?

Trevor.

Trevor Burbridge
Network Infrastructure & Innovation | BT Innovate & Design
Tel: 01473 645115
Fax: 01473 640929

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you.
We monitor our email system, and may record your emails. 
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000 

>-----Original Message-----
>From: lmap [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: 13 March 2014 09:20
>To: [email-masked]
>Cc: [email-masked]; Eardley,PL,Philip,TUB8 R; j.schoenwaelder@jacobs-
>university.de
>Subject: [lmap] Information Model proposed changes
>
>As presented and discussed at IETF 89, unless we hear contrary opinions we plan
>to make the following changes in the next week:
>
>1) Channels no longer have timing information. This allows the channel to just
>specify an endpoint and security credentials. What data is to be sent to the
>channel and when is left to Tasks. Tasks become more generic encompassing any
>scheduled logic running on the MA. In addition to Measurement Tasks, Tasks will
>also batch results and send data to/from the channels etc. Tasks can output to
>other Tasks (e.g. to batch results) or to Channels. For example, updating the
>Instruction becomes a scheduled Task. As does error reporting or updating
>capabilities. For further information see the IETF slides.
>
>2) Reports no longer have context information in the Report header. The original
>purpose was to report device and network context such as line speed. This
>responsibility is now devolved to Tasks and as such the information will be
>reported in the Task result data within the Report. Each Measurement tasks can
>either report the context application to itself, or tasks specifically designed to
>gather and report such context can be used. This approach seems clearer and
>there is no longer any ambiguity about then the context was valid.
>
>3) Suppression information to include one further Boolean "Stop Current Tasks".
>If set the MA will terminate already executing Tasks in addition to stopping the
>commencement of new scheduled Tasks.
>
>Trevor.
>
>_______________________________________________
>lmap mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lmap

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Mar 2014 10:36:45 +0100

> While this seems sensible, does anyone know of existing interface ontologies that are used elsewhere in the IETF or wider industry that we could learn from or reference?

IANA has an interface type registry [1]. Of course, these interface
types are technology specific. Things like "active WAN" are usage
specific classifications and the question is whether devices can be
trusted to determine them correctly.

/js

[1] http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib

-- 
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: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Mar 2014 11:17:10 +0000

> > We discussed at IETF 89 the possibility of classifying interfaces and being
> able to use such classes in the Task or Channel configuration. For example,
> instead of having to specify ppp0 we might be able to say "active WAN".
> Other classes might exist for wireless, Wi-Fi, GPRS, LAN, DSL etc.
> >
> > While this seems sensible, does anyone know of existing interface
> ontologies that are used elsewhere in the IETF or wider industry that we
> could learn from or reference?
> >
> 
> IANA has an interface type registry [1]. Of course, these interface types are
> technology specific. Things like "active WAN" are usage specific classifications
> and the question is whether devices can be trusted to determine them
> correctly.
> 
> /js
> 

Every time I've participated in a discussion about "standard ways of expressing interfaces" (many instances of such discussions, in various groups), we've always looked at this IANA registry and determined that it's useless for this purpose. In every case, the people ended up either (1) defining their own enumerated list or (2) don't standardize and just accept whatever names the underlying OS applies to the interface (i.e., no classifying).

When the devices are largely homogeneous or of a limited set of different devices, using the OS name is workable.

The reason the IANA list has been found useless for these purposes in the past is because the interfaces in this registry are at all layers and some are not sufficiently specific (e.g., ieee80211 is used for all variants -- a, b, g, n, ac; and a device with multiple radios, for example operating at 2.4 and 5 GHz would get the same classification). The fact that they are at all layers presents ambiguity if an interface is specific that has multiple IP interfaces riding over it. There is no ability in it to distinguish different IP interfaces. 

For example, a "telco broadband" "residential gateway" can have (1) a management IP interface, (2) a default route "Internet service" IP interface, (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may go over a single DSL, PON, or Ethernet (PHY) interface. They may be done using separate ATM interfaces (not likely anymore, but done at one time), separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer), separate IP "default router" routes, or separate tunnels over a single IP routed interface. And that's just the WAN. On the LAN, we have RGs with multiple Wi-Fi radios operating at different frequencies and being used for different purposes. So asking such a device to test over its "Wi-Fi" interface is ambiguous. "LAN" is even more ambiguous. 

If the group would like, I can put together and provide you with information on how various groups have tried to solve this sort of thing, based on publicly available docs. Maybe this would be useful insight.
Barbara

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Mar 2014 11:21:10 +0000

Hi,

I am wondering what is the practical purpose or benefit of this classification for LMAP. Does it change any bits on wire, protocol fields, location or organization of IANA registry? 

Can somebody explain? 

Thanks and Regards,

Dan

> From: lmap [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
> Sent: Thursday, March 13, 2014 1:17 PM
> To: Juergen Schoenwaelder; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [lmap] Information Model - Interface classification
> 
> > able to use such classes in the Task or Channel configuration. For
> > example, instead of having to specify ppp0 we might be able to say "active
> WAN".
> > ontologies that are used elsewhere in the IETF or wider industry that
> > we could learn from or reference?
> > >
> >
> Every time I've participated in a discussion about "standard ways of
> expressing interfaces" (many instances of such discussions, in various
> groups), we've always looked at this IANA registry and determined that it's
> useless for this purpose. In every case, the people ended up either (1)
> defining their own enumerated list or (2) don't standardize and just accept
> whatever names the underlying OS applies to the interface (i.e., no
> classifying).
> 
> The reason the IANA list has been found useless for these purposes in the
> past is because the interfaces in this registry are at all layers and some are
> not sufficiently specific (e.g., ieee80211 is used for all variants -- a, b, g, n, ac;
> and a device with multiple radios, for example operating at 2.4 and 5 GHz
> would get the same classification). The fact that they are at all layers presents
> ambiguity if an interface is specific that has multiple IP interfaces riding over
> it. There is no ability in it to distinguish different IP interfaces.
> 
> For example, a "telco broadband" "residential gateway" can have (1) a
> management IP interface, (2) a default route "Internet service" IP interface,
> (3) an IPTV IP interface, and (4) a VoIP IP interface. All of these may go over a
> single DSL, PON, or Ethernet (PHY) interface. They may be done using
> separate ATM interfaces (not likely anymore, but done at one time),
> separate PPPoE interfaces, separate VLAN IDs (at the Ethernet MAC layer),
> separate IP "default router" routes, or separate tunnels over a single IP
> routed interface. And that's just the WAN. On the LAN, we have RGs with
> multiple Wi-Fi radios operating at different frequencies and being used for
> different purposes. So asking such a device to test over its "Wi-Fi" interface is
> ambiguous. "LAN" is even more ambiguous.
> 
> If the group would like, I can put together and provide you with information
> on how various groups have tried to solve this sort of thing, based on publicly
> available docs. Maybe this would be useful insight.
> Barbara
>

---

From: <[email-masked]>
Date: Thu, 13 Mar 2014 11:29:25 +0000

Yes. The Information Model allows the specification of an Interface as either a Task or Channel parameter. At the moment this is a string (no suggested change) and expresses a device interface (e.g. eth1, ppp0 etc.). While the structure of the Information model does not need to change we do need to say what data can be present in those strings. E.g. if a Controller says "Active WAN" as an alias then the MA needs to know what the Controller means by this. This does need to be standardised (if we allow such aliases) or referenced to existing definitions.

Trevor.

>From: lmap [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
>Sent: 13 March 2014 11:21
>To: STARK, BARBARA H; Juergen Schoenwaelder; Burbridge,T,Trevor,TUB8 R
>Cc: [email-masked]; Eardley,PL,Philip,TUB8 R; [email-masked]
>I am wondering what is the practical purpose or benefit of this classification for
>LMAP. Does it change any bits on wire, protocol fields, location or organization
>of IANA registry?
>
>Can somebody explain?
>
>Thanks and Regards,
>
>Dan
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Mar 2014 13:46:38 +0100

> When the devices are largely homogeneous or of a limited set of different devices, using the OS name is workable.

Please do not confuse interface type with interface name. These are
separate things although they are often related since several OSes use
an interface naming scheme that carries some type information.
 
> The reason the IANA list has been found useless for these purposes in the past is because the interfaces in this registry are at all layers and some are not sufficiently specific (e.g., ieee80211 i…

While I da agree that the IANA registry is far from being perfect, it
depends on the layer whether differences are visible or not. There is
usually a stack of interfaces layers and yes not all devices expose
them and yet not all layers are properly registered within IANA. But
then it is also not clear in some cases what is another layer and what
is not.

> For example, a "telco broadband" "residential gateway" can have (1) a management IP interface, (2) a default route "Internet service" IP interface, (3) an IPTV IP interface, and (4) a VoIP IP inter…

Exactly. And this is why I believe this problem is too hard to
solve. Lets stay aware from it.

> If the group would like, I can put together and provide you with information on how various groups have tried to solve this sort of thing, based on publicly available docs. Maybe this would be usef…

Did anyone solve the problem or did they all only try to solve it? In
the later case, I do not need to see the details. ;-)

/js

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Mar 2014 13:06:47 +0000

> Exactly. And this is why I believe this problem is too hard to solve. Lets stay
> aware from it.

Agreed regarding generic classification. But I wasn't an advocate of that in the first place. I didn't argue against it very strongly because it seemed better to let people explore the question and come to their own conclusions. I'm thinking there may be something we can do to better model interface info. 
 
> > If the group would like, I can put together and provide you with
> information on how various groups have tried to solve this sort of thing,
> based on publicly available docs. Maybe this would be useful insight.
> 
> Did anyone solve the problem or did they all only try to solve it? In the later
> case, I do not need to see the details. ;-)
> 
> /js

Fair enough. Whether the problem was "solved" is a matter of opinion and degree (e.g.., somewhat solved, good enough, etc.). I'll try my best not to provide details of anything that I consider inadequate.
Barbara

---

From: "Bugenhagen, Michael K" <[email-masked]>
Date: Thu, 13 Mar 2014 13:09:17 +0000

UNI = Network User Interface

That is the highest abstraction level for a customer interface.

Make sure you allow more than 1 of those per device.

Mike

-----Original Message-----
From: lmap [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, March 13, 2014 4:37 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lmap] Information Model - Interface classification

> While this seems sensible, does anyone know of existing interface ontologies that are used elsewhere in the IETF or wider industry that we could learn from or reference?

IANA has an interface type registry [1]. Of course, these interface types are technology specific. Things like "active WAN" are usage specific classifications and the question is whether devices can be trusted to determine them correctly.

/js

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 13 Mar 2014 06:27:56 -0700 (PDT)

Dan,

As someone who would use the metrics produced by measurement devices, it is of great interest to know the kind of interface you are analyzing.   For example, of doing diagnostics and the interface is wireless, one would expect more packet loss and potentially less speed (as a general rule, of course).   Is this what you were getting at?

BTW, passive measurements such as WireShark packet traces already have an indication of the layer 2 interface, so I know what I am getting.

As another question, do we want to consider the topic of Multiple Provisioning Domains (https://datatracker.ietf.org/meeting/89/agenda/mif/)?  If I am understanding correctly, this would allow a device to communicate over multiple interfaces.   Please let me know if I have misunderstood.
 
Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "STARK, BARBARA H" <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, March 13, 2014 4:21 AM
Subject: Re: [lmap] Information Model - Interface classification

Hi,

Can somebody explain? 

Thanks and Regards,

Dan

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 13 Mar 2014 09:28:49 -0400

Dan, I can imagine cases where the interface technology used
might influence the results analysis or the test stream design.
Some tech. are "always-on", others assign resources when traffic
requires them. In some cases, one type of access technology will be
hidden behind others, or the technology may not be important at all.
But I support sorting this out to the extent that we can.
Al

> Sent: Thursday, March 13, 2014 7:29 AM
> To: [email-masked]; STARK, BARBARA H; j.schoenwaelder@jacobs-
> university.de
> Yes. The Information Model allows the specification of an Interface as
> either a Task or Channel parameter. At the moment this is a string (no
> suggested change) and expresses a device interface (e.g. eth1, ppp0 etc.).
> While the structure of the Information model does not need to change we do
> need to say what data can be present in those strings. E.g. if a
> Controller says "Active WAN" as an alias then the MA needs to know what
> the Controller means by this. This does need to be standardised (if we
> allow such aliases) or referenced to existing definitions.
> 
> Trevor.
> 
> >> When the devices are largely homogeneous or of a limited set of
> different
> >> devices, using the OS name is workable.
> >>
> information

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 13 Mar 2014 13:45:32 +0000

I agree that striping tasks will be very challenging and have advocated not to go this route. The tasks usually will have information about the interface they ran on e.g. DSL, WiFi, and will have the that information on a per task basis that will be part of the generated report.

The collision problem is another issue. I thought there was agreement for an MA to execute tasks sequentially and there should only be a single active task or task list. That would ensure that there are no collisions. There could be many task lists stored in the MA but only one would be active at any one time. This is all under the control of one MC.

//Sharam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Mar 2014 14:51:58 +0100

On Thu, Mar 13, 2014 at 06:27:56AM -0700, Nalini Elkins wrote:
> 
> BTW, passive measurements such as WireShark packet traces already
> have an indication of the layer 2 interface, so I know what I am
> getting.

Ehem, do not confuse the PCAP link-type with the technology that was
used to ship the packet. They can be different. The PCAP link-type
merely indicates the format the pcap trace is encoded with. It is easy
to draw wrong conclusions from such assumptions. And even if the
link-type correctly indicates a wired ethernet interface, the wire
might simply end at an AP running a P2P link and you still have a
wireless link involved in your measurement.

Similarly, if a box takes care to label one Ethernet port as WAN port
and the others as LAN ports and the OS carefully renames the OS
interfaces wan and lan0, lan1, ..., there is no guarantee that the
user did plug the cables correctly. Some boxes make the WAN port
special by associating statically say a TR69 daemon with it so that
there is an incentive to plug things right. But then the customer
might have two home routers connected in series and what have you.

/js

---

From: Nalini Elkins <[email-masked]>
Date: Thu, 13 Mar 2014 06:58:38 -0700 (PDT)

Good point!
 
Thanks for the information.

If we can know the interface type, it is useful, though.

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________
 From: Juergen Schoenwaelder <[email-masked]>
To: Nalini Elkins <[email-masked]> 
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "STARK, BARBARA H" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Thursday, March 13, 2014 6:51 AM
Subject: Re: [lmap] Information Model - Interface classification

/js

---

From: Sharam Hakimi <[email-masked]>
Date: Thu, 13 Mar 2014 14:15:47 +0000

One could easily extrapolate the interface used from the IP that was used to transfer data. It just takes a little more post processing.

//SH

From: lmap [mailto:[email-masked]] On Behalf Of Nalini Elkins
Sent: Thursday, March 13, 2014 9:59 AM
To: Juergen Schoenwaelder
Cc: [email-masked]; [email-masked]; Romascanu, Dan (Dan); [email-masked]; STARK, BARBARA H; [email-masked]
Subject: Re: [lmap] Information Model - Interface classification

Good point!

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

/js