Subject: Re: [eman] modeling power states

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 09:18:15 +0100

Hi John,

this seems to be a misunderstanding.

I said it is not a technical argument that if we do not follow your proposal we would not need an EMAN WG.

I agree that indeed it is a technical argument that your proposal may help building great management applications. 
My comment on this one is that is certainly is an objective of our work in EMAN, but probably not the one with top priority.

Thanks,

    Juergen

Am 01.03.2011 um 00:54 schrieb John Parello (jparello):

> Hi Juergen,
> 
> Thanks that's where we disagree :)
> 
> IMO it is a technical argument. Without adding an common interface for
> devices *and*  the ability to manage devices attached to a communication
> network you can achieve your goals with simple data models added to
> sensor, entity and even UPS mib.
> 
> Interface vs implementation abstraction, retrieval, all partitioning of
> data is a technical decision. It's not a business, time to market or
> artistic argument.
> 
> I'll leave the debate to the rest of the group as you can see where my
> opinion goes.
> 
> Looking forward to feedback!
> Jp
> 
> 
> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]] 
> Sent: Monday, February 28, 2011 1:08 PM
> To: John Parello (jparello)
> Cc: eman mailing list
> Subject: Re: [eman] modeling power states
> 
> Hi John,
> 
> Thanks for your comments. Please find replies inline.
> 
> Am 28.02.2011 um 18:22 schrieb John Parello (jparello):
> 
>> Thanks Juergen for summarizing this. 
>> 
>> I think the stall we've seen on the proposals is directly related to
> not
>> converging on an agreement for power states and parent child
>> aggregation.
>> 
>> We've asked this question on the list before with no dialogue and our
>> conversations have come down to two differences
>> 
>> The proposal submitted, by verges, quittek, parello, claise are very
>> similar. The similarities are in data elements and only vary by
>> partitioning (ie class). The only differences exist in two items
>> 
>> 1) Power states / Interfaces
>> 2) Parent Child relationship (or aggregator as specified in
> references)
>> 
>> IMO any work in EMAN must contain the addition of an IETF power
>> interface as described in claise architecture (or some compromise as
> you
>> listed with IANA interfaces). It must also contain the addition of
>> parent/child/aggregator relationship for non SNMP energy management.
> 
> You say we MUST adopt the power states from the claise architecture 
> and we MUST adopt the parent/child concept.
> 
> The reasons you give for this in the paragraphs below are
>  - Otherwise we would not need an EMAN WG.
>  - This helps manufacturers to build sophisticated energy management
> systems.
> 
> I would not accept the first one as a technical argument, 
> On your second argument I would reply that providing good interfaces
> for building sophisticated applications is certainly an objective 
> of our work in EMAN, but probably not the one with top priority.
> 
> Thanks,
> 
>    Juergen
> 
> 
>> Without those two additions the work in this group can easily be
> covered
>> by two additions to existing SNMP objects. First would be adding
> energy
>> related fields (watts units or Kwh) to the sensor mib. The seconds
> would
>> be to add better the context information (see energy aware proposal)
> to
>> the entity mib. A simple on/off/standby state already exists in oper
>> status.
>> 
>> So in short without an IETF EMAN set of power states / interfaces to
>> unify or map to the states from other orgs as you listed, *and* the
>> ability to monitor/aggregate non SNMP devices - the work here can
> easily
>> be absorbed into the sensor and entity mibs with minor additions.
>> 
>> The experience I've personally had with energy management and running
>> code with exactly these additions has shown that manufacturers can
> build
>> sophisticated energy management systems and devices for many different
>> network connected devices with a converged set of states and the
> parent
>> child relationship. 
>> 
>> Having run a program which adds these features I'm strongly in favor
> of
>> a solution that has a unified power interface and the concept of a
>> parent / child to allow for non-snmp management of power.
>> 
>> Jp
>> 
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
>> Juergen Quittek
>> Sent: Monday, February 28, 2011 4:07 AM
>> To: eman mailing list
>> Subject: [eman] modeling power states
>> 
>> Dear all,
>> 
>> We have two proposals for a Power/Energy MIB module:
>> 
>> - draft-claise-energy-monitoring-mib-06
>> - draft-quittek-power-mib-02
>> 
>> Among the authors of both documents we are currently trying to merge
>> them.
>> But there are some open issues that should be discussed on the mailing
>> list.  Here is the probably biggest of them: modeling power states.
>> 
>> For simplifying energy management we want to introduce the concept of
>> power states (aka power levels).  A power state will indicate roughly
>> how
>> much power a device consumes.  Examples for simple power states are
> off,
>> sleep, and operational states.
>> 
>> In the envisioned EMAN MIB modules, a power state is characterized by
> a
>> descriptive name and the device's expected power input in this state
>> (max/min/average).
>> 
>> Power states are not a new concept.  The DMTF has already defined a
> set
>> of
>> power states and there is the Other standards bodies as the DMTF
>> (Distributed Management Task Force) and there  is the ACPI (Advanced
>> Configuration and Power Interface) for PC motherboards.  And there may
>> be
>> more than these out there.  I listed some DMTF and ACPI states at the
>> end
>> of this message.
>> 
>> An easy solution for EMAN would be just adopting one of these sets.
>> However, there are issues with the ones we looked at.  ACPI was
>> developed
>> for PC motherboards and is quite PC-centric.  Also it defines states
>> that
>> seem to be superfluous, because so far, almost no one has implemented
>> them.  Also the DMTF model seems to have a narrower scope than
>> envisioned
>> by the EMAN WG.
>> 
>> At some point in time, the EMAN WG hast to make a decision, which
> power
>> state model to adopt.  Here is a set of alternatives. The first four
>> have
>> fixed sets of power states.
>> 
>> Option 1: fixed minimum
>> Just support three power states (off, sleep (stand-by), operational)
>> This has clear semantics, but there are several people claiming it's
> too
>> restrictive.
>> 
>> Option 2: fixed DMTF
>> Just use the states defined by DMTF.
>> Might be too much focussed n PCs.
>> 
>> Option 3: fixed ACPI
>> Just use the states defined by ACPI.
>> Might be too much focussed n PCs.
>> 
>> 
>> 
>> Option 4: fixed EMAN
>> Define a new fixed set of power levels within the EMAN WG.
>> 
>> Option 5: IANA-registered power states
>> Have power states be registered at IANA.
>> We would start with registering (off, sleep, operational, the DMTF
> set,
>> and the ACPI set.
>> Manufacturers can then register further ones.
>> 
>> 
>> There has been discussions pointing out that these fixed sets may not
> be
>> sufficient, particularly if non-IT equipment should also be covered.
>> 
>> For being more open, the idea to support user-defined or
>> manufacturer-defined power states of devices has been developed.  In
>> such
>> a state, for example, certain components of a device may be switched
> off
>> or put to sleep.  Which ones are switched off in which state is to be
>> defined by the user/operator/manufacturer and may be chosen such that
>> operational needs are met.
>> 
>> Again, there are several proposals how to do this.  All of them favor
> a
>> two-level approach that distinguishes between rather flexible
> functional
>> power states and rather fixed basic power states.  Functional power
>> states
>> would be defined by the manufacturer, operator, or user.  These would
> be
>> the power states that would be reported by a device.  However, in
> order
>> to
>> better define the semantics of functional power states, Each of these
>> would be mapped to exactly one basic power states.  This means that a
>> property of any functional state would be the basic state it maps to.
>> Basic power states would be fixed, such as the ones used in options
> 1-5.
>> An easy example would be functional power states defined by
>> user/operator/manufacturer with each state indicating whether it is an
>> off
>> state, a sleep state or an operational state.
>> 
>> Here are the corresponding options:
>> 
>> Option 6: flexible functional states mapped to a fixed set of basic
>> states
>> States could be defined flexibly.  But each state would indicate a
> basic
>> state to which it corresponds. Basic states could be either basic
>> (off/sleep/operational) or the DMTF set or the ACPI set
>> 
>> Option 7: flexible functional states mapped to a IANA registered set
> of
>> basic states
>> This is like Option 6, but basic states would be registered at IANA
> and
>> can be extended.  We would register all DMTF and ACPI states and
>> probably
>> some more at IANA. Manufacturers could add more.
>> 
>> Option 8: IANA-registered sets of functional states, only three basic
>> states
>> The main reasoning behind this option is that is should always be
> clear
>> whether a power state is an off state, a sleep state, or an
> operational
>> state.  Therefore, only these three basic states are supported.  This
>> would be in line with an instance of Option 6.  However, this option
> has
>> an extension for the functional states.  It suggests that for
>> customizing
>> devices in order to be compliant with given management systems, for
>> example a DMTF-based system, it should be possible to restrict
>> functional
>> power states to a given set that is registered at IANA.  An example
>> would
>> be the DMTF states.  We would register a flag at IANA that indicates
> we
>> are using DMTF states only.  This would signal the management
>> application
>> that all power state IDs are in line with power state numbering as
>> defined
>> by IANA.  Analogously, ACPI and further sets could be registered at
>> IANA.
>> A fallback to Option 6 could be realized by registering a set number
> of
>> 0
>> at IANA that does not impose any limit for functional states.
>> 
>> Obviously, there are more possible options.  If you think there is a
>> better one, please send it to this list.
>> 
>> I know this discussion is not easy, but we have to have it in order to
>> make the right decision in the EMAN WG.  Please take some time and
> think
>> about what you consider to be the best way to go.  And of course send
>> questions on the issue.
>> 
>> Thanks.
>> 
>>   Juergen
>> 
>> 
>> DMTF (Distributed Management Task Force) power states:
>> - 2 (Power On)
>> - 3 (Sleep - Light)
>> - 4 (Sleep - Deep)
>> - 5 (Power Cycle (Off Soft))
>> - 6 (Power Off - Hard)
>> - 7 (Hibernate)
>> - 8 (Power Off - Soft)
>> - 9 (Power Cycle (Off Hard))
>> - 10 (Master Bus Reset)
>> - 11 (Diagnostic Interrupt (NMI))
>> - 12 (Power Off - Soft Graceful)
>> - 13 (Power Off - Hard Graceful)
>> - 14 (Master Bus Reset Graceful)
>> - 15 (Power Cycle (Off - Soft Graceful))
>> - 16 (Power Cycle (Off - Hard Graceful))
>> 
>> ACPI (Advanced Configuration and Power Interface Specification) power
>> states for PC motherboards:
>> - G3-S5 (Off-Hard)
>> - G2-S5 (Off-Soft)
>> - G1-S4 (Hibernate)
>> - G1-S3 (Sleep-Deep)
>> - G1-S2 (Sleep-Light)
>> - G1-S1 (Sleep-Light)
>> - G0-S0-P5
>> - G0-S0-P4
>> - G0-S0-P3
>> - G0-S0-P2
>> - G0-S0-P2
>> - G0-S0-P2
>> 
>> 
>> 
>> 
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
>

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 09:43:01 +0100

Hi Chris,

Thank you for your thoughts. I have three comments:

- I do not think that anyone in this WG is still proposing seriously to go for an extension of the ENTITY-MIB.  It seems to be clear that this is not sufficient.  Maybe the chairs can check if we have consensus on this issue. I guess we have it.

- I like your example below and yes, we should be able to support this. But this is not a problem of power states. This is about the parent/child concept which we have not discussed so far on this list. My concern about parent child is that it may be too simple to model complex cases like the one you describe and others. This is why I try to have a clean reference model. 

- Yes, you are right, the reference model currently has very few example scenarios with multiple instances of a port or a PC. But the only purpose of section 3.4 is to explain how the scenarios and  figures expand to multiple instances. If think this is not sufficient, I can add more explanations to it. If you think it would be helpful in any aspect to provide a figure with the PDU with 24 ports you describe in your message, I will be glad to draw this figure for you and include it in the next revision.

Thanks,

    Juergen

Am 01.03.2011 um 06:06 schrieb [email-masked]:

> Hi John and Juergen,
> 
>>> Without those two additions the work in this group can easily be covered
>>> by two additions to existing SNMP objects. First would be adding energy
>>> related fields (watts units or Kwh) to the sensor mib. The seconds would
>>> be to add better the context information (see energy aware proposal) to
>>> ability to monitor/aggregate non SNMP devices - the work here can easily
> I disagree with the argument that ENTITY-MIB can be extended to support
> power data properly.  ENTITY-MIB contains an inherent flaw, in that it
> separates physical and logical entities into distinct buckets that
> cannot overlap in sparse tables.

> WHEN -- not if -- the IETF decides to provide a meter hook for logical
> entities (individual programs, virtual machines on a shared server,
> etc.), an EMAN schema based on ENTITY-MIB would have to be forked to
> support this.  That duplication of effort is pointless.
> 
> And I say "when" because it's a matter of time.  Lots of people are
> already working on this problem because there is a huge amount of money
> involved:
> 
>   30-second internet search:
>   http://research.microsoft.com/apps/pubs/default.aspx?id=120435
> 
> The IETF exists to enable others' innovation and interoperability in
> those pursuits.  It is not our responsibility to debate the merits of
> this undertaking.  It is, however, our duty to acknowledge this pursuit
> and prepare to integrate it into schema.
> 
> So while it's good to make a nod to the predecessor ENTITY-MIB, I urge
> us to make a structural break from it.
> 
>>> interface as described in claise architecture (or some compromise as you
> I agree with John's first point ("otherwise EMAN wouldn't exist") in the
> light that, even though it may not yet be fully and properly
> articulated, there is a sense that EMAN is needed because the existing
> solution architecture just doesn't quite do what is needed.  I mean, why
> does your MIB draft exist?  You see a problem and have tried to solve it
> because a solution doesn't yet exist.
> 
> Here's a structural example to illustrate the point:
> 
> Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor types,
> the data COULD be represented.  For a single intelligent power supply on
> a server that monitors voltage, amperage, real power, apparent power,
> power factor, and frequency, we'd have 6 entities enumerated in
> ENTITY-MIB.  And all of this would need to be tied together logically
> into a "Power Supply" concept, so that'd be another entity -- 7 in
> total.
> 
> For a single server, sure, fine, do-able.  Tiny scale.
> 
> What about a 24-outlet PDU?  Or a 84-circuit panelboard?
> 
> 	http://www.kondra.com/circuit/circuit.html
> 
> 	Eaton Branch Circuit Monitoring Whitepaper:
> 	http://tinyurl.com/5rpmhrp
> 
> Managing 168 entities on a PDU or 588 entities on a panelboard is
> a ridiculous burden on the user who is consuming the agent's data.
> 
> "Bonding" these entities that are a common purpose reduces the magnitude
> by a factor of 7, and simplifies the conceptual use of the framework.
> Users don't need to think in terms of "voltage sensor for Outlet 1" but
> instead can refer to that same data as "Outlet 1's voltage."
> 
> Juergen, it seems like you're so busy focused on a conceptual model that
> real-world usability may be getting sacrificed.  Each of your examples
> only reflects a single entity at a time.  Why not kick up the examples a
> notch and model something like an intelligent PDU with the following
> properties?
> 
>   1. 24 outlets, single phase
>   2. 6 banks (4 outlets per bank), single phase
>   3. 2 inputs (3 banks per input), three phase
>   4. "Ganged" outlets (multiple outlets that are managed as one
>      construct)
>   5. High current alerts, low current alerts, circuit breaker alerts,
>      high voltage alerts (spikes), low voltage alerts (sags) -- all of
>      which can be applied to a physical entity or a logical entity
>      (like an outlet "gang")
>   6. Internal network card and metering logic
>   7. Outlets "owned" by different users (think co-location facility,
>      "context")
>   8. Manage power via 5 different interface modalities/mechanisms
>   9. Except for the existence of the outlets/banks/inputs/"gangs", all
>      other properties are potentially optional
> 
> I challenge you -- everyone participating in the EMAN list -- to model
> this level of complexity.  If your MIB can withstand this, it's a good
> MIB (IMO, of course).

> Chris

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 1 Mar 2011 01:35:22 -0800

Hi Chris,

Thanks I think that's a great challenge to throw down and we should use
that as a reference case.

I was specifically terse in my reply because I don't want to take up the
discussion or poison the pool if you will with an issue we've been
discussion off alias for almost a year. Fresh opinions are needed

Just to clarify a point though...

My concern is that in presenting the architecture in claise we made a
case to the OPSAWG that the entity mib, sensor mib and UPS mib are
insufficient to model energy management. Specifically we proposed that
we need  a model(s) of power state interface(s) *and* a parent/child
model to handle implementation that will not support SNMP.

That supposition let to the formation of this group and the need to
create a new class of data. 

This is a data modeling exercise. If you have attributes to add to a
model you first look at your existing classes to see if there's a fit.
You create a new class when there's a need to model something new ( anew
actor etc) not just because you have a few more attributes.

So with the addition of power states and parent/child we postulated that
a new class of data was needed. That would mean we could also factor
data in that class that might readily have resided in the entity, sensor
and UPS objects.

My challenge then would be that if those concepts are removed then the
burden of justifying a new class has to be taken up again. 

I presented an argument for a new class of data due to these concepts
and reason you pointed out. The sum total of those justifies a new class
of data. If those concepts are removed then IMO any object model and
proposal must re-affirm/prove the need for the new class and justify why
the existing classes are insufficient.

I don't think you can remove the assumptions and then retain the
conclusion.

HTH to clarify...
Thanks
Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 28, 2011 9:06 PM
To: John Parello (jparello)
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] modeling power states

