Subject: [eman] Use of ENTITY-MIB in EMAN (version 01)

From: [email-masked]
Date: Tue, 8 Mar 2011 07:54:05 -0800

Hi all,

I've integrated the current feedback for the
eman-relationship-to-entity-mib-00.txt revision into
eman-relationship-to-entity-mib-01.txt.  Many thanks to Juergen S. for
helping flush things out to this point.

The conclusion that I'm coming away with at this point is that
ENTITY-MIB was designed to model physical entities, where an "entity" is
some construct that is intended for management purposes.  Logical
entities are not handled by entLogicalTable, which instead manages
logical contexts (slight difference in that a context is not intended to
be directly managed.)  So for EMAN's purposes, a mechanism to manage
both physical and logical entities is needed.  This may be an extension
of ENTITY-MIB (are other WG's needing something like this?) or may be a
separate structure wholy contained in the EMAN MIB schema.

Looking forward to your thoughts and feedback!

Thanks,
Chris

--------- eman-relationship-to-entity-mib-01.txt ---------

On the EMAN working group mailing list recently, there has a been a huge surge
of activity surrounding the use of ENTITY-MIB (RFC4133) to define the list of
core entities.  I thought a detailed look at ENTITY-MIB's structures and
philosophical underpinnings would be in order to see if it will work for
EMAN's needs.

>From RFC4133, ENTITY-MIB's description of itself and its purpose:

   "There is a need for a standardized way of representing a single agent,
   which supports multiple intstances of one MIB.  This is presently true for
   at least 3 standard MIBs, and is likely to become true for more and more
   MIBs as time passes...."

   "What is needed is a way to determine exactly which logical entities are
   managed by the agent (with some version of SNMP) in order to communicate
   with the agent about a particular logical entity.  When different logical
   entities are associated with different physical entities within the overall
   physical entity, it is also useful to be able to use this information to
   distinguish between logical entities."

Also from RFC4311, some nomenclature:

   "Logical Entity: a managed system contains one or more logical entities,
   each represented by at most one instantiation of each of a particular set
   of MIB objects.  A set of management functions is associated with each
   logical entity.  Examples of logical entities include routers, bridges,
   print-servers, etc."

   "Physical Entity: a 'physical entity' or 'physical component' represents an
   identifiable physical resource within a managed system.  Zero or more
   logical entities may utilize a physical resource at any given time.
   Determining which physical components are represented by an agent in the
   EntPhysicalTable is an implementation-specific matter.  Typically, physical
   resources (e.g., communications ports, backplanes, sensors, daughter-cards,
   power supplies, the overall chassis), which can be managed via functions
   associated with one or more logical entities, are included in the MIB."

There exist two key tables in ENTITY-MIB: entPhysicalTable, which identifies
physical system components; and entLogicalTable, which identifies logical
entities.  Each contain one row per entity, where each row is indexed by an
arbitrary integer.

The target system that I am attempting to model is an ePower series
intelligent PDU (iPDU) from Cyber Switching.  One representation of this
device's physical construction might be:

   ePower PDU
   |-- Network Interface Card
   |   |-- LCD screen
   |   |-- Processor
   |   `-- Real-time clock battery/super-cap
   |-- Input #1                                 (3 Phase AC cord)
   |   |-- Bank #1                              (1Ph branch circuit - L1/L2)
   |   |   |-- Outlet #1
   |   |   |-- Outlet #2
   |   |   |-- Outlet #3
   |   |   `-- Outlet #4
   |   |-- Bank #2                              (1Ph branch circuit - L2/L3)
   |   |   |-- Outlet #5
   |   |   |-- Outlet #6
   |   |   |-- Outlet #7
   |   |   `-- Outlet #8
   |   `-- Bank #3                              (1Ph branch circuit - L3/L1)
   |       |-- Outlet #9
   |       |-- Outlet #10
   |       |-- Outlet #11
   |       `-- Outlet #12
   `-- Input #2                                 (3 Phase AC cord)
       |-- Bank #4                              (1Ph branch circuit - L1/L2)
       |   |-- Outlet #13
       |   |-- Outlet #14
       |   |-- Outlet #15
       |   `-- Outlet #16
       |-- Bank #5                              (1Ph branch circuit - L2/L3)
       |   |-- Outlet #17
       |   |-- Outlet #18
       |   |-- Outlet #19
       |   `-- Outlet #20
       `-- Bank #6                              (1Ph branch circuit - L3/L1)
           |-- Outlet #21
           |-- Outlet #22
           |-- Outlet #23
           `-- Outlet #24

Note that for each 3 Phase AC cord, between three and four separate
sub-entities can exist:

   3 Phase AC cord
   |-- Line L1 / X / A
   |-- Line L2 / Y / B
   |-- Line L3 / Z / C
   `-- Line Neutral / N

In addition to this physical component breakdown, logical groupings of
physical entities may be created.  For example, outlet entities may be
logically associated with one another into an "outlet gang."  An outlet may
belong to more than one "outlet gang."  One representation of this may be:

   ePower PDU
   |-- Outlet Gang #1
   |   |-- Outlet #5
   |   |-- Outlet #6
   |   `-- Outlet #7
   `-- Outlet Gang #2
       |-- Outlet #6
       `-- Outlet #13

As this applies to the EMAN goals, our objective is to instantiate the objects
necessary to represent all of these various entities in such a way that power
data and operational state control can be linked to them.  I will investigate
several possible scenarios of using ENTITY-MIB's existing structures to
achieve this instantiation.

In this exercise, we will start by placing all physical entities in
entPhysicalTable.  The table below shows key columns from that table along
with sample values.

   entPhysicalTable
   +-----+---------------+-------------------+-------------+--------------+
   | Idx | Name          | Alias             | ContainedIn | ParentRelPos |
   +-----+---------------+-------------------+-------------+--------------+
   | 1   | ePower PDU    | epower-pdu        | 0           | 0            |
   | 2   | NIC           | Control Logic     | 1           | 1            |
   | 3   | LCD           | Touchscreen Disp. | 2           | 0            |
   | 4   | Processor     | CPU               | 2           | 0            |
   | 5   | RTC Battery   | Clock battery     | 2           | 0            |
   | 6   | Input #1      | XFMR #1 feed      | 1           | 2            |
   | 7   | Input #1 - L1 | Line L1 / X / A   | 6           | 0            |
   | 8   | Input #1 - L2 | Line L2 / Y / B   | 6           | 0            |
   | 9   | Input #1 - L3 | Line L3 / Z / C   | 6           | 0            |
   | 10  | Input #1 - N  | Line Neutral / N  | 6           | 0            |
   | 11  | Bank #1       | Branch Cir. L1/L2 | 6           | 1            |
   | 12  | Outlet #1     | filer01-sjc-pwr1  | 11          | 1            |
   | 13  | Outlet #2     | filer17-sjc       | 11          | 2            |
   | 14  | Outlet #3     | filer23-sjc       | 11          | 3            |
   | 15  | Outlet #4     | san-array05-sjc   | 11          | 4            |
   | 16  | Bank #2       | Branch Cir. L2/L3 | 6           | 2            |
   | 17  | Outlet #5     | rtr-u3-fre        | 16          | 1            |
   | 18  | Outlet #6     | wap-flr01         | 16          | 2            |
   | 19  | Outlet #7     | wap-flr02         | 16          | 3            |
   | 20  | Outlet #8     | wap-flr03         | 16          | 4            |
   | 21  | Bank #3       | Branch Cir. L3/L1 | 6           | 3            |
   | 22  | Outlet #9     | rtr-m6-he         | 21          | 1            |
   | 23  | Outlet #10    | rtr-m6-att        | 21          | 2            |
   | 24  | Outlet #11    | switch-p989       | 21          | 3            |
   | 25  | Outlet #12    | switch-t332       | 21          | 4            |
   | 26  | Input #2      | XFMR #1 feed      | 1           | 3            |
   | 27  | Input #2 - L1 | Line L1 / X / A   | 26          | 0            |
   | 28  | Input #2 - L2 | Line L2 / Y / B   | 26          | 0            |
   | 29  | Input #2 - L3 | Line L3 / Z / C   | 26          | 0            |
   | 30  | Input #2 - N  | Line Neutral / N  | 26          | 0            |
   | 31  | Bank #4       | Branch Cir. L1/L2 | 26          | 1            |
   | 32  | Outlet #13    | filer01-sjc-pwr2  | 31          | 1            |
   | 33  | Outlet #14    | ...               | 31          | 2            |
   | 34  | Outlet #15    | ...               | 31          | 3            |
   | 35  | Outlet #16    | ...               | 31          | 4            |
   | 36  | Bank #5       | Branch Cir. L2/L3 | 26          | 2            |
   | 37  | Outlet #17    | ...               | 36          | 1            |
   | 38  | Outlet #18    | ...               | 36          | 2            |
   | 39  | Outlet #19    | ...               | 36          | 3            |
   | 40  | Outlet #20    | ...               | 36          | 4            |
   | 41  | Bank #6       | Branch Cir. L3/L1 | 26          | 3            |
   | 42  | Outlet #21    | ...               | 41          | 1            |
   | 43  | Outlet #22    | ...               | 41          | 2            |
   | 44  | Outlet #23    | ...               | 41          | 3            |
   | 44  | Outlet #24    | ...               | 41          | 4            |
   +-----+---------------+-------------------+-------------+--------------+

In the spirit of ENTITY-MIB, the "outlet gang" entities do not belong in
entPhysicalTable, as they are virtual representations of a collection of
outlets.  Therefore, we will place them in entLogicalTable.

   entLogicalTable
   +-----+----------------+
   | Idx | Descr          |
   +-----+----------------+
   | 1   | Outlet Gang #1 |
   | 2   | Outlet Gang #2 |
   +-----+----------------+

The logical entities can be mapped onto the physical entities by using
entLPMappingTable.

   entLPMappingTable
   +------------+-------------+
   | LogicalIdx | PhysicalIdx |
   +------------+-------------+
   | 1          | 17          |          Outlet Gang #1 -> Outlet #5
   | 1          | 18          |                         -> Outlet #6
   | 1          | 19          |                         -> Outlet #7
   | 2          | 16          |          Outlet Gang #2 -> Outlet #6
   | 2          | 32          |                         -> Outlet #13
   +------------+-------------+

The entire model is now implemented using ENTITY-MIB.  However, there are some
ramifications to this:

   1. There is no single "index" that can be referenced for sparse tables in
      an EMAN MIB.  The use of both entPhysicalTable and entLogicalTable means
      that separate indicies must be used, which results in separate EMAN
      tables for power data, control, etc. (one for physical entities, one for logical
      entities).

   2. The structure of entPhysicalTable allows an entity to maintain a
      constant name (e.g., "Outlet #1") while changing an alias (e.g.,
      "filer01-sjc-pwr1").  The structure of entLogicalTable does not allow
      the same behavior, so logical entities are naturally less feature
      capable.

   3. None of the objects in ENTITY-MIB allow for 'read-create', so creating
      new "outlet gangs" would have to be supported by a third-party
      mechanism.  While not critical to EMAN's needs, it is a major
      inconvenience for the various manufacturers who would benefit from such
      standard operation.

One proposed solution on the mailing list for #1 is to duplicate all entries
from entPhysicalTable in entLogicalTable.  The resulting structure would allow
a single index to be used (entLogicalIndex), but would not address item #2.

One possible solution for #2 would be to list the virtual "outlet gangs" in
entPhysicalTable as well as in entLogicalTable, but this violates the spirit
behind entPhysicalTable as described in RFC4133.

So both compromise solutions would need to be made in order to handle
"virtual" entities like "outlet gangs" using ENTITY-MIB.

However, even if both solutions are used, establishing a relationship graph
between an "outlet gang" and its parent PDU and between an "outlet gang" and
its associated physical outlets is not handled in a simple manner.  The
entPhysicalContainedIn object can be used to relate physical outlets to their
corresponding banks and the "outlet gangs" with the physical PDU.  The
entLPMappingTable can establish a mapping between the "outlet gang" and the
physical outlets.  However, as you can see, determining the parent/child
relationship between entities is a complex process involving both
entPhysicalContainedIn and entLPMappingTable.

UPDATE 2011-03-08: Juergen Schoenwaelder pointed out in the EMAN WG mailing
list (http://www.ietf.org/mail-archive/web/eman/current/msg00265.html) that
this use of entLogicalTable is incorrect.  The use proposed here assumes that
entLogicalTable and entLPMappingTable establish a set of logical entities that
can be managed, but Juergen points out that entLogicalTable instead creates a
set of SNMP contexts only -- entities that are not intended for management
purposes but are instead only used for grouping purposes.

Another goal for EMAN is to report data on behalf of remote entities.  In such
a scenario, the agent must reference multiple physical entities that are
external to the agent's system.

   Ethernet Switch
   |-- Port 1
   |-- Port 2 --------------------> VoIP Phone
   |-- Port 3 --------------------> ePower PDU
   `-- Port 4 --------------------> Windows PC

In this scenario, the VoIP phone, ePower PDU, and Windows PC report their
power data to the Ethernet Switch, which acts as a collection proxy for the
data.

The structure underneath "ePower PDU" follows that described above.

Modeling the switch itself is straight-forward.  Following the logic used to
describe an ePower PDU above, we can model all of the entities known/managed
by the switch.

   entPhysicalTable
   +-----+---------------+-------------------+-------------+--------------+
   | Idx | Name          | Alias             | ContainedIn | ParentRelPos |
   +-----+---------------+-------------------+-------------+--------------+
   | 1   | Eth. Switch   | switch-4-sjc      | 0           | 0            |
   | 2   | Port 1        | Switchport 1      | 1           | 1            |
   | 3   | Port 2        | Switchport 2      | 1           | 2            |
   | 4   | Port 3        | Switchport 3      | 1           | 3            |
   | 5   | Port 4        | Switchport 4      | 1           | 4            |
   | 6   | ePower PDU    | epower-pdu        | 4           | 0            |
   | 7   | NIC           | Control Logic     | 6           | 1            |
   | 8   | LCD           | Touchscreen Disp. | 7           | 0            |
   | 9   | Processor     | CPU               | 7           | 0            |
   | 10  | RTC Battery   | Clock battery     | 7           | 0            |
   | 11  | Input #1      | XFMR #1 feed      | 6           | 2            |
   | 12  | Input #1 - L1 | Line L1 / X / A   | 11          | 0            |
   | 13  | Input #1 - L2 | Line L2 / Y / B   | 11          | 0            |
   | 14  | Input #1 - L3 | Line L3 / Z / C   | 11          | 0            |
   | 15  | Input #1 - N  | Line Neutral / N  | 11          | 0            |
   | 16  | Bank #1       | Branch Cir. L1/L2 | 11          | 1            |
   | 17  | Outlet #1     | filer01-sjc-pwr1  | 16          | 1            |
   | 18  | Outlet #2     | filer17-sjc       | 16          | 2            |
   | 19  | Outlet #3     | filer23-sjc       | 16          | 3            |
   | 20  | Outlet #4     | san-array05-sjc   | 16          | 4            |
   | 21  | Bank #2       | Branch Cir. L2/L3 | 11          | 2            |
   | 22  | Outlet #5     | rtr-u3-fre        | 21          | 1            |
   | 23  | Outlet #6     | wap-flr01         | 21          | 2            |
   | 24  | Outlet #7     | wap-flr02         | 21          | 3            |
   | 25  | Outlet #8     | wap-flr03         | 21          | 4            |
   | 26  | Bank #3       | Branch Cir. L3/L1 | 11          | 3            |
   | 27  | Outlet #9     | rtr-m6-he         | 26          | 1            |
   | 28  | Outlet #10    | rtr-m6-att        | 26          | 2            |
   | 29  | Outlet #11    | switch-p989       | 26          | 3            |
   | 30  | Outlet #12    | switch-t332       | 26          | 4            |
   | 31  | Input #2      | XFMR #1 feed      | 11          | 3            |
   | 32  | Input #2 - L1 | Line L1 / X / A   | 31          | 0            |
   | 33  | Input #2 - L2 | Line L2 / Y / B   | 31          | 0            |
   | 34  | Input #2 - L3 | Line L3 / Z / C   | 31          | 0            |
   | 35  | Input #2 - N  | Line Neutral / N  | 31          | 0            |
   | 36  | Bank #4       | Branch Cir. L1/L2 | 31          | 1            |
   | 37  | Outlet #13    | filer01-sjc-pwr2  | 36          | 1            |
   | 38  | Outlet #14    | ...               | 36          | 2            |
   | 39  | Outlet #15    | ...               | 36          | 3            |
   | 40  | Outlet #16    | ...               | 36          | 4            |
   | 41  | Bank #5       | Branch Cir. L2/L3 | 31          | 2            |
   | 42  | Outlet #17    | ...               | 41          | 1            |
   | 43  | Outlet #18    | ...               | 41          | 2            |
   | 44  | Outlet #19    | ...               | 41          | 3            |
   | 45  | Outlet #20    | ...               | 41          | 4            |
   | 46  | Bank #6       | Branch Cir. L3/L1 | 31          | 3            |
   | 47  | Outlet #21    | ...               | 46          | 1            |
   | 48  | Outlet #22    | ...               | 46          | 2            |
   | 49  | Outlet #23    | ...               | 46          | 3            |
   | 50  | Outlet #24    | ...               | 46          | 4            |
   | 51  | Outlet Gang 1 | Finance Servers   | 6           | 0            |
   | 52  | Outlet Gang 2 | Sales Servers     | 6           | 0            |
   | 53  | VoIP Phone    | VoIP/SIP Phone    | 3           | 0            |
   | 54  | Windows PC    | John Smith's PC   | 5           | 0            |
   +-----+---------------+-------------------+-------------+--------------+

   entLogicalTable
   +-----+---------------+
   | Idx | Descr         |
   +-----+---------------+
   | 1   | Eth. Switch   |
   | 2   | Port 1        |
   | 3   | Port 2        |
   | 4   | Port 3        |
   | 5   | Port 4        |
   | 6   | ePower PDU    |
   | 7   | NIC           |
   | 8   | LCD           |
   | 9   | Processor     |
   | 10  | RTC Battery   |
   | 11  | Input #1      |
   | 12  | Input #1 - L1 |
   | 13  | Input #1 - L2 |
   | 14  | Input #1 - L3 |
   | 15  | Input #1 - N  |
   | 16  | Bank #1       |
   | 17  | Outlet #1     |
   | 18  | Outlet #2     |
   | 19  | Outlet #3     |
   | 20  | Outlet #4     |
   | 21  | Bank #2       |
   | 22  | Outlet #5     |
   | 23  | Outlet #6     |
   | 24  | Outlet #7     |
   | 25  | Outlet #8     |
   | 26  | Bank #3       |
   | 27  | Outlet #9     |
   | 28  | Outlet #10    |
   | 29  | Outlet #11    |
   | 30  | Outlet #12    |
   | 31  | Input #2      |
   | 32  | Input #2 - L1 |
   | 33  | Input #2 - L2 |
   | 34  | Input #2 - L3 |
   | 35  | Input #2 - N  |
   | 36  | Bank #4       |
   | 37  | Outlet #13    |
   | 38  | Outlet #14    |
   | 39  | Outlet #15    |
   | 40  | Outlet #16    |
   | 41  | Bank #5       |
   | 42  | Outlet #17    |
   | 43  | Outlet #18    |
   | 44  | Outlet #19    |
   | 45  | Outlet #20    |
   | 46  | Bank #6       |
   | 47  | Outlet #21    |
   | 48  | Outlet #22    |
   | 49  | Outlet #23    |
   | 50  | Outlet #24    |
   | 51  | Outlet Gang 1 |
   | 52  | Outlet Gang 2 |
   | 53  | VoIP Phone    |
   | 54  | Windows PC    |
   +-----+---------------+

   entLPMappingTable
   +------------+-------------+
   | LogicalIdx | PhysicalIdx |
   +------------+-------------+
   | 51         | 22          |          Outlet Gang #1 -> Outlet #5
   | 51         | 23          |                         -> Outlet #6
   | 51         | 24          |                         -> Outlet #7
   | 52         | 23          |          Outlet Gang #2 -> Outlet #6
   | 52         | 37          |                         -> Outlet #13
   +------------+-------------+

UPDATE 2011-03-08: Building on Juergen Schoenwaelder's point about the
intended use of entLogicalTable, however, such a structure would be incorrect
and not plausible for implementation.  Some kind of structure that emulates
these requirements, however, would be needed.  This is the foundation behind
emanEntityTable in draft-verges-eman-separate-modules-mib-00.

Questions that remain to be answered:

   1. When an entity is disconnected/removed (like the ePower PDU being
      disconnected from the switchport), what is the behavior related to
      ENTITY-MIB?  Are the entries removed and, if so, are the indices for the
      remaining entries collapsed/adjusted to remove the gap?

      UPDATE 2011-03-08: entPhysicalIndex should not be collapsed/adjusted, as
      described in Juergen S.'s response
      (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html).

   2. What happens when an entity is reconnected (like the same ePower PDU
      being connected to a different switchport), what is the behavior related
      to ENTITY-MIB?  Are the original indices reused?

      UPDATE 2011-03-08: New entities would be given a new PhysicalIndex
      value.  Reconnected entities may optionally reuse their old
      PhysicalIndex value (if that value is available), but do not have to
      since a UUID can be persisted for the entity via entPhysicalUris.
      (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html)

   3. How will an Energy Management System (EMS) or other NMS using this data
      ensure that the data gathered and control mechanisms used are
      universally guaranteed?  Does a UUID or other form of identification
      need to be created for an entity and, if so, how is that UUID exposed
      via ENTITY-MIB?

      UPDATE 2011-03-08: Universal identification may be achieved through
      either entPhysicalAssetID (a user-writable field) or entPhysicalUris
      (most likely preferred).  See RFC4122 for information on using
      entPhysicalUris to carry UUID URNs.
      (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html)

   4. How does this proposed use of ENTITY-MIB for EMAN's purposes relate to
      the standard, existing use of ENTITY-MIB in the industry?

      UPDATE 2011-03-08: ENTITY-MIB does not support arbitrary logical
      groupings at present, and a mechanism would need to be created to
      support this functionality.
      (http://www.ietf.org/mail-archive/web/eman/current/msg00272.html)

      UPDATE 2011-03-08: There is sufficient complexity involved in some
      logical groupings at the energy reporting/management level to warrant
      logical groupings.  Allowing the agent to handle these logical groupings
      rather than burdening the EMS/BMS/NMS puts the domain-specific
      complexity involved in energy measurements/calculations in the hands of
      the manufacturer who specializes in it.
      (http://www.ietf.org/mail-archive/web/eman/current/msg00274.html)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Mar 2011 12:31:58 +0100

> separate structure wholy contained in the EMAN MIB schema.

I request that we change the terminology to avoid the use of the term
"logical entity" with two different meanings. Since the ENTITY-MIB has
a define meaning of "logical entity", I think EMAN should use a
different term to refer to "functional groupings".

The ENTITY-MIB models a containment hierarchy of physical entities
representing components of a managed system. Every physical entity has
0 or 1 parents (entPhysicalTable, entPhysicalContainsTable). Physical
entities can have stable identifiers, such as URIs (containing UUIDs)
or assigned stable identifiers (entPhysicalAssetID, entPhysicalAlias).
Every physical entity can point to an arbitrary number of other
modelled resources such as bridge ports, network interfaces, ...
(entAliasMappingTable).

A logical entity is an SNMP context, that is an instantiation of a MIB
object tree in a naming scope identified by the contextEngineID and
the contextName. An SNMP agent can provide access to multiple contexts
(multiple MIB object trees). The ENTITY-MIB provides a list of
existing logical entities (SNMP contexts) and it provides pointers in
which logical contexts physical entities participate (entLogicalTable,
entLPMappingTable).

If there is a need to represent "functional groupings", then we can
either use SNMP contexts (note that the entLPMappingTable allows to
map physical entities into logical contexts), although that might not
be sufficient, or we could extend the ENTITY-MIB by providing a
functional grouping mechanism (perhaps designing an indexing scheme
that makes it easy to refer to both physical entities and functional
groupings of physical entities), or we might follow the path of
creating a data model only loosely coupled to the ENTITY-MIB (but then
I think we should avoid overlap as much as possible and for the
overlap that is not avoidable, we need to explain how this is going to
be implemented).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: [email-masked]
Date: Thu, 17 Mar 2011 08:43:56 -0700

> different term to refer to "functional groupings".

Rather than "functional groupings," which does not reflect the managed
entity nature of the end goal, how about the following breakdown
instead?

   1. Physical entity - ENTITY-MIB
   2. Logical entity - ENTITY-MIB
   3. Virtual entity - EMAN
   4. Power entity - EMAN

A "power entity" can either refer to a "physical entity" or a "virtual
entity."  A "virtual entity" is anything that behaves similar to a
"physical entity" but which has no actual physical nature, like a
virtual machine or an outlet gang or a daemon running on the system.

This clarifies the point that we need to manage "virtual entities" just
like we would "physical entities."  The term "functional groupings"
makes it seem like we're bundling things just for abstract purposes
only, whereas there is a deeper use case being answered in reality.

> overlap that is not avoidable, we need to explain how this is going to

Since ENTITY-MIB was specifically designed to represent a physical
instantiation of a system, it does not handle virtual entities (as
described above) properly.  I would like to see it extended to solve
the cases that we are grappling with here; however, such an undertaking
would be outside of EMAN's scope and delay the development and release
of EMAN-MIB significantly.  Please feel free to let the ENTITY-MIB
working group know that some changes are desired in their model and let
them begin working on it as a separate undertaking -- I am happy to help
explain use cases if needed.  But we need to focus on developing
something that will work for EMAN in a timely manner, and already have
solutions for doing that.

In both draft-verges and draft-parello (now
draft-ietf-eman-energy-aware), we create such a data model that loosely
couples with ENTITY-MIB but does not rely on it.  I'm hearing that you
may be coming around to the same conclusion that ENTITY-MIB won't
properly handle these "virtual entities" that EMAN needs to support, so
would either of these proposed models in the drafts fit your needs?  If
not, what needs to change?

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 10:00:48 +0100

> only, whereas there is a deeper use case being answered in reality.

The ENTITY-MIB has been designed to be relatively generic. If
arbitrary groupings of physical entities need to be added, we better
do it in a generic way instead of inventing this N times over again.

> described above) properly.

That is not what I said.

> I would like to see it extended to solve

The process argument and that claim that extending the ENTITY-MIB is
going to be way slower than EMAN can tolerate. Been there before.
 
> draft-ietf-eman-energy-aware), we create such a data model that
> loosely couples with ENTITY-MIB but does not rely on it.  I'm
> hearing that you may be coming around to the same conclusion that
> ENTITY-MIB won't properly handle these "virtual entities" that EMAN
> needs to support, so would either of these proposed models in the
> drafts fit your needs?  If not, what needs to change?

No, virtual entities are just fine (or we have different definition
what virtual entities means). I see a large duplication of the
ENTITY-MIB in several of the MIBs flowing around (sometimes lacking
essential pieces that are in the ENTITY-MIB) and I fail to see why
that can be desirable.

/js

---

From: [email-masked]
Date: Fri, 18 Mar 2011 08:04:55 -0700

> essential pieces that are in the ENTITY-MIB) and I fail to see why

Given that I defined "virtual entities" above, what aspect of the
definition are we in disagreement on?

If you really are seeing several working groups that are implementing
something like ENTITY-MIB but not using ENTITY-MIB itself, there has to
be a reason.  Either ENTITY-MIB doesn't meet their needs (like we are
encountering in EMAN) or it's an education problem (certainly we
experienced that on the mailing list, too) or something else might be
going on.  I'd suggest that those who are responsible for ENTITY-MIB do
their own due-diligence to vet out these newer use cases and change
ENTITY-MIB appropriately.  However, if we hold up several working groups
while waiting for this analysis to be finished, you're talking about
effectively stopping forward progress on multiple WG's while this is
being done.  I don't know about your employer, but mine would probably
fire me for something like this.  :-)  We can always spin the EMAN MIBs
later to bring them into alignment with the new model when (if?) it is
developed.

Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Mar 2011 16:51:15 +0100

> later to bring them into alignment with the new model when (if?) it is

I was talking about EMAN related MIBs, not multiple working groups.
And as you might have noticed, the IETF is not working like a normal
company.

I got involved here because I did not find a good description why
using existing MIB modules does not work - and this is a reasonable
question to ask since there is quite some overlap in some of the MIB
modules I have seen related to this working group. I found that some
people were confused how the ENTITY-MIB works and I took an initiative
to clear up the confusion while learning more about the things this WG
is trying to achieve. You may or may not appreciate this.

/js

---

From: [email-masked]
Date: Fri, 18 Mar 2011 09:09:40 -0700

> And as you might have noticed, the IETF is not working like a normal

I apologize for misunderstanding then.  I thought you were indicating
that several working groups were coming up against the same challenge.

That does not negate the sense of urgency surrounding EMAN's
undertaking, however.

> is trying to achieve. You may or may not appreciate this.

And your input into ENTITY-MIB is greatly appreciated.  I certainly
learned a lot from your and Dan's comments on the list.  But I keep
coming back to the conclusion that ENTITY-MIB was not structured to work
for virtual entities, and EMAN has a requirement to support virtual
entities alongside physical entities.

How do we drive the discusion about ENTITY-MIB to an actionable
conclusion?  Do we (EMAN WG) propose whatever extensions are needed to
ENTITY-MIB to make it work?  Or do we ask the WG who originally created
it to take this venture on?  Or do we say that we are going to set up
our own entity structure and simply give a nod (reference) ENTITY-MIB
where appropriate for physical entities?  Or some fourth choice that
isn't yet mentioned?

Thanks,
Chris