Re: [eman] Entity identification method

[Christian Groves <[e-mail]>]

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