Hi John and Juergen,

covered
energy
would
to
easily

you

Thanks,
Chris

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 10:58:15 +0100

Hi John,

I entirely agree with you that this is a data (and information) modeling exercise.

And we should stop discussing whether to do it or not, 
we should just work on the models.

There are two big issues in modeling. One is modeling power states.
I sent a message with alternative models for power states. 
Let's start discussing which of them is the best one for EMAN.

The other one is modeling the relations between parents/powerMonitors 
and childs/powered devices.  Here we have a model in the architecture draft 
and we have the reference model that I posted yesterday. 
Also here discussion is needed.

Thanks,

    Juergen

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Mar 2011 10:58:56 +0100

I am still to be convinced that an ENTITY-MIB extension is not possible.
What I understood from previous discussions is that the current
indexation scheme and mapping tables are not sufficient, but this does
not mean that an extension cannot be built. It looks like we are trying
to solve here to solve a modeling problem that is not specific only for
power entities. 

Dan

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Quittek
> Sent: Tuesday, March 01, 2011 10:43 AM
> To: [email-masked]
> Cc: eman mailing list
> - I do not think that anyone in this WG is still proposing 
> seriously to go for an extension of the ENTITY-MIB.  It seems 
> to be clear that this is not sufficient.  Maybe the chairs 
> can check if we have consensus on this issue. I guess we have it.
> 
> - I like your example below and yes, we should be able to 
> support this. But this is not a problem of power states. This 
> is about the parent/child concept which we have not discussed 
> so far on this list. My concern about parent child is that it 
> may be too simple to model complex cases like the one you 
> describe and others. This is why I try to have a clean 
> reference model. 
> 
> - Yes, you are right, the reference model currently has very 
> few example scenarios with multiple instances of a port or a 
> PC. But the only purpose of section 3.4 is to explain how the 
> scenarios and  figures expand to multiple instances. If think 
> this is not sufficient, I can add more explanations to it. If 
> you think it would be helpful in any aspect to provide a 
> figure with the PDU with 24 ports you describe in your 
> message, I will be glad to draw this figure for you and 
> include it in the next revision.
> 
> Thanks,
> 
>     Juergen
> 
> 
> >>> covered by two additions to existing SNMP objects. First would be 
> >>> adding energy related fields (watts units or Kwh) to the 
> sensor mib. 
> >>> The seconds would be to add better the context information (see 
> >>> energy aware proposal) to the entity mib. A simple on/off/standby 
> >>> state already exists in oper status.
> >>> 
> >>> easily be absorbed into the sensor and entity mibs with 
> minor additions.
> > 
> > I disagree with the argument that ENTITY-MIB can be extended to 
> > support power data properly.  ENTITY-MIB contains an 
> inherent flaw, in 
> > that it separates physical and logical entities into 
> distinct buckets 
> > that cannot overlap in sparse tables.
> 
> > 
> 
> > this undertaking.  It is, however, our duty to acknowledge this 
> > pursuit and prepare to integrate it into schema.
> > 
> >>> you listed with IANA interfaces). It must also contain 
> the addition 
> >>> of parent/child/aggregator relationship for non SNMP 
> energy management.
> >> 
> >> I would not accept the first one as a technical argument, On your 
> >> second argument I would reply that providing good interfaces for 
> >> building sophisticated applications is certainly an 
> objective of our 
> >> work in EMAN, but probably not the one with top priority.
> > 
> > I agree with John's first point ("otherwise EMAN wouldn't 
> exist") in 
> > the light that, even though it may not yet be fully and properly 
> > solution architecture just doesn't quite do what is needed. 
>  I mean, 
> > why does your MIB draft exist?  You see a problem and have tried to 
> > solve it because a solution doesn't yet exist.
> > 
> > Using ENTITY-MIB and extending it to include kW, kWh, etc. sensor 
> > types, the data COULD be represented.  For a single 
> intelligent power 
> > supply on a server that monitors voltage, amperage, real power, 
> > apparent power, power factor, and frequency, we'd have 6 entities 
> > enumerated in ENTITY-MIB.  And all of this would need to be tied 
> > together logically into a "Power Supply" concept, so that'd 
> be another 
> > entity -- 7 in total.
> > 
> > Managing 168 entities on a PDU or 588 entities on a panelboard is a 
> > ridiculous burden on the user who is consuming the agent's data.
> > 
> > "Bonding" these entities that are a common purpose reduces the 
> > magnitude by a factor of 7, and simplifies the conceptual 
> use of the framework.
> > Users don't need to think in terms of "voltage sensor for Outlet 1" 
> > but instead can refer to that same data as "Outlet 1's voltage."
> > 
> > Juergen, it seems like you're so busy focused on a conceptual model 
> > that real-world usability may be getting sacrificed.  Each of your 
> > examples only reflects a single entity at a time.  Why not 
> kick up the 
> > examples a notch and model something like an intelligent 
> PDU with the 
> > following properties?
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Mar 2011 11:01:04 +0100

