Re: [eman] Entity identification method

[Christian Groves <[e-mail]>]

Hello Mouli,

Please see my comments below.

Regards, Christian

On 2/11/2010 5:37 PM, Mouli Chandramouli (moulchan) wrote:
> Hi Christian,
>
> Presently, the power measurement technology and instrumentation (power
> sensors) exist for physical entities.
> While the MIBs in circulation attempt to provide power consumption by
> physical components, cost of measurement sensors should be taken into
> account.
[CNG] I certainly agree cost of measurement is an issue. As the IETF are 
producing a new MIB future flexibility/extensibility (and backward 
compatibility) should also be considered. It may be possible to add 
support for logical/virtual entities in a way that does not burden 
vendors who don't want to implement this feature. Considering this issue 
may save costs in the future.
> Clearly, the power cost of software features or virtual machines
> (logical entities) should be determined, the technology/methodology is
> work in progress as given in the research paper.
>
> Power measurement of virtual machines is still at research stage.
>
> http://www.sigmetrics.org/sigmetrics2010/greenmetrics/greenMetrics10.Kri
> shnan.pdf
[CNG] Thanks for the link.
>
> On another point, it has been widely reported in several bench marking
> studies that most of the power consumption is due to physical entities.
> Clearly, this notion should be extended to logical entities as you have
> pointed out.
>
> Thanks
> Mouli
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Christian Groves
> Sent: Monday, November 01, 2010 8:44 AM
> To: [e-mail]
> Subject: Re: [eman] Entity identification method
>
> Hello Juergen,
>
> I think distinguishing the two cases is the correct way to go.
>
> I agree that reporting energy consumption for logical entities is a
> challenge and not straight forward. I guess there are a number of ways
> to look at this problem and how address the problem depends on the
> ambition level.
>
> As you rightly mention where there is partial use of a physical resource
>
> by a logical entity it is very difficult to have an exact figure.
> However I think the "grain size" of the measurement comes into play. For
>
> example if we have a large gateway implementing several virtual gateways
>
> if we take an overall measurement then we have the problem determining a
>
> figure. If the however the virtual gateways were each assigned a
> physical rack and the measurements were taken at a rack level then we
> have a more precise estimate of contribution of each virtual gateway to
> the overall picture.
>
> For me logical entities ultimately will be realised by physical
> hardware. The key is understanding the relationship between these
> entities. Thus I think virtualization can in some way be supported by
> allowing energy consumption reports for physical entities to indicate
> if/what logical entities they relate to. As they say information is
> power (pardon the pun :-) ).
>
> Regards, Christian
>
> On 29/10/2010 12:48 PM, Juergen Quittek wrote:
>> 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
>>
>> _______________________________________________
>> 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
>