References: <F9AC12FC-49D5-4CD0-886C-6AE80C442F25@quittek.at>
 <CE38E868.CFE88%brads@coraid.com>
 <5133F0CE-6966-4A20-B384-5E60587E2DF3@cisco.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <5133F0CE-6966-4A20-B384-5E60587E2DF3@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4631E41-F449-463F-A9B9-72DC4943CA32@quittek.at>
From: Juergen Quittek <ietf@quittek.at>
Date: Tue, 27 Aug 2013 02:06:10 -0700
To: "John Parello (jparello)" <jparello@cisco.com>
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] eman framework issue: How to model a meter?
Precedence: list

Hi John,

I have the same answer to you as for Brad. What you want is categories for d=
evices, not capability modeling.=20

Then my question is: do we need this? We live well in the Internet without p=
robes having a MIB object saying: "I am a probe".

Of course, a well designed network management system may classify devices an=
d that is probably what EnergyWise does as well for meters, consumers, etc. T=
he question is how much of the energy management system design needs to be p=
ushed down to the devices?

If we think we need more for energy management than we have so far needed fo=
r managing traffic in the Internet, I would like to understand why.=20

Thanks,
    Juergen=20

Am 20.08.2013 um 10:39 schrieb "John Parello (jparello)" <jparello@cisco.com=
>:

> +1 on that Brad.
>=20
> The category broadly classifies the device so a mgt system can determine i=
f its behaving beyond its intent. For example power in the wrong direction f=
rom a producer (motor or or solar panel for example) that starts to consume.=

>=20
> So the category attribute answered the question "is a"
>=20
> The power interface by their by their nature only measure power so it "is"=
 not a meter but "can" measure. A meter can contain power interfaces.
>=20
> So if you are looking for a capability  first I suggest not using the word=
 "meter" to answer that question.  What you are looking for is "measure". =20=

>=20
> A device is a "meter" and can "measure". An interface can "measure"  but "=
is not" a meter (a meter may contain multiple power interfaces). If you use t=
he word "meter" there for capability then yes thats confusing but we are not=
 doing that.
>=20
> See inline
>=20
> Jp
>=20
>=20
>=20
> Sent from my iPad=20
> (expect ridiculous spelling mistakes)=20
>=20
> On Aug 20, 2013, at 10:06 AM, "Brad Schoening" <brads@coraid.com> wrote:
>=20
>> Juergen,
>>=20
>> My experience has been that usually a meter was just a meter.  While many=

>> devices such as PoE switches and PDUs can internally meter, we have to
>> recognize that there is a real use case for stand-alone metering.
>> Intelligent smart meters from vendors such as Shark, SATEC, and Crompton
>> are but a few examples of these widely used products   An ethernet switch=

>> is a device who's primary purpose is networking, but may have metering
>> relationships.  But a smart meter is a device with the primary purpose of=

>> metering. =20
>>=20
>>=20
>> A common sense approach to classification should be more than adequate to=

>> distinguish between products which consume energy to provide some
>> function, products that primarily produce energy, and products which are
>> designed for metering.  If we clarify that classification should involve
>> the primary purpose of a device it would this address this nit?
>>=20
>> You ask "Do we need to model metering capability at all"?  Yes, because
>> smart meters, in particular sub-meters, are a key part of real time energ=
y
>> monitoring.
>>=20
>> Regards,
>>=20
>> Brad
>>=20
>> On 8/20/13 1:09 AM, "Juergen Quittek" <ietf@quittek.at> wrote:
>>=20
>>> Dear all,=20
>>>=20
>>> Here is another framework issue: How to model metering capabilities of
>>> devices?
>>>=20
>>> Our framework draft (draft-ietf-eman-framework-08) models metering
>>> capability by categorizing devices and components into either a producer=
,
>>> a comsumer, a meter, or a distributor, see pseudocode on page 43.
>>>=20
>>> I think this approach is broken. It may be useful for modeling simple
>>> scenarios, but it does not work as general model.
>>>=20
>>> There are two problems with this approach.
>>>=20
>>> 1. The either-or classification. A meter is typically not just a meter,
>>> but as well a consumer that consumes energy when doing it's job. A PDU
>>> that meters power at it's outlets is a meter and a distributor and a
>>> consumer. The same holds for a PoE switch. These are not either meters o=
r
>>> consumers, they are meters and consumers and some of them are also
>>> distributors at the same time.
> [jp] for poe switch : is a "consumer", contains power interfaces that can "=
measure". A switch is certainly not a meter.  I proposed "distributor" as an=
other category for pdu and/or a Poe switch. That may be clearer.
>=20
> The model reads well to me with a clear distinction between category and c=
apability to me. Don't see how that's broken unless you use meter as a capab=
ility which I agree is wrong but we don't do that.
>=20
>=20
>=20
>>> 2. The categorization as 'meter' is only available for devices and
>>> components, not for power interfaces. But obviously a device with
>>> metering capabilities meters at (some of) its interfaces. Take the PoE
>>> switch that meters power at some or all of its PoE outlets. It would be
>>> natural to label the power interfaces at which metering capabilities are=

>>> available as 'metered'. It appears strange to classify the device as
>>> 'meter'.
> [jp] you're confusing "is a" versus "can" and overloading meter in both th=
ose attributes. Meter is a classification not a capability. Measuring is the=
 capability.
>=20
>=20
>>> The basic question here is: Do we need to model metering capability at
>>> all?  If yes, we should model it as an attribute, not as a category; and=

>>> we should model it as attribute of the power interfaces as well.
>=20
>>> BTW, if we model metering capability (monitoring), we should consequentl=
y
>>> model circuit breaker capability (control) at power interfaces as well.
> [jp] sounds like you want an additional field for capabilities. We had tha=
t in the model quite some time ago and from feedback deleted that from the M=
ib and framework. Are your proposing we revisit that issue and then add capa=
bility back? IMO and experience these capability type attributes need a regi=
stry and then get used rather loosely when implemented. So I think it much s=
impler to categorize devices and component broadly and then the capability i=
s inferred from the presence of a measurement with caliber. Much simpler.
>=20
> Jp