Hi Chris,

See in-line. 

Regards,

Dan

(speaking as contributor) 

> Behalf Of [email-masked]
> Sent: Tuesday, March 01, 2011 7:06 AM
> I disagree with the argument that ENTITY-MIB can be extended 
> to support power data properly.  ENTITY-MIB contains an 
> inherent flaw, in that it separates physical and logical 
> entities into distinct buckets that cannot overlap in sparse tables.
> 

Can you detail what is this inherent flaw? I am afraid that I do not
understand what 'distinct buckets that ... overlap in sparse tables'
are. Maybe an example would help.

> WHEN -- not if -- the IETF decides to provide a meter hook 
> for logical entities (individual programs, virtual machines 
> on a shared server, etc.), an EMAN schema based on ENTITY-MIB 
> would have to be forked to support this.  That duplication of 
> effort is pointless.
> 

You seem to be saying that the Entity MIB as it stands is not fit for
modeling virtual machines on a shared server. I tend to agree. My
question is however how is this related to the Power MIB? I do not think
it's a good idea to develop a data model for VMs in the Power MIB. The
WG is not chartered for this either, I think.

> And I say "when" because it's a matter of time.  Lots of 
> people are already working on this problem because there is a 
> huge amount of money
> involved:
> 
> The IETF exists to enable others' innovation and 
> interoperability in those pursuits.  It is not our 
> responsibility to debate the merits of this undertaking.  It 
> is, however, our duty to acknowledge this pursuit and prepare 
> to integrate it into schema.
> 
> So while it's good to make a nod to the predecessor 
> ENTITY-MIB, I urge us to make a structural break from it.

I tend to disagree here. If there is something missing in the Entity MIB
it should be added there. There is merit in providing a consistent way
of addressing managed entities. Being able to point to a managed power
entity using the Entity MIB indexation seems to be a useful thing from
an operational perspective. 

> > > of parent/child/aggregator relationship for non SNMP 

Yes, but all these do not seem to be specific only to managed power
devices. 

...

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 11:08:42 +0100

Hi Dan,

The problem with the Entity MIB is that we cannot use it for reporting 
on remote devices, for example, a PoE switch reporting on PoE 
powered devices connected to it. 

We will still provide means to use indices provided by Entity MIB 
(entPhysicalIndex) when a device reports on internal components.

    Juergen
 
Am 01.03.2011 um 10:58 schrieb Romascanu, Dan (Dan):

>> for logical 
>> interoperability in

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Mar 2011 11:18:20 +0100

Hi Juergen,

But we can do this using something similar to the LLDP-MIB and
LLDP-MED-MIB. True, these are not IETF MIB modules (they were developped
in the IEEE 802.1 and TIA 41.4 respectively), but they have solved this
modeling problem, and also developped the protocol to report on the
state of devices connected to a switch. Actually the LLDP-MED-MIB (ANSI
TIA 1057) reports power information from end-devices. 

Regards,

Dan

> Sent: Tuesday, March 01, 2011 12:09 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; eman mailing list
> The problem with the Entity MIB is that we cannot use it for 
> reporting on remote devices, for example, a PoE switch 
> reporting on PoE powered devices connected to it. 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 11:20:32 +0100

> to solve here to solve a modeling problem that is not specific only for

I guess like Dan, I would appreciate a clear and yet concise
explanation why the ENTITY-MIB does not work and why it is not
possible or awkward to extend the ENTITY-MIB to make it work. If
someone can write this up as a 2-page I-D (plus N page boilerplate of
the day ;-), I think we will have a much easier time to put this
discussion to an end.

Perhaps this text can be based on the text currently in section 3 of
<draft-verges-eman-separate-modules-mib-00> with some more details
added.

/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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 11:22:25 +0100

> powered devices connected to it. 

Would contexts not work?

/js

---

From: Rolf Winter <[email-masked]>
Date: Tue, 1 Mar 2011 10:24:18 +0000

Sounds like a reasonable request. Could also go into the requirements draft, either section 3 or section 7?

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: Dienstag, 1. März 2011 11:21
> To: eman mailing list

---

From: Rolf Winter <[email-masked]>
Date: Tue, 1 Mar 2011 10:39:43 +0000

Hi,

I think acid test-type of questions like this are very useful and I wish more "customers" of this work would throw them at the EMAN WG. Some of this relates to the type of information that needs to be presented which is the easy part I would assume. The structural aspect of is (parent-child/aggregation etc.) has not received a lot of attention, other than that people seem to agree that "something in this direction" is indeed needed for energy management. 

Best,

Rolf

> [email-masked]
> Sent: Dienstag, 1. März 2011 06:06
> magnitude

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 11:50:23 +0100

Hi Juergen,

I assume you refer to the SNMP context engineID.

Yes, this can be used as long as the remote device has one.
If not, something else is needed.

    Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 12:15:48 +0100

> If not, something else is needed.

I am talking about an SNMP context as defined in RFC 3411 section
3.3.1 and in particular the usage of contextName as a mechanism to
select different MIB trees. This is what the ENTITY-MIB calls a
logical entity.

The default contextName ("") is the zero-length string, so on a power
over ethernet switch, we have objects reporting the energy consumption
of the components of the device itself (physical entities). If you
plug a phone into the switch and the switch is able to determine power
consumption of the remote phone device, you can instantiate another
MIB tree that reports the components of the phone as physical entities
under a different contextName (e.g., "port-N"). The ENTITY-MIB allows
you to discover which contexts are available.

/js

---

From: Thomas Dietz <[email-masked]>
Date: Tue, 1 Mar 2011 11:17:20 +0000

I agree with Rolf that such an explanation would nicely fit into the
requirements draft. I understand that it is not so easy to model the
reporting for values that come from another device that does not support
SNMP itself. But since I have not a concise knowledge of all those MIBs out
there it would be nice to get an overview what we have there and why it
might not fit.

Best Regards,

Thomas

-- 
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> Rolf Winter
> Sent: Tuesday, March 01, 2011 11:24 AM
> To: Juergen Schoenwaelder; eman mailing list

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 1 Mar 2011 15:07:11 +0100

Hi Juergen,

Thank you for this hint.

Let's investigate how far we can get with SNMP contexts.

    Juergen

---

From: [email-masked]
Date: Tue, 1 Mar 2011 08:00:32 -0800

> the day ;-), I think we will have a much easier time to put this

Hi Juergen (S) and Dan,

