Re: [eman] Entity identification method (was: EMAN chartered itemsversus drafts)
"Chris Verges" <chrisv@cyberswitching.com> Thu, 28 October 2010 11:33 UTC
Return-Path: <chrisv@cyberswitching.com>
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 856F23A67F6 for <eman@core3.amsl.com>; Thu, 28 Oct 2010 04:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.681
X-Spam-Level:
X-Spam-Status: No, score=-5.681 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 THv-swqsDkL5 for <eman@core3.amsl.com>; Thu, 28 Oct 2010 04:33:41 -0700 (PDT)
Received: from p01c12o145.mxlogic.net (p01c12o145.mxlogic.net [208.65.145.68]) by core3.amsl.com (Postfix) with ESMTP id 39FA23A67EF for <eman@ietf.org>; Thu, 28 Oct 2010 04:33:39 -0700 (PDT)
Received: from unknown [64.81.28.110] (EHLO mail03.cyberswitching.local) by p01c12o145.mxlogic.net(mxl_mta-6.7.0-2) with ESMTP id 10069cc4.0.94354.00-388.217034.p01c12o145.mxlogic.net (envelope-from <chrisv@cyberswitching.com>); Thu, 28 Oct 2010 05:35:31 -0600 (MDT)
X-MXL-Hash: 4cc9600323e7ca9b-c701b3cadaed169fec1d57e73e9c426ab2473f0e
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Oct 2010 04:34:39 -0700
Message-ID: <68FBE0F3CE97264395875AC1C468F22C514657@mail03.cyberswitching.local>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Entity identification method (was: [eman] EMAN chartereditemsversus drafts)
Thread-Index: AQHLdQ3EaMG7aU2FN0SaNbGSJdLxoZNUMZ3wgAIDsVA=
From: Chris Verges <chrisv@cyberswitching.com>
To: Juergen Quittek <Quittek@neclab.eu>, Benoit Claise <bclaise@cisco.com>, eman mailing list <eman@ietf.org>
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010073001)]
X-MAIL-FROM: <chrisv@cyberswitching.com>
X-SOURCE-IP: [64.81.28.110]
X-AnalysisOut: [v=1.0 c=1 a=gPx1rXISJPUA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel]
X-AnalysisOut: [0A:10 a=4zsJQXJisSY22NXBO5KRuA==:17 a=48vgC7mUAAAA:8 a=AUd]
X-AnalysisOut: [_NHdVAAAA:8 a=yhEAkUgIS2BXHeENvPgA:9 a=_W6Xe9ZAQRsU1m3Ir7U]
X-AnalysisOut: [A:7 a=Yh-WNSJjDl3R0Oo4xeuMSCVaZlIA:4 a=CjuIK1q_8ugA:10 a=l]
X-AnalysisOut: [ZB815dzVvQA:10 a=JfD0Fch1gWkA:10 a=X7bfEhj96K-v7h_N:21 a=h]
X-AnalysisOut: [pFeuZnnd_Ml4Iok:21]
Subject: Re: [eman] Entity identification method (was: EMAN chartered itemsversus 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: Thu, 28 Oct 2010 11:33:46 -0000
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: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] 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: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] 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" <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-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 >>> eman@ietf.org >>> https://www.ietf.org/mailman/listinfo/eman > _______________________________________________ eman mailing list eman@ietf.org https://www.ietf.org/mailman/listinfo/eman
- Re: [eman] Entity identification method (was: EMA… Chris Verges
- Re: [eman] Entity identification method (was: EMA… Juergen Quittek
- Re: [eman] Entity identification method Christian Groves
- Re: [eman] Entity identification method Juergen Quittek
- Re: [eman] Entity identification method Christian Groves
- Re: [eman] Entity identification method Chris Verges
- Re: [eman] Entity identification method Mouli Chandramouli (moulchan)
- Re: [eman] Entity identification method Christian Groves
- Re: [eman] Entity identification method Christian Groves
- Re: [eman] Entity identification method Chris Verges
- Re: [eman] Entity identification method Benoit Claise
- Re: [eman] Entity identification method Chris Verges
- Re: [eman] Entity identification method john parello
- Re: [eman] Entity identification method Chris Verges