[eman] Entity identification method (was: EMAN chartered items versus drafts)

Juergen Quittek <Quittek@neclab.eu> Tue, 26 October 2010 12:58 UTC

Return-Path: <Quittek@neclab.eu>
X-Original-To: eman@core3.amsl.com
Delivered-To: eman@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6433A695A for <eman@core3.amsl.com>; Tue, 26 Oct 2010 05:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.127
X-Spam-Level:
X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIqfA2Fkti82 for <eman@core3.amsl.com>; Tue, 26 Oct 2010 05:58:55 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 99C433A67FB for <eman@ietf.org>; Tue, 26 Oct 2010 05:58:54 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 985392C0001B2; Tue, 26 Oct 2010 15:00:41 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd)
Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFZTIKGedsmL; Tue, 26 Oct 2010 15:00:41 +0200 (CEST)
Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by smtp0.neclab.eu (Postfix) with ESMTP id 72FB42C0001AD; Tue, 26 Oct 2010 15:00:31 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.19]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0255.000; Tue, 26 Oct 2010 15:00:31 +0200
From: Juergen Quittek <Quittek@neclab.eu>
To: Benoit Claise <bclaise@cisco.com>, eman mailing list <eman@ietf.org>
Thread-Topic: Entity identification method (was: [eman] EMAN chartered items versus drafts)
Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoQ==
Date: Tue, 26 Oct 2010 13:00:30 +0000
Message-ID: <C8EC9D8C.161AA%quittek@neclab.eu>
In-Reply-To: <4CC6A302.3060106@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-Entourage/13.6.0.100712
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3370950028_13961643"
MIME-Version: 1.0
Subject: [eman] Entity identification method (was: EMAN chartered items versus drafts)
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussions about the creation of an Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2010 12:58:56 -0000

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" <bclaise@cisco.com> 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"<bclaise@cisco.com>  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-requirements-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-statement/
>>> 
>>> Please let me know if I made any mistakes or if I missed any draft?
>>> 
>>> Regards, Benoit.
>>> _______________________________________________
>>> eman mailing list
>>> eman@ietf.org
>>> https://www.ietf.org/mailman/listinfo/eman
>