How would the model for a virtual entity like an outlet gang and
physical outlets work?

   Entities:
   1. Outlet #1
   2. Outlet #2
   3. Outlet #3
   4. Outlet #4
   5. Outlet Gang #1 (combo of Outlets #1 and #2)
   6. Outlet Gang #2 (combo of Outlets #2 and #4)

This scenario does occur with certain vendors iPDUs.

Entities 5 and 6 in the list above are "virtual," in that they do not
reflect a physically concrete object in the real world but instead are
logical containers that simplify management of the associated real
outlets.

As far as I understand, entPhysicalTable would contain Outlets #1 thru
#4 and entLogicalTable would contain the Outlet Gangs #1 and #2.  Is
this your understanding, too?

In an EMAN schema based on ENTITY-MIB, how would this work?  How would
dual-indexing to both entPhysicalTable and entLogicalTable be done?

Thanks,
Chris

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Mar 2011 17:23:11 +0100

> Sent: Tuesday, March 01, 2011 6:01 PM
> To: eman mailing list; Romascanu, Dan (Dan); Juergen Quittek; 
> Juergen Schoenwaelder
> > > indexation scheme and mapping tables are not sufficient, but this 
> > > does not mean that an extension cannot be built. It looks like we 
> > > are trying to solve here to solve a modeling problem that is not 
> > > specific only for power entities.
> >
> How would the model for a virtual entity like an outlet gang 
> and physical outlets work?
> 
>    Entities:
>    1. Outlet #1
>    2. Outlet #2
>    3. Outlet #3
>    4. Outlet #4
> Entities 5 and 6 in the list above are "virtual," in that 
> they do not reflect a physically concrete object in the real 
> world but instead are logical containers that simplify 
> management of the associated real outlets.
> 
> #4 and entLogicalTable would contain the Outlet Gangs #1 and 
> #2.  Is this your understanding, too?
> 
> In an EMAN schema based on ENTITY-MIB, how would this work?  
> How would dual-indexing to both entPhysicalTable and 
> entLogicalTable be done?
> 
> Thanks,
> Chris
> 

How is this problem different from the one of managing a stack or
cluster of physical devices? Ethernet switch vendors have done this for
a decade and more. You just define entries for the Outlet Gangs #1 and
#2 also in the entPhysical table, use the entPhysicalContainsTable to
define the containment relations with Outlet #1-4 and map them
one-to-one to the entries in the entLogicalTable.  

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 22:23:45 +0100

> This scenario does occur with certain vendors iPDUs.

What exactly is an outlet gang? My knowledge of English is somewhat
limited when it comes to such terms and it is important that I
understand what it is to answer your question.
 
> logical containers that simplify management of the associated real

Is #2 really part of both Outlet Gangs? What can I do with such an
outlet gang?

> this your understanding, too?

Most likely not (most likely since I am not sure what an outlet gang
is ;-). A logical entity is defined in RFC 4133 as follows:

     A managed system contains one or more logical entities, each
     represented by at most one instantiation of each of a particular
     set of MIB objects.  A set of management functions is associated
     with each logical entity.  Examples of logical entities include
     routers, bridges, print-servers, etc.

The 'logical entity' term might have been a confusing choice. But
anyway, a 'logical entity' means "an SNMP context hosting a MIB object
tree". In other words, an SNMP agent can host multiple independent MIB
object trees and contexts select which MIB object tree you access. A
logical entity is pretty much the same as an SNMP context (at least
for the discussion we have here, an SNMP purist likely would say that
a logical entity is one way of using SNMP contexts).

> dual-indexing to both entPhysicalTable and entLogicalTable be done?

The SNMP engine representing your outlets has a default SNMP context
(contextName ""), which is a 'logical entity'. In this default context
(logical entity), you find the entPhysicalTable entries representing
the physical components and sensors of the device.

If some power consuming device A is plugged into one of your outlets
and device A provides additional power sensors and your devices can
access them remotely (via some implementation specific mechanism), you
can represent the power consumer A in a seperate SNMP context (aka
logical entity, e.g. contextName="A"). The MIB tree of this logical
entity will provide the entPhysicalTable entries representing the
physical components and sensors of power consumer A. The
entLogicalTable in the default context lists the logical contexts that
are available. In other words, an application can access the default
context and read information about the physical components. To
discover any addition logical contexts, your application reads the
entLogicalTable. Once you learned which logical contexts exist, you
access the agent with the appropriate contextName etc. and you can
read information from remote devices, such as device A.

If you have a collection of outlets somehow bundled together, you can
model this by putting the physical components into different 'modules'
(see PhysicalClass of the ENTITY-MIB). The ENTITY-MIB provides some
support for expressing this kind of relationships since routers and
switches often have a modular structure and power supplies might be
similar (but I am obviously no an expert in that domain).

/js

---

From: [email-masked]
Date: Tue, 1 Mar 2011 14:25:10 -0800

> understand what it is to answer your question.

An outlet gang is a collection of outlets that appear as a single
entity.  The corresponding class diagram might be:

   +------------------+           +--------------+
   | OutletGangObject |<>---------| OutletObject |
   +------------------+           +--------------+

Where the "<>---" operator is the UML "composite" operator.

For example, let's say a server has redundant power supplies connected
to the same PDU (Outlets 1 and 7).  You can create an outlet gang called
"Server Outlets" that are a collection of Outlets 1 and 7.  Then the
"Server Outlets" entity can be queried for power data, control, etc.

> Is #2 really part of both Outlet Gangs? What can I do with such an

I think I answered this question above in the explanation, but let me
know if it was unclear.

> similar (but I am obviously no an expert in that domain).

Now it's my turn to be confused.  I'm definitely not understanding
ENTITY-MIB, it seems.  I interpreted "Physical" to mean "real-world
instantiations of an object" and "Logical" to mean "objects that have no
physical substance (like software)".

Given that the notion of an outlet gang is virtual -- it's just a more
user-friendly interface -- wouldn't that go into entLogicalTable while
the outlets themselves go into entPhysicalTable?

More fully, I'd appreciate a diagram of how you'd suggest representing
the 24-outlet PDU scenario described earlier using ENTITY-MIB.  Perhaps
that would help in understanding ENTITY-MIB's structure.

Thanks,
Chris

---

From: [email-masked]
Date: Tue, 1 Mar 2011 14:30:12 -0800

Hi Dan,

