Re: [eman] Entity identification method

Juergen Quittek <Quittek@neclab.eu> Thu, 28 October 2010 15:24 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 2AECE3A6855 for <eman@core3.amsl.com>; Thu, 28 Oct 2010 08:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.009
X-Spam-Level:
X-Spam-Status: No, score=-101.009 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, MANGLED_MEDS=2.3, 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 33RuvBP1slyE for <eman@core3.amsl.com>; Thu, 28 Oct 2010 08:24:07 -0700 (PDT)
Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 74D8E3A677C for <eman@ietf.org>; Thu, 28 Oct 2010 08:24:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 680742C0001B0; Thu, 28 Oct 2010 17:25:59 +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 J8wszAofqKD8; Thu, 28 Oct 2010 17:25:59 +0200 (CEST)
Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 3504D2C0001B2; Thu, 28 Oct 2010 17:25:49 +0200 (CEST)
Received: from DAPHNIS.office.hd ([169.254.2.19]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Thu, 28 Oct 2010 17:25:49 +0200
From: Juergen Quittek <Quittek@neclab.eu>
To: Benoit Claise <bclaise@cisco.com>
Thread-Topic: Entity identification method
Thread-Index: AQHLdqkPzhRnSz7auE2VMOFT88Los5NWe3WA
Date: Thu, 28 Oct 2010 15:25:48 +0000
Message-ID: <C8EF6299.1635A%quittek@neclab.eu>
In-Reply-To: <4CC982EC.80803@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.7.0.100913
x-originating-ip: [10.1.2.39]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3371131545_20451962"
MIME-Version: 1.0
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] Entity identification method
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: Thu, 28 Oct 2010 15:24:10 -0000

Hi Benoit,

That's why I recommend that whenever you have an implementation of the
ENERGY AWARE MIB available in your local SNMP engine you should use the
ENERGY AWARE MIB for indexing. It serves all purposes and it can use the
ENTITY MIB if this is also available.

Thanks,

    Juergen

On 28.10.10 16:04  "Benoit Claise" <bclaise@cisco.com> wrote:

> Hi Juergen,
> 
> draft-parello-eman-energy-aware-mib has its own pmIndex index, but also
> pmPhysicalEntity (as a non index MIB object) if the ENTITY-MIB is supported.
> Isn't it the best of both worlds?
> If the ENTITY-MIB is not supported, the pmIndex does its job.
> If you need to report on the remote entities, the pmIndex does its job.
> If the ENTITY-NIB is supported, then the pmPhysicalEntity contains the
> pointer to the ENTITY-MIB
> 
> Btw, the same principle has been applied for the Power Ethernet MIB
> [RFC3621] with pmEthPortIndex and pmEthPortGrpIndex
> PethPsePortGroupIndexOrZero.
> And again with the [LLDP-MIB
> <http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00#ref-LLDP-MI
> B>] 
> and [LLDP-MED-MIB
> <http://tools.ietf.org/html/draft-parello-eman-energy-aware-mib-00#ref-LLDP-ME
> D-MIB>] 
> with pmLldpPortNumber
> 
> See inline.
>> 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.
> Another problem that is linked: index persistence.
> If the persistence is required (to be discussed), and if you use the
> entPhysicalIndex as an index in these MIB module, basically you're
> asking for the ENTITY-MIB persistence.
> IMHO, another reason to have this level of indirection via the pmIndex
> -> pmPhysicalEntity
> 
> Regards, Benoit (as a contributor)
>> 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
> 

-- 
Juergen Quittek            quittek@neclab.eu      Tel: +49 6221 4342-115
General Manager            http://www.neclab.eu   Fax: +49 6221 4342-155
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