Re: [eman] Entity identification method

[Juergen Quittek <[e-mail]>]

Hi Christian,

Thank you for this interesting comment.

It looks like we have to distinguish two cases: power state monitoring and
energy consumption monitoring.

For a logical entity and a virtual machine it may be well possible to report
on their power state. However, reporting their energy consumption seems to
be a tough challenge at least if be base it on real measurements.

It is well feasible to measure energy consumption of physical entities, but
if you have a logical entity that consumes only partial resources of a
physical entity, then precise measurement of the energy consumption will be
hardly possible. Estimations may be possible based on a model of the logical
entity, but I don't know how good such models can be.

Thanks,

    Juergen 


On 29.10.10 03:25  "Christian Groves" <[e-mail]> wrote:

> Hello
> 
> I've just started to digest the various drafts of the eman wg and I see
> the comment below on logical entities. It's not clear to me how/if
> network virtualization is intended on being handled in the eman work.
> 
> In networks there's now a trend towards network virtualization and cloud
> computing with the different "X" as a service models (i.e. Amazon EC2
> "platform as a service" running different server instances). Even in
> today's networks we have physical gateways that are virtualized into
> different logical gateways. For example: H.248/Megaco virtual MG (VMG)
> concept.
> 
> I think it would be advantageous to be able to assess the energy
> consumption of the VMGs or instances (which are logical entities)
> independent of the physical gateway so that a customers energy use may
> be recording. Will this sort of functionality be allowed?
> 
> Regards, Christian
> 
> On 29/10/2010 1:22 AM, Juergen Quittek wrote:
>> Hi Chris,
>> 
>> I think it may become very difficult if we want to assess energy consumption
>> of logical entities. It seems to be reasonable and practical to limit energy
>> consumption measurements to physical entities. The ENERGY AWARE MIB module
>> (draft-parello-eman-energy-aware-mib) and the POWER MIB
>> (draft-quittek-power-mib-02) went this way.
>> 
>> Just using entPhysicalIndex solves some of the problem you mentioned.
>> Particularly, you don't need a mapping table to entities if you restrict
>> Yourself to entPhysicalIndex.
>> 
>> Thanks,
>> 
>>      Juergen
>> 
>> On 28.10.10 13:34  "Chris Verges"<[e-mail]>  wrote:
>> 
>>> Hi Jurgen and all,
>>> 
>>> The more I've been thinking about these scenarios, the more something
>>> doesn't seem quite right.  I'll try to explain my thought process behind
>>> this and see if my concerns/confusions get captured.
>>> 
>>> ENTITY-MIB provides enumerated lists of physical and logical entities on
>>> the system.  The indices in both lists are maintained separately, so
>>> there is not a single, unique identifier provided.  Because of this, the
>>> MIBs being discussed by the EMAN WG must only reference to one type
>>> (physical or logical) and are limited to that without additional work.
>>> At some point in my mind, I'm asking myself the question, "What's the
>>> point of linking to ENTITY-MIB?"
>>> 
>>> More on that question in later scenarios below ...
>>> 
>>> One possibility would be to create a separate mapping table that gives a
>>> guaranteed unique index based on all entities, regardless of type.  The
>>> physical vs. logical extensions would then become sparse tables that
>>> augment this.  For example:
>>> 
>>>    ENTITY-MIB : entityGeneral.entGeneralTable.entGeneralEntry
>>>    +-----------------+-----------------+-----+
>>>    | entGeneralIndex | entGeneralDescr | ... |
>>>    +-----------------+-----------------+-----+
>>>    |        1        | PDU Chassis     |     |
>>>    +-----------------+-----------------+-----+
>>>    |        2        | Meter #1        |     |
>>>    +-----------------+-----------------+-----+
>>>    |        3        | Meter #2        |     |
>>>    +-----------------+-----------------+-----+
>>>    |        4        | Remote Meter #1 |     |
>>>    +-----------------+-----------------+-----+
>>> 
>>>    ENTITY-MIB : entityPhysical.entPhysicalTable.entPhysicalEntry
>>>    +-----------------+-----------------+-----+
>>>    | entGeneralIndex | entVendorType   | ... |
>>>    +-----------------+-----------------+-----+
>>>    |        1        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>>    |        2        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>>    |        3        | enterprises.foo |     |
>>>    +-----------------+-----------------+-----+
>>> 
>>>    ENTITY-MIB : entityLogical.entLogicalTable.entLogicalEntry
>>>    +-----------------+----------------------+-----+
>>>    | entGeneralIndex | entLogicalCommunity  | ... |
>>>    +-----------------+----------------------+-----+
>>>    |        4        | remote-power-group-1 |     |
>>>    +-----------------+----------------------+-----+
>>> 
>>> It seems like this 'entGeneralIndex' concept is what's missing from the
>>> current ENTITY-MIB, and is causing problems when thinking about local
>>> and remote power data being reported by the same agent.
>>> 
>>> Another possibility would be to choose one -- entLogicalIndex, most
>>> likely -- and require that anyone who wants to implement the EMAN WG
>>> MIBs to always create an entLogicalEntry for the power data.  In this
>>> context, the entLogicalTable fills the role of entGeneralTable as
>>> described above.  For all entPhysicalTable entries, there would need to
>>> be a corresponding entry in entLogicalTable with a 1:1 mapping between
>>> them.  For all remote entries, there would be a unique entry in
>>> entLogicalTable.  Of course, this would add some additional overhead on
>>> the part of the implementer, but isn't too overburdening.
>>> 
>>> A third possibility is that ENTITY-MIB just doesn't do what we need in
>>> its present form and we need to think about enumerating power sensors
>>> separately from other components/sensors on the system.  It seems like
>>> entPhysicalTable gives a good starting template for a new
>>> 'POWER-ENTITY-MIB', but can be extended to include support for remote
>>> agents.  The difference would be a clean break from the legacy
>>> ENTITY-MIB structure.
>>> 
>>> And with that, I look forward to others' feedback and ideas on solving
>>> this problem!
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Chris Verges
>>> Sent: Tuesday, October 26, 2010 9:26 PM
>>> To: Juergen Quittek; Benoit Claise; eman mailing list
>>> Subject: Re: [eman] Entity identification method (was: EMAN chartered
>>> itemsversus drafts)
>>> 
>>> Hi Juergen and all,
>>> 
>>> Agreed that a common ID method makes sense, and ENTITY-MIB seems to be a
>>> good choice.  In case (c) from your list, wouldn't the remote agent
>>> condition be handled by ENTITY-MIB supporting a logical entity that is
>>> the remote agent iself?  Since the logical entity is in the ENTITY-MIB
>>> table, it would be given a unique ID mixed amongst the other logical and
>>> physical entities.
>>> 
>>> At that point, should all of the MIBs being discussed in the EMAN WG be
>>> sparse table augmentations of ENTITY-MIB?
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>> Juergen Quittek
>>> Sent: Tuesday, October 26, 2010 6:01 AM
>>> To: Benoit Claise; eman mailing list
>>> Subject: [eman] Entity identification method (was: EMAN chartered items
>>> versus drafts)
>>> 
>>> Hi Benoit and all,
>>> 
>>> I agree that we should find a common identification method for entities
>>> used by all MIB modules. This does not apply to the POWER MIB only, but
>>> to all MIB modules in the eman WG.
>>> The modules will use an entity ID as index for their tables.
>>> Which entity is identified by the index can be resolved by other MIB
>>> modules, such as the POWER AWARE MIB module
>>> (draft-parello-eman-energy-aware-mib) or the ENTITY MIB module (RFC
>>> 4133).
>>> 
>>> I see three basic scenarios for the entity identification:
>>> 
>>>    a) a device just reports on its own power state and energy
>>>       consumption and it reports on its own as a single unit.
>>> 
>>>       Then we have a single index only stating "it's me".
>>>       Such a device usually does not need further identification
>>>       of itself, because typically there are sufficient other
>>>       MIB modules for this purpose running in the same SNMP engine,
>>>       that provide information about the device's IP address,
>>>       manufacturer, operating system, etc. In such a case a
>>>       'trivial' index, such as '0' should be used in order to
>>>       keep it simple in this most simple case.
>>> 
>>>    b) a device reports on its own but not just as a single unit
>>>       but it reports power states and energy consumption for its
>>>       individual components, for example it may report separately
>>>       on contained hard drives, line cards, back planes,
>>>       processor boards, etc.
>>> 
>>>       In such a case, identification of these components as
>>>       individual entities would be required. The ENTITY MIB
>>>       module was designed for this purpose and would be a good
>>>       choice here. Also the POWER AWARE MIB module would be
>>>       useful in this case.
>>> 
>>>    c) a device reports on energy consumption of other, remote
>>>       devices. Then remote devices (and potentially also their
>>>       contained components need to be identified. For
>>>       identifying remote components there is the POWER AWARE MIB
>>>       module that has been designed for this purpose. As far as
>>>       I understand, the ENTITY MIB module is not applicable to
>>>       remote devices.
>>> 
>>> In summary,
>>>    - if you need to report on remote entities (case c)),
>>>      you need the POWER AWARE MIB module,
>>>    - if you report only on entities locally contained
>>>      in the reporting device (case b)), you can use
>>>      the POWER AWARE MIB or the ENTITY MIB
>>>    - if you report just on your own as a single device
>>>      (case a)), identification is trivial
>>> 
>>> Hence, my recommendation (stated for POWER-STATE MIB and ENERGY MIB in
>>> draft-quittek-power-mib-02) would be:
>>> 
>>> If there is an implementation of the POWER AWARE MIB module instantiated
>>> in the local SNMP engine, then you SHOULD (or MUST?) use it for indexing
>>> (pmIndex).
>>> If this is not the case but there is an ENTITY MIB instance available,
>>> then you SHOULD use this one (entPhysicalIndex).
>>> If neither of this MIB modules is available you should use index 0 only
>>> and be limited to report on the local device as a single entity only.
>>> 
>>> That's just my view. Certainly, there are more ways of entity
>>> identification. I look forward to discussing them.
>>> 
>>> Thanks,
>>> 
>>>      Juergen
>>> 
>>> 
>>> On 26.10.10 11:44  "Benoit Claise"<[e-mail]>  wrote:
>>> 
>>>> Hi Juergen,
>>>> 
>>>> Thanks for the clarification.
>>>> 
>>>> Something key is to agree on the Power Monitor index for all MIB
>>>> modules, which IMHO should be part of the Energy-aware Networks and
>>>> Devices MIB module, but reuse in the other MIB modules.
>>>> 
>>>> Regards, Benoit.
>>>>> Hi Benoit,
>>>>> 
>>>>> Thanks for checking all drafts.
>>>>> 
>>>>> I don't think that draft-quittek-power-mib-02 makes significant
>>>>> contributions to the Energy-aware Networks and Devices MIB.
>>>>> It just covers the Power and Energy Monitoring MIB and the Battery
>>> MIB.
>>>>> Thanks,
>>>>>       Juergen
>>>>> 
>>>>> 
>>>>> On 26.10.10 08:22  "Benoit Claise"<[e-mail]>   wrote:
>>>>> 
>>>>>> Dear all,
>>>>>> 
>>>>>> I went through the exercise of mapping the existing six chartered
>>>>>> items with the existing draft content.
>>>>>> 
>>>>>> _Energy Management Requirements_
>>>>>> http://tools.ietf.org/html/draft-quittek-power-monitoring-requiremen
>>>>>> ts-02 https://datatracker.ietf.org/doc/draft-norwin-energy-consider/
>>>>>> _
>>>>>> Energy Management Framework_
>>>>>> http://tools.ietf.org/html/draft-claise-power-management-arch-02
>>>>>> 
>>>>>> _Energy-aware Networks and Devices MIB_
>>>>>> http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Power and Energy Monitoring MIB_
>>>>>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-06
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Battery MIB_
>>>>>> http://tools.ietf.org/html/draft-quittek-power-mib-02
>>>>>> 
>>>>>> _Energy Management Applicability_
>>>>>> http://datatracker.ietf.org/doc/draft-tychon-eman-applicability-stat
>>>>>> ement/
>>>>>> 
>>>>>> Please let me know if I made any mistakes or if I missed any draft?
>>>>>> 
>>>>>> Regards, Benoit.
>>>>>> _______________________________________________
>>>>>> eman mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/eman
>>> _______________________________________________
>>> eman mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/eman
>> 
>> 
>> _______________________________________________
>> eman mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/eman
> _______________________________________________
> eman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman

-- 
Juergen Quittek            [e-mail]      Tel: [phone]
General Manager            http://www.neclab.eu   Fax: [phone]
NEC Europe Ltd., Network Laboratories Europe
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany
Registered Office: NEC House, 1 Victoria Road, London W3 6BL, UK
Registered in England 2832014