I'm going to assume that my follow up to this was covered in the
previous reply.  While the scenario that I've described talks about this
in terms of Outlet Gangs (because that's what I know), you could apply
the same question to that of a VMware ESXi server running multiple
Windows and Linux VMs.  If an agent wanted to expose the VMware ESXi
server's power consumption and allocate power to each VM, how would that
structure work in relation to ENTITY-MIB?

   +--------------------+
   | VMware server      |
   |                    |
   |  +--------------+  |
   |  | Windows VM 1 |  |
   |  +--------------+  |
   |                    |
   |  +--------------+  |
   |  | Windows VM 2 |  |
   |  +--------------+  |
   |                    |
   |  +--------------+  |
   |  | Linux VM     |  |
   |  +--------------+  |
   |                    |
   |  +--------------+  |
   |  | Solaris VM   |  |
   |  +--------------+  |
   |                    |
   +--------------------+

Would there be 5 entities listed in entPhysicalTable, one for each of
the above items?  (It's kinda trippy since the VM's aren't "physical.")

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 1 Mar 2011 23:51:50 +0100

> entity.  The corresponding class diagram might be:

OK, I think I got it.
 
> I think I answered this question above in the explanation, but let me

So you confirm that an outlet can be part of two different outlet
gangs at the same time? I think this is an important detail to know.

> physical substance (like software)".

Yes, I assume you misinterpret the terms by giving "logical" an
interpretation that is not defined in RFC 4133. Please check again the
text in RFC 4133.

> the outlets themselves go into entPhysicalTable?

No.

>      other properties are potentially optional

I can't do this without your help because I do not understand the
example. As mentioned before, I am pretty much clueless about power
supplies and their terminology. I do not know what it means for an
outlet to be "owned" by a user. I do not know what 5 different
interface modalities/mechanisms are. What are banks? Where exactly are
the voltage / current measurements taken?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Mar 2011 11:42:14 +0100

> Sent: Wednesday, March 02, 2011 12:30 AM
> To: Romascanu, Dan (Dan)
> Cc: eman mailing list; Juergen Quittek; Juergen Schoenwaelder
> > cluster of physical devices? Ethernet switch vendors have done this 
> > for a decade and more. You just define entries for the 
> Outlet Gangs #1 
> > and
> I'm going to assume that my follow up to this was covered in 
> the previous reply.  While the scenario that I've described 
> talks about this in terms of Outlet Gangs (because that's 
> what I know), you could apply the same question to that of a 
> VMware ESXi server running multiple Windows and Linux VMs.  
> If an agent wanted to expose the VMware ESXi server's power 
> consumption and allocate power to each VM, how would that 
> Would there be 5 entities listed in entPhysicalTable, one for 

This looks indeed like a different application. The VMs are logical
entities, the server is a physical entity. They can be modeled easily
with the entity MIB and the mapping table provides you the picture of
what runs where. However I may be missing something in the discussion
because I do not understand what 'allocate power to each VM' means. 

Dan

---

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Mar 2011 16:37:45 +0100

Dear all,
> - I do not think that anyone in this WG is still proposing seriously to go for an extension of the ENTITY-MIB.  It seems to be clear that this is not sufficient.  Maybe the chairs can check if we h…
The issue is more about:
1. could we solve the problems specified in draft-ietf-eman-requirements 
with the ENTITY-MIB?
2.  if yes, do we chose to do so? So consensus only addresses this part.

We discussed 1. when presenting before the WG was created, i.e. in 
OPSAWG, and my recollection is that we concluded that the ENTITY-MIB was 
not good enough. I remember one of the conclusion at IETF78: the 
ENTITY-MIB is good to represent something on the device itself, but not 
good enough to represent something outside of the box, i.e. a child. 
Then the notion of SNMP context was put in the picture...
However, I can't find any written explanation of the reasons why the 
ENTITY-MIB is not suitable.
http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.1 
addresses ENTITY-STATE-MIB
http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.2 
addresses ENTITY-SENSOR-MIB

As proposed in this email thread, as a WG co-chair, I would like to see 
some summary text of why the ENTITY-MIB is not good enough. Ideally in 
requirements draft (a new section 7.1.x)  or potentially in the framework.

Another point, which seems related.
It seems that the use cases described in draft-ietf-eman-requirements 
don't cover the ones mentioned by Chris Verges.
For example, Chris already mentioned the notion of redundant power 
supplies in his email in 
http://www.ietf.org/mail-archive/web/eman/current/msg00112.html and gave 
the same example in this email thread again.
So, we should discuss whether we want to solve this redundant power 
supply issue. If yes, provide some text in draft-ietf-eman-requirements 
for this.
And apparently, this is this use case that prevents from using the 
ENTITY-MIB.

Finally, I agree on the data model exercise, also mentioned in this 
email thread, which we must work on.

Regards, Benoit, co-chair hat on.

---

From: [email-masked]
Date: Wed, 2 Mar 2011 08:29:14 -0800

Hi Dan,

Let's say the VMware server is drawing 10.0A total.  The SNMP agent on
the VMware machine reports 10.0A for the VMware server entity.

That same SNMP agent is aware that multiple VMs are running on the
machine, however, and attempts to use the CPU utilization for each VM to
allocate the 10.0A total to a VM.  So for example:

   Entity             CPU%      Amps
   ---------------------------------
   Windows VM 1        27%      2.7A
   Windows VM 2        35%      3.5A
   Linux VM            20%      2.0A
   Solaris VM          18%      1.8A
   ---------------------------------
   VMware server      100%     10.0A

In this case, we want to display all five of these rows to give the
end user a full picture of what's going on inside the server.

Companies like Power Assure in Santa Clara, CA are already doing this
kind of utilization-to-consumption mapping, and are extremely accurate
with it.  We do need to provide a hook to get this kind of detailed
data as a result.

How would this work with ENTITY-MIB's structure?

   entLogicalTable
   +-------+---------------+
   | Index | Name          |
   +-------+---------------+
   |       |               |
   +-------+---------------+

   entPhysicalTable
   +-------+---------------+
   | Index | Name          |
   +-------+---------------+
   |       |               |
   +-------+---------------+

   entLPMappingTable (?)
   +--------------+---------------+
   | LogicalIndex | PhysicalIndex |
   +--------------+---------------+
   |              |               |
   +--------------+---------------+

Thanks,
Chris

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Mar 2011 17:36:13 +0100

> Sent: Wednesday, March 02, 2011 6:29 PM
> To: Romascanu, Dan (Dan)
> Let's say the VMware server is drawing 10.0A total.  The SNMP 
> agent on the VMware machine reports 10.0A for the VMware 
> server entity.
> 
> That same SNMP agent is aware that multiple VMs are running 
> on the machine, however, and attempts to use the CPU 
> utilization for each VM to allocate the 10.0A total to a VM.  
> So for example:
> 
>    Entity             CPU%      Amps
> In this case, we want to display all five of these rows to 
> give the end user a full picture of what's going on inside the server.
> 
> Companies like Power Assure in Santa Clara, CA are already 
> doing this kind of utilization-to-consumption mapping, and 
> are extremely accurate with it.  We do need to provide a hook 
> to get this kind of detailed data as a result.
> 

>From an Entity MIB modeling this is really a simple case. 

You have 
- one entry in the entPhysicalTable - the server
- four entries in the entLogicaltable  - the VMs
- four entries in the entLPMappingTable mapping the index of the VM
server to the 4 indices of the VMs respectively

The MIB we design would be either indexed by LogicalIndex or point to
the value of the Index (we need an accessible variable for this) and
will include an 'estimate power consumption' object

Now I assume that you power guys know how to provide the value for power
estimate of a VM per server machine  - because for me this is magic
(i.e. technology that I do not understand)

Dan

---

From: [email-masked]
Date: Wed, 2 Mar 2011 09:14:18 -0800

Hi Dan,

If we use the LogicalIndex for the EMAN MIB, then we lose the ability to
represent the VMware server itself in the EMAN structure unless we add
another "pseudo-entry" in the LogicalTable.  Is it common practice for
agents that implement ENTITY-MIB to enumerate an entity in both the
Physical and Logical tables as a 1:1 mapping (minimum)?

If we create a new "Index" variable, we'd also need to introduce a
method to "multiplex" on the proper table -- Logical or Physical.  So
we'd have to add an additional variable to the EMAN entity table,
"LogicalOrPhysical", which then adds complexity and burden onto the
consuming user.

This is getting at the heart of why I believe ENTITY-MIB won't
necessarily work for EMAN's needs.  There's always something else that
is needed to make it work, some additional layer of complexity in either
understanding or actual use.

Thanks,
Chris

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 2 Mar 2011 18:22:38 +0100

Hi Benoit,

Am 02.03.2011 um 16:37 schrieb Benoit Claise:

> 1. could we solve the problems specified in draft-ietf-eman-requirements with the ENTITY-MIB?
> We discussed 1. when presenting before the WG was created, i.e. in OPSAWG, and my recollection is that we concluded that the ENTITY-MIB was not good enough. I remember one of the conclusion at IETF78: the ENTITY-MIB is good to represent something on the device itself, but not good enough to represent something outside of the box, i.e. a child. Then the notion of SNMP context was put in the picture...
> However, I can't find any written explanation of the reasons why the ENTITY-MIB is not suitable.
> http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.1 addresses ENTITY-STATE-MIB
> http://tools.ietf.org/html/draft-ietf-eman-requirements-00#section-7.1.2 addresses ENTITY-SENSOR-MIB
> 
> As proposed in this email thread, as a WG co-chair, I would like to see some summary text of why the ENTITY-MIB is not good enough. Ideally in requirements draft (a new section 7.1.x)  or potentially in the framework.

So far I thought, that the Entity MIB does not meet EMAN requirements.
However, with what I learned from Juergen S. maybe it does.
Anyway, we will add the conclusion of the discussion going on on this list to the requirements draft.

> It seems that the use cases described in draft-ietf-eman-requirements don't cover the ones mentioned by Chris Verges.
> For example, Chris already mentioned the notion of redundant power supplies in his email in http://www.ietf.org/mail-archive/web/eman/current/msg00112.html and gave the same example in this email thread again.
> So, we should discuss whether we want to solve this redundant power supply issue. If yes, provide some text in draft-ietf-eman-requirements for this.
> And apparently, this is this use case that prevents from using the ENTITY-MIB.

I don't think it would be a good option to ignore it and state: Sorry, if you have a dual power supply you can't use eman MIBs.

Thanks,

    Juergen Q.

> Finally, I agree on the data model exercise, also mentioned in this email thread, which we must work on.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Mar 2011 18:24:21 +0100

Hi Chris,

See in-line. 

Regards,

Dan

> Sent: Wednesday, March 02, 2011 7:14 PM
> To: Romascanu, Dan (Dan)
> If we use the LogicalIndex for the EMAN MIB, then we lose the 
> ability to represent the VMware server itself in the EMAN 
> structure unless we add another "pseudo-entry" in the 
> LogicalTable.  Is it common practice for agents that 
> implement ENTITY-MIB to enumerate an entity in both the 

Yes - you define a PhysicalVMWareServer and LogicalVMWareServer and a
one to one mapping. This is what is down when managing stacks of
switches or clusters of rounding devices. 

> If we create a new "Index" variable, we'd also need to 
> introduce a method to "multiplex" on the proper table -- 
> Logical or Physical.  So we'd have to add an additional 
> variable to the EMAN entity table, "LogicalOrPhysical", which 
> then adds complexity and burden onto the consuming user.

The overhead is minimal, and you can use the same indices as in the
Entity MIB to avoid this.

> 
> This is getting at the heart of why I believe ENTITY-MIB 
> won't necessarily work for EMAN's needs.  There's always 
> something else that is needed to make it work, some 
> additional layer of complexity in either understanding or actual use.

Reinventing something new is more overhead IMO. The Entity MIB is
designed to provide a basic common structure to managed different
entities and yes - in many cases you need to add something else, but
this is simpler than writing all from scratch and making it usable only
for one application (EMAN in this case).

---

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Mar 2011 18:15:35 +0100

Dear all,

As far as we understand the power monitoring for virtual machines is not 
on our charter
However, if we have a flexible data model that allows us to cover this 
case as well, great.

Regards, co-chair hats on, Bruce and Benoit,

---

From: Benoit Claise <[email-masked]>
Date: Wed, 02 Mar 2011 18:25:44 +0100

Hi Juergen,
> Anyway, we will add the conclusion of the discussion going on on this list to the requirements draft.
thanks.
> I don't think it would be a good option to ignore it and state: Sorry, if you have a dual power supply you can't use eman MIBs.
Agreed.

Regards, Benoit.

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 2 Mar 2011 13:49:24 -0800

I would also add that allocating power and energy among virtual machines
could be done many different ways so is unlike other topics we have
discussed
where there is a specific flow of electrons that is being measured or
estimated.
To me the key is that I would not want the email reflector or meeting time
to
be burdened by the topic.
--Hat still on, Bruce

On Wed, Mar 2, 2011 at 9:15 AM, Benoit Claise <[email-masked]> wrote:

> Dear all,
>
> As far as we understand the power monitoring for virtual machines is not on
> our charter
> However, if we have a flexible data model that allows us to cover this case
> as well, great.
>
-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 2 Mar 2011 23:44:33 +0100

> will include an 'estimate power consumption' object

Dan,

I am not sure I can follow you. Where is the values be reported? For
virtualization, I think the most logical approach would be that the
VMs run their own SNMP agents (as ours do) and that the VMs would have
virtual power resources that they report in their ENTITY-MIB tree.  In
other words, the hypervisor (or whatever piece of software does the
virtualization) should provide a virtualized power sensor to the
virtual machines and you take it from there.

If it is important to discover which VMs run on a given physical
server, one could use the entLogicalTable of the ENTITY-MIB on the
physical server to point to the SNMP agents running on the VMs.

/js

---

From: [email-masked]
Date: Wed, 2 Mar 2011 18:07:48 -0800

On Wed, Mar 02, 2011 at 01:49:24PM -0800, Bruce Nordman wrote:
> I would also add that allocating power and energy among virtual
> machines could be done many different ways so is unlike other topics
> we have discussed where there is a specific flow of electrons that is
> being measured or estimated.  To me the key is that I would not want
> the email reflector or meeting time to be burdened by the topic.

Hi Bruce and Benoit,

Agreed that it shouldn't be a major point, but it needs to be something
that we add to the use case list.  In principle, it is a problem of
defining a time-share in the specific flow of electrons, which could
theoretically apply to other conditions beyond virtual machines.

It gets to my earier point about modeling "power/electricity" rather
than a specific type of entity ("server" or "switch.")

Thanks,
Chris

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Mar 2011 08:21:47 +0100

> From: Juergen Schoenwaelder 
> [mailto:[email-masked]] 
> Sent: Thursday, March 03, 2011 12:45 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; eman mailing list; Juergen Quittek
> I am not sure I can follow you. Where is the values be 
> reported? For virtualization, I think the most logical 
> approach would be that the VMs run their own SNMP agents (as 
> ours do) and that the VMs would have virtual power resources 
> that they report in their ENTITY-MIB tree.  In other words, 
> the hypervisor (or whatever piece of software does the
> virtualization) should provide a virtualized power sensor to 
> the virtual machines and you take it from there.
> 
> If it is important to discover which VMs run on a given 
> physical server, one could use the entLogicalTable of the 
> ENTITY-MIB on the physical server to point to the SNMP agents 
> running on the VMs.
> 
> /js
> 

Hi Juergen,

Indeed, the more general solution (or one of them) is the one that you
point to. You still need to define a new object in a table augmenting
the ENTITY-MIB logical table. 

Still the major problem for me (and it may be my lack of knowledge on
how power per VM is estimated or measured) seems to me how you estimate
the power consumed by each VM. My common sense tells me that this is
function not only of SW but also of the HW it runs on (i.e. the same VM
may 'suck' different power on my Dell D630 than on my MacBook). Maybe I
am wrong, maybe the power people know how to cope with this. 

Dan

---

From: [email-masked]
Date: Wed, 2 Mar 2011 23:46:43 -0800

> > the virtual machines and you take it from there.

The VMs don't always know their power consumption, but the host
operating system does.

   1. The host OS (VMware ESXi server in the example) reads the power
      measuremrents from the hardware on the motherboard

   2. The host OS also tracks the CPU utilization of each of the VMs

   3. Therefore, the host OS can correlate power measurements with CPU
      utilization

   4. The guest VMs are ignorant of all of this because they don't know
      their CPU utilization relative to other VMs nor do they have
      direct access to the power measurement hardware on the motherboard
      (they're virtual, of course)

> the ENTITY-MIB logical table.

I'm still struggling with some of these ENTITY-MIB concepts.  They
really do seem to be convoluted and require either highly specific
(esoteric?) domain knowledge about ENTITY-MIB to be useful or "hacks" to
get it to do what we want.

Certainly, I tend to be vocal.  :-)  What do others (that we haven't
heard from) think?

> am wrong, maybe the power people know how to cope with this.

CPU utilization is the metric that ties this together.  You really
should check out these guys:  http://www.powerassure.com.

Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2011 08:51:02 +0100

> the ENTITY-MIB logical table. 

Not sure what this object would be.

> am wrong, maybe the power people know how to cope with this. 

I share your curiosity how this calculation might work but then I also
understand that if customers demand numbers, they are provided with
numbers, whatever the accuracy really is. I have seen enough fake SNMP
counters in my life. ;-)

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Mar 2011 08:59:16 +0100

...

> Not sure what this object would be.

Something like entLogicalPowerConsume expressed in miliWatts or similar.
The output of what you call 'virtualized power sensor' I guess.

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2011 09:06:45 +0100

> Certainly, I tend to be vocal.  :-)  What do others (that we haven't

My understanding is that this IETF WG is chartered to produce
standards-track MIB modules and thus this requires some willingness to
understand how SNMP and core IETF MIB modules work. You might call
this "highly specific (esoteric?) domain knowledge" but then I am
wondering how you write this down in a way that it passes the IESG.

I jumped into this discussion because I sensed that people have a
completely wrong idea of the ENTITY-MIB, in particular what logical
entities are. I do not know where this confusion is coming from, I can
only offer help so that the WG understands what the ENTITY-MIB and
SNMP has to offer.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Mar 2011 09:17:37 +0100

> Sent: Thursday, March 03, 2011 10:07 AM
> Cc: Romascanu, Dan (Dan); eman mailing list; Juergen Quittek
> > (esoteric?) domain knowledge about ENTITY-MIB to be useful 
> or "hacks" 
> > to get it to do what we want.
> > 
> standards-track MIB modules and thus this requires some 
> willingness to understand how SNMP and core IETF MIB modules 
> work. You might call this "highly specific (esoteric?) domain 
> knowledge" but then I am wondering how you write this down in 
> a way that it passes the IESG.
> 
> I jumped into this discussion because I sensed that people 
> have a completely wrong idea of the ENTITY-MIB, in particular 
> what logical entities are. I do not know where this confusion 
> is coming from, I can only offer help so that the WG 
> understands what the ENTITY-MIB and SNMP has to offer.
> 
> /js
> 

I agree to what Juergen says here. There needs to be a good
justification to invent something new rather than re-use concepts that
are shared by many MIB and SNMP management applications. 

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2011 09:20:49 +0100

> The output of what you call 'virtualized power sensor' I guess.

But why? The purpose of the entLogicalTable is to point to other SNMP
contexts where you find the information and then you access the
context pointed to in order to read the information you are interested
in. For me, virtualization means that the VM provides a virtual notion
of power sensors to the OSes running in the VMs; the SNMP context
representing your Linux VM would then host a physical entity reporting
power states.  This is consistent with how I get network interface
statistics and CPU usage statistics from VMs today - I talk to the
SNMP agent on the VMs.

People likely argue that this is a purly academic view since some
common virtualization solutions simply do not provide the relevant
information to the VMs and instead an add-on piece of software on the
physical server is supposed to report the information instead of the
SNMP engines on the virtual machines. But even then, you can use
different contextNames to represent the virtualized power states and
sensors with a single SNMP agent running on a pysical server.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 3 Mar 2011 09:27:49 +0100

> Sent: Thursday, March 03, 2011 10:21 AM
> To: Romascanu, Dan (Dan)
> But why? The purpose of the entLogicalTable is to point to 
> other SNMP contexts where you find the information and then 
> you access the context pointed to in order to read the 
> information you are interested in. For me, virtualization 
> means that the VM provides a virtual notion of power sensors 
> to the OSes running in the VMs; the SNMP context representing 
> your Linux VM would then host a physical entity reporting 
> power states.  This is consistent with how I get network 
> interface statistics and CPU usage statistics from VMs today 
> - I talk to the SNMP agent on the VMs.
> 
> People likely argue that this is a purly academic view since 
> some common virtualization solutions simply do not provide 
> the relevant information to the VMs and instead an add-on 
> piece of software on the physical server is supposed to 
> report the information instead of the SNMP engines on the 
> virtual machines. But even then, you can use different 
> contextNames to represent the virtualized power states and 

Got it. You are right. 

Dan

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 3 Mar 2011 16:20:48 +0100

Hi Juergen,

If we use the Entity MIB for reporting on power values for remote PCs
aren't we over-stretching the Entity MIB a bit?

In the introduction of RFC4133, there is stated:

  'Effectively, there is some "overall" physical entity which houses 
   the sum of the things managed by that one agent, i.e., there are 
   multiple "logical" entities within a single physical entity.'

We exceed this limitation, when we report on several entities 
that are not located within a single physical entity.

    Juergen Q.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2011 20:52:43 +0100

> that are not located within a single physical entity.

So all we have is a philosophical concern? What do you think is the
proper way in SNMP to report data about remote systems? Are contexts
not the natural way of doing this?

I went to the requirements document and searched for remote but could
not find a decent description what this remote monitoring requirement
is. The framework document mentions remote somewhere but does not
provide any details either. So where can I find more details?

/js

PS: Out of curiosity, I actually like to know how the devices this
    group models actually retrieve measurement data from remote
    systems.

---

From: [email-masked]
Date: Thu, 3 Mar 2011 12:55:55 -0800

> provide any details either. So where can I find more details?

I'll address the above points in a separate thread that will be started
later tonight.

>     group models actually retrieve measurement data from remote

Modbus, BACnet, etc.  There are lots of non-SNMP protocols that can
transmit information to a collector.  This is, I believe, the principle
behind the Cisco Mediator product, which is gaining a lot of traction as
an IP gateway/bridge for the non-SNMP products.

Chris

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Thu, 3 Mar 2011 22:24:24 -0600

I think the issue here is that there a lot of people on this list who undoubtedly have personal experience in implementing the ENTITY-MIB and the physical and logical tables which some here may lack.  I certainly know that I am no expert in the practical aspects of how these tables are implemented in actual practice.  I would expect that there may be common or de facto standard ways of using them that aren't obvious directly from the base specifications.

Does anyone on this list know of any publicly available sources of information on the practical side of implementing these objects and how they are actually used in real systems?  Tutorials?  Books?  Archived discussions?  Open source code?  I for one would like to review such information if it is available.

Thanks,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

> Behalf Of Juergen Schoenwaelder
> Sent: Thursday, March 03, 2011 3:07 AM
> or "hacks" to

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 4 Mar 2011 10:30:27 +0100

> not the natural way of doing this?

The question we need to answer is not a philosophical one, but a 
technical one:
Is there anything in the Entity MIB module that breaks if we extend it
beyond the scope that the IETF originally limited it to? 
The question is valid, because we can assume that when the Entity
MIB was written, checked, and implemented, probably everyone had 
the original scope in mind and did not check if things would still work
with our intended extension.

I started writing a summary on the applicability of the Entity MIB to eman.
For this, I don't want to ignore such a sentence from RFC 4133 as the one
cited above. I rather want to be able to clearly state: "We are extending 
the Entity MIB beyond its original scope and there is no technical 
problem with this."

> provide any details either. So where can I find more details?

Good point. We should elaborate this more clearly in the requirements.
There are currently two sections in draft-ietf-eman-requirements dealing
with this issue:
1.2.  Specific aspects of energy management
3.2.  Remote and Aggregated Monitoring
I will update them with more detailed example scenarios and figures.

>    group models actually retrieve measurement data from remote

I see two basic scenarios:
1. The reporting device is attached to the power supply lines of other 
devices
Examples (also mentioned in raft-ietf-eman-requirements) are dedicated 
power meters, power distribution units with built-in power meters, and
PoE switches.
Here devices report on what they measured at power lines attached to them.
If they are able to find out which devices are supplied by a power line, 
then they should report this as well.

2. The reporting device receives power/energy information on other 
devices by any means that are not based on SNMP or even not on IP.
It may even just be an estimate of power consumption of other devices.
An example would be a gateway to a building network, that receives
power information on many devices within the building and makes 
it available using eman MIB modules.

I think Cisco has another example with PCs reporting their power to 
switches and the switches report it to the management system, 
but this can certainly be explained better by the people from Cisco.

Thanks,

    Juergen Q.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Mar 2011 12:25:32 +0100

> Does anyone on this list know of any publicly available sources of information on the practical side of implementing these objects and how they are actually used in real systems?  Tutorials?  Books…

Perhaps it helps to take a quick look at an example (in this case data
taken from a Cisco Catalyst 4500 L3 switch). Here is a part of the
physical entity containment hierarchy:

$ scli -c "show entity containment" $DEVICE
    ENTITY CLASS       CONTAINMENT
         1 chassis       Cisco Systems, Inc. WS-C4506 6 slot switch 
         2 container     |- WS-C4506 6 slot switch chassis slot
      1000 module        |  `- Supervisor II+ with 2 1000BaseX GBIC ports
      1001 container     |     |- Port Container
      1003 port          |     |  `- 1000BaseSX
      1002 container     |     `- Port Container
      1004 port          |        `- 1000BaseSX
         3 container     |- WS-C4506 6 slot switch chassis slot
      2000 module        |  `- 10/100/1000BaseT (RJ45) with 48 10/100/1000 baseT ports
         4 container     |- WS-C4506 6 slot switch chassis slot
      3000 module        |  `- 10/100/1000BaseT (RJ45) with 48 10/100/1000 baseT ports
         5 container     |- WS-C4506 6 slot switch chassis slot
      4000 module        |  `- 10/100/1000BaseT (RJ45)V with 48 10/100/1000 baseT voice power ports (Cisco/IEE
         6 container     |- WS-C4506 6 slot switch chassis slot
         7 container     |- WS-C4506 6 slot switch chassis slot
         8 backplane     |-  WS-C4506 6 slot switch backplane
         9 sensor        |- Chassis Temperature Sensor
        10 container     |- Container of Fan Tray
        11 fan           |  `- FanTray
        12 container     `- Container of Container of Power Supply
        13 container        |- Container of Power Supply
        14 powerSupply      |  `- Power Supply ( AC 1300W )
        15 sensor           |     `- Power Supply Fan Sensor
        16 container        `- Container of Power Supply
        17 powerSupply         `- Power Supply ( AC 1300W )
        18 sensor                 `- Power Supply Fan Sensor

I have removed all the ports from the tree since it would get a bit
long. Anyway, this should give you an idea what you get already out of
today's ENTITY-MIB. Note the power supplies and the various sensors
already there. Here is more detailed information I can get from one
of the power supplies:

$ scli -c "show entity details" $DEVICE
[...]
Entity: 17                            Name:   Power Supply 2
Vendor: Cisco Systems, Inc.           HW Rev: V04                           
Model:  PWR-C45-1300ACV               FW Rev:                               
Serial: xxxxxxxxxxxx                  SW Rev:                               
Asset:                                Class:  powerSupply (replaceable)
Alias:  
Descr:  Power Supply ( AC 1300W )
[...]

These information fields are application to all physical entity types.
Now from an ENTITY-MIB point of view, it seems rather logical to have
lets say batteries represented as physical components and to have
augmentations that can provide more detailed information for
batteries. Similarily, reporting power states and power consumption of
modules or ports or power supplies seems a rather straight-forward
extension (in fact, a number of objects in the pmTable of the
ENERGY-AWARE-MIB would not be needed at all).

Back to our example device. Since our device provides briding
functionality per VLAN, it supports multiple "virtual" bridge
instances. To access them, we have to use different SNMP contexts (aka
logical entities in ENTITY-MIB speak). So lets look which contexts
exists:

$ ./scli -c "show snmp contexts" $SWITCH 

Description:          VLAN0000 
Community:            public@0
ContextEngineID:      800000090300020000000100 (Cisco Systems)
ContextName:          
Transport:	      xxx.xxx.xxx.xxx:161 (udp)

Description:          vlan1
Community:            public@1
ContextEngineID:      800000090300020000000100 (Cisco Systems)
Context:              
Transport:            xxx.xxx.xxx.xxx:161 (udp)

[...]

This data is retrieved from the logical entity table, which simply
provides a directory of all known SNMP contexts plus the information
needed to access them. If I use SNMPv1/SNMPv2c, I can access the SNMP
agent using the community string "public@1" to see the bridge instance
of vlan1. Note that the logical entity can even point to a different
transport endpoint, so I could even point to a separate SNMP agent.

I have no clue whether Net-SNMP supports meanwhile the ENTITY-MIB out
of the box. The biggest challenge I guess will not be the
implementation of the MIB objects themself but the digging of
information out of the various operating systems Net-SNMP is running
on. But it would actually be cool if Net-SNMP would provide a common
way to list the components of the systems via the ENTITY-MIB and if it
would be possible to access the various sensors most computers now
have embedded.

/js

PS: If I manage to tweak the scli code a bit during the weekend, I
    might also be able to show you sensor readings from the same Cisco
    box.

PS: We have recently implemented a tiny SNMP agent running under
    Contiki on AVR Raven boards (8-bit microcontroller) and to report
    the temperature sensor reading, we implemented just a few objects
    to represent this sensor using the ENTITY-SENSOR-MIB. In terms of
    implementation complexity, this all might be more a reading and
    learning hurdle for people not familiar with the ENTITY-MIB than a
    coding hurdle.

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 4 Mar 2011 09:35:58 -0600

> Juergen Quittek [[email-masked]] wrote:
>

I have a question related to "by any means that are not based on SNMP or even not on IP".  I understand that the intent here is to emphasize that such information may be gathered by any proprietary means available, which is fine.  Is the intent here also to explicitly EXCLUDE the use of SNMP and the EMAN MIBs as a means of gathering such "internal" information?

Personally I don't think that we should prohibit the use of SNMP and the EMAN MIBs in that context so I wish to understand your thinking in this case.

Now once we envision a multi-layered hierachy of SNMP and EMAN driven reporting we are starting to dive into the discussion of Parent/Child that is waiting to be discussed.  I am happy enough to save that discussion until later but a brief response here might help people to start getting their mental gears working in this space as well.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

> Sent: Friday, March 04, 2011 4:30 AM
> To: Juergen Schoenwaelder
> Cc: eman mailing list

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 4 Mar 2011 16:39:04 +0100

Hi Bill,

> I have a question related to "by any means that are not based on SNMP or even not on IP".  I understand that the intent here is to emphasize that such information may be gathered by any proprietary…

Sorry for not being clear in my message.
I definitely do not want to exclude gathering such information with SNMP.

    Juergen

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Fri, 4 Mar 2011 09:40:24 -0600

OK, that is what I would have expected/assumed but I wanted to make certain we were on the same page.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]<mailto:[email-masked]>
Phone: 614 367 5628
Fax: 614 367 5965

    - Albert Einstein

________________________________
From: Juergen Quittek [mailto:[email-masked]]
Sent: Friday, March 04, 2011 10:39 AM
To: Mielke, William F (Bill)
Cc: eman mailing list
Subject: Re: [eman] modeling power states

Hi Bill,

    Juergen

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]<mailto:[email-masked]>
Phone: 614 367 5628
Fax: 614 367 5965

   - Albert Einstein

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On

If we use the Entity MIB for reporting on power values for
remote PCs
aren't we over-stretching the Entity MIB a bit?

'Effectively, there is some "overall" physical entity
which houses
 the sum of the things managed by that one agent, i.e., there are
 multiple "logical" entities within a single physical entity.'

the original scope in mind and did not check if things would
still work

I started writing a summary on the applicability of the
Entity MIB to eman.
For this, I don't want to ignore such a sentence from RFC
4133 as the one
cited above. I rather want to be able to clearly state: "We
are extending
the Entity MIB beyond its original scope and there is no technical
problem with this."

I went to the requirements document and searched for remote
but could
not find a decent description what this remote monitoring
requirement
is. The framework document mentions remote somewhere but does not
provide any details either. So where can I find more details?

Good point. We should elaborate this more clearly in the requirements.
There are currently two sections in
draft-ietf-eman-requirements dealing
with this issue:
1.2.  Specific aspects of energy management
3.2.  Remote and Aggregated Monitoring
I will update them with more detailed example scenarios and figures.

/js

I see two basic scenarios:
1. The reporting device is attached to the power supply lines
of other
devices
Examples (also mentioned in raft-ietf-eman-requirements) are
dedicated
power meters, power distribution units with built-in power meters, and
PoE switches.
Here devices report on what they measured at power lines
attached to them.
If they are able to find out which devices are supplied by a
power line,
then they should report this as well.

Thanks,

   Juergen Q.

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Mar 2011 16:42:48 +0100

> Here devices report on what they measured at power lines attached to them.

But this is straight forward as far as the reporting of the power
going over the power lines go. A PoE switch should have no problem to
report the power going over the different ports by using physical
entities. I do not see anything report here.

> If they are able to find out which devices are supplied by a power
> line, then they should report this as well.

What are we talking about? A simple string? A few objects? A complete
MIB tree?

> but this can certainly be explained better by the people from Cisco.

One mechanism that can be used in such cases are contexts. Using
contexts allows to reuse existing MIB definitions as much as you want
since you have a separate OID namespace for the different devices. The
alternative is to create new object definitions (partially overlapping
existing ones) and to have everything indexed by some additional ID.
With contexts, I also gain some flexibility because I can either
provide a local context for stuff learned via some other mechanism or
I can provide a pointer to a remote context if I happen to know that
the other devices provides SNMP access.

The question likely boils down to how much information (standardized
and proprietary) "other means" provide about remote devices in the
foreseeable future.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Mar 2011 16:43:06 +0100

> 
> I think Cisco has another example with PCs reporting their 
> power to switches and the switches report it to the 
> management system, but this can certainly be explained better 
> by the people from Cisco.
> 

The standard version of this scheme is by implementing LLDP-MED
(ANSI/TIA 1057) which is an extension of IEEE 802.1AB and has also
defined a MIB to report on power and other characteristics of the remote
devices directly connected to an Ethernet switch. 

Dan

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 8 Mar 2011 00:52:00 -0600

Hello all, 

If I recall, we had this discussion on the applicability of Entity-MIB
at Anaheim - IETF77 meeting. 

Here is my understanding and summary. 

Clearly for power monitoring of network devices, it can be argued that
Entity MIB should be almost sufficient. 
In the requirements draft,
http://tools.ietf.org/html/draft-ietf-eman-requirements-00  there is a
requirement to collect power consumption as a system and also as a
breakdown of subcomponents. There are sub-components of network devices
that are not considered in Entity MIB RFC 4133 such as ASICs and Memory;
i.e. if there is interest to measure power consumption of those
components. 
It has been observed in benchmarking studies that TCAMs in network
devices are power hungry. 
http://www.hpl.hp.com/personal/Partha_Ranganathan/papers/2009/2009_netwo
rking_metrics.pdf

The intent of the entity MIB is for a different purpose and now its
current application is different. Given that physical devices can
consume power; we are trying to reuse the entity-MIB as much as
possible. Clearly, some of the physical components listed are quite
handy from a power monitoring point of view - Chassis, power Supply,
fan, module, port, cpu, stack etc. However, the value of assigning a
power value to Unknown or Other (as a component) is not clear.  

Beyond the Entity-MIB, LLDP-MED and RFC3621 provides power negotiation
of PoE devices - between a network device (switch) and an attached
device (phone). 
An attempt has been made to reuse the pmLldpPortNumber in those
scenario. 

There are also network power monitoring scenarios, when the device is
drawing power from a wall outlet or building HVAC devices and would not
have entPhysicalIndex or pmLldpPortNumber. In those situations, we had
proposed the use of pmIndex. 

There was also a point made in the last WG meeting, power consumption of
software components (not just physical components) should also be
considered. 
For e.g. an Email program on some platforms can consume power which can
be noticed by the rate of battery drain. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Romascanu, Dan (Dan)
Sent: Sunday, March 06, 2011 9:13 PM
To: Juergen Quittek; Juergen Schoenwaelder
Cc: eman mailing list
Subject: Re: [eman] modeling power states

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2011 14:52:30 +0100

> at Anaheim - IETF77 meeting. 

Let me start by explaining my involvement in this discussion: I am not
pushing for the ENTITY-MIB as _the_ solution for EMAN. All I am
looking for is that the design decision is taken well informed and
that the decision subsequently is well documented. What caused me to
speak up on this list was some confusion I think some people seemed to
have about some of the features of the ENTITY-MIB and the lack of any
text in the documents explaining how EMAN objects relates to the
ENTITY-MIB. Of course, now I am also playing a bit devil's advocate in
order to make sure any possible reasons to not extend the ENTITY-MIB
are becoming clear.

> power value to Unknown or Other (as a component) is not clear.  

I agree that the PhysicalClass TC should have been under IANA control
to enable extensibility. On the other hand, I have not seen anything
in the EMAN MIB proposals that is not also in the ENTITY-MIB. In fact,
most EMAN MIBs seem to use simple SnmpAdminStrings, which enables a
great deal of flexibility but also makes automation hard if every
vendor can label components in arbitrary ways. In other words, the
ENTITY-MIB even today is not "worse" than the other proposals (correct
me if I am missing something) and it could be fixed by moving the
PhysicalClass TC under IANA control.

> Beyond the Entity-MIB, LLDP-MED and RFC3621 provides power
> negotiation of PoE devices - between a network device (switch) and
> an attached device (phone).  An attempt has been made to reuse the
> pmLldpPortNumber in those scenario.

The entAliasMappingTable provides an extensible set of pointers to
other MIB table entries that may even exist in other logial entities
(contexts). I am not familiar with pmLldpPortNumber, so I am not sure
what exactly this is. But existing devices use this mechanism already
to relate "port" physical entities to network interfaces.

For me, it is most important that relationships between number spaces
are well documented so that it is clear how management applications
can relate the bits and pieces they get from various MIB modules. And
with every additional number space, the pain on the manager side
usually increases (and on the device itself unless the devices chooses
to not provide the relevant mapping information).

> proposed the use of pmIndex. 

Why do these devices not have entPhysicalIndex or why can't they have
an entPhysicalIndex? We do have wirelesse sensor nodes and they do
manage to report an entPhysicalIndex.

> There was also a point made in the last WG meeting, power
> consumption of software components (not just physical components)
> should also be considered.  For e.g. an Email program on some
> platforms can consume power which can be noticed by the rate of
> battery drain.

But you can't really measure this. People proposing something like
this likely measure the physical component's power consumption and
relate it to running software and its CPU usage via some magic
formula. It is not clear to me that this is necessarily expected to be
done and reported via an SNMP agent. If you export the power
consumption readings of your physical devices to a management system,
you can calculate whatever seems useful off the devices and in much
more flexible ways.

/js

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 9 Mar 2011 03:11:35 -0600

Hello Juergen S.

Thanks for your comments. Certainly your due diligence and questions are
appreciated. 
Replies in line.

Thanks
Mouli

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Tuesday, March 08, 2011 7:23 PM
To: Mouli Chandramouli (moulchan)
Cc: Romascanu, Dan (Dan); Juergen Quittek; eman mailing list
Subject: Re: eman] modeling power states - Entity-MIB

On Tue, Mar 08, 2011 at 12:52:00AM -0600, Mouli Chandramouli (moulchan)

YCM> Agreed. There are two questions. How long will it to update the
Physical Class TC ? 
YCM> There is a clear need for energy monitoring in networks now. 
YCM> So, this approach seemed as an interim solution.
YCM> Secondly, entity-MIB is widely implemented in networking devices. 
YCM> Other power consuming devices such as non-POE devices or building
HVAC devices 
YCM> have not implemented the Entity-MIB. 

YCM> Sane comment as before. Some of these devices may not implement the
Entity-MIB. 

YCM> agreed, good point. Even for some physical devices, there may not
be a power sensor
YCM> for measurement and may have to be estimated. In fact to handle
this scenario, in our proposal, a MIB variable 
YCM> Measurement Caliber to indicate how the measurement was obtained
(by direct measurement, estimation, or the max value, ...) 

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Mar 2011 12:20:31 +0100

> YCM> So, this approach seemed as an interim solution.

IETF processes never give you now. How long things take in the IETF
depends on convergence time, getting thing written down, reviewed,
processed etc.

> YCM> have not implemented the Entity-MIB. 

But those devices also have not implemented any yet to be standardized
EMAN MIB modules, so this is pretty much a mood point.

> YCM> Sane comment as before. Some of these devices may not implement the

Same answer as above. ;-)

> (by direct measurement, estimation, or the max value, ...) 

Sure, a value is not just a value. We know that at least since the
ENTITY-SENSOR-MIB. The question is more whether reporting power
consumptions of applications or even further the power consumption
produced by certain users of an organization is in scope or not.
There are lots of things people might calculate from the raw
measurements, this WG needs to decide what of at that is realistic to
report via an SNMP agent.

/js