Subject: [eman] Use of ENTITY-MIB in EMAN

From: [email-masked]
Date: Sat, 5 Mar 2011 16:27:33 -0800

Hi all,

The large number of discussions related to the use of ENTITY-MIB
prompted me to look further at its use related to EMAN.  I'd like to
thank Dan and Juergen for helping to explain certain concepts during the
development of this analysis.

I've finished putting together the first draft of the analysis and
invite your feedback.  (Especially from those of you who understand
ENTITY-MIB better than I do!)  Please take a look and make sure that
such a structural breakdown makes sense and works for the various needs
related to EMAN.

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Mar 2011 10:44:56 +0100

> 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
>    +------------+-------------+

I do not think this is a proper usage of entLogicalTable. The
entLogicalTable is used to refer to other SNMP contexts where
additional data resides.
 
> 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.

This would be more wrong use of entLogicalTable.

> 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.

How is an outlet gang different from a port module of a switch, except
that it allows out outlet to be in multiple outlet groups?

> 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.
> 
> 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
>    +------------+-------------+

Again, I think this is not a proper use of the entLogicalTable.

> 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?

PhysicalIndex ::= TEXTUAL-CONVENTION
    DISPLAY-HINT      "d"
    STATUS            current
    DESCRIPTION
            "An arbitrary value that uniquely identifies the physical
            entity.  The value should be a small, positive integer.
            Index values for different physical entities are not
            necessarily contiguous."
    SYNTAX Integer32 (1..2147483647)

>    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?

I assume this is implementation specific.

>    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?

The entPhysicalTable has a number of columns providing identification
information. It they are not sufficient and a UUID column is needed,
then the entPhysicalTable can be easily augmented.

>    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?

This usages of entLogicalTable I believe is pretty much a non-standard
usage of the ENTITY-MIB. The switches and routers supporting the
ENTITY-MIB do not seem to use it in that way.

/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: Mon, 7 Mar 2011 04:38:40 -0800

Hi Juergen,

Thank you for your reply and thoughts!  Additional follow up questions
are in-line with you responses.

> This would be more wrong use of entLogicalTable.

Agreed.  Do you have a different proposal of how to structure things?

> that it allows out outlet to be in multiple outlet groups?

The primary difference is that a port module on a switch is a physical
entity that pre-defines the grouping.  The outlet gang is a virtual
entity that has an arbitrary grouping which is unrelated to the physical
layout of the PDU.

>     SYNTAX Integer32 (1..2147483647)

I apologize if I'm not understanding your answer properly.  I understand
the definition of PhysicalIndex, but are you saying that the
entPhysicalIndex should not be adjusted?  Therefore, new items connected
to the switchport would be given new PhysicalIndex values?  Would an
agent be required to persist and reuse the IDs for a reconnected device?
What if the reconnected device is plugged into a different switchport on
the same switch?

> I assume this is implementation specific.

What are the impacts on an EMS/BMS/NMS system if we leave such behavior
unspecified?

> then the entPhysicalTable can be easily augmented.

So is a UUID needed?  For example, if we disconnect a PDU from Switch #1
and connect it to Switch #2, should the EMS/BMS/NMS know that the PDU is
the "same" PDU and has just moved connection points?

> ENTITY-MIB do not seem to use it in that way.

The reason that entLogicalTable was used this way is to provide a
mechanism to enable virtual, arbitrary groupings of non-physical
entities as they relate to physical ones.  Consider it similar to
channel bonding (EtherChannel, Ethernet bonding, link aggregation, etc.)

entPhysicalTable seems to not be the proper home for such virtual
entities, and I'm hearing that entLogicalTable is also not the proper
home.  So what is?  This is where there appears to be a gap, either in
my understanding or in the limitations of ENTITY-MIB.

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2011 12:35:22 +0100

On Mon, Mar 07, 2011 at 04:38:40AM -0800, [email-masked] wrote:

[...]
 
> Agreed.  Do you have a different proposal of how to structure things?

Concerning outlet gangs, which seem to be a pure logical aggregation
unit as far as I understand things, I would start by asking why they
need to be represented on the device in the first place since
aggregation can easily be done in flexible ways outside the devices.
If outlet gangs need to be represented on devices, the question pops
up how they are created. I have not seen that in any of the MIBs
either (but I might have overlooked this).

> entity that has an arbitrary grouping which is unrelated to the physical

OK

> entPhysicalIndex should not be adjusted?

yes

> Therefore, new items connected
> to the switchport would be given new PhysicalIndex values?  

yes

> Would an

This does not seem to be clearly spelled out. Since the physical
component carries information about itself, I would assume that it is
OK to simply allocate a index. I currently do not have access to a hot
pluggable device implementing the ENTITY-MIB to check what
implementations actually do.

> What if the reconnected device is plugged into a different switchport on

The ENTITY-MIB requires that values such as the entPhysicalAssetID are
retained.

            If write access is implemented for an instance of
            entPhysicalAssetID, and a value is written into the
            instance, the agent must retain the supplied value in the
            entPhysicalAssetID instance (associated with the same
            physical entity) for as long as that entity remains
            instantiated.  This includes instantiations across all
            re-initializations/reboots of the network management system,
            including those resulting in a change of the physical
            entity's entPhysicalIndex value.

This makes me assume that the index value can change, but the
properties of a physical entity should remain.

> What are the impacts on an EMS/BMS/NMS system if we leave such behavior

I assume that the idea properties of a physical entity persist. While
this is not spelled out in the DESCRIPTION of entPhysicalUris, there
is text in section 2.12.1. that states:

     [...] Uniform Resource Names (URNs), RFC
     3406 [RFC3406], are resource identifiers with the specific
     requirements for enabling location independent identification of a
     resource, as well as longevity of reference.

> the "same" PDU and has just moved connection points?

Note that entPhysicalUris can carry UUID URNs (see RFC 4122).

> my understanding or in the limitations of ENTITY-MIB.

Yes, the ENTITY-MIB does not support arbitrary logical groupings. If
this is needed, such a grouping mechanism would have to be added. But
also consider the question whether this really needs to be on the
device. The ENERGY-AWARE-MIB seems to instead just tag entities and
leaves the interpretation of the groups created by tagging to an
application.

/js

---

From: [email-masked]
Date: Tue, 8 Mar 2011 07:17:01 -0800

Hi Juergen,

Thanks for the feedback.  I'll roll it up into a new revision of the
eman-relationship-to-entity-mib document.  Some addition
answers/questions inline:

> either (but I might have overlooked this).

Yes, they need to be represented on the device itself.  The ganging
concept can be enabled from many vendors' HTTP/CLI interfaces.  If we
can expose these logically created entities over SNMP, it means less
duplication of effort for the send user to setup these entities again in
the EMS/BMS/NMS.

> > entPhysicalIndex should not be adjusted?

So what begs the question of what to do when we hit the maximum value
(2147483647) as we constantly count up.  Do we roll over to zero again?
If we're adding in a whole collection of entities, like the 30+ rows
required for a PDU, and the max value would fall in the middle of the
30+ row group, should we count up to the max value and THEN rollover; or
should we rollover first and find a contiugous block to use?

> Note that entPhysicalUris can carry UUID URNs (see RFC 4122).

So it sounds like all of the questions in the above quoted block are
answered by using entPhysicalUris to carry a UUID for the entity in
question.  This allows us to vary the entPhysicalIndex arbitrarily, but
gives the EMS/BMS/NMS a constant identifier for the entity.

> leaves the interpretation of the groups created by tagging to an

I'm not the biggest fan of the current ENERGY-AWARE-MIB proposed in
draft-ietf-eman-energy-aware-mib-00.  So that argument won't hold much
weight.  :-)

As I indicated above, I do think that outlet groups should be supported
on a device.  It's a question of whether we want to simplify complexity.
Consider the following scenario:

   An outlet gang has two three-phase AC outlets in it.  One of the
   outlets is wired as a 3PH Wye (line-neutral) and the other as a 3PH
   Delta (line-line).

To "gang" these two outlets together for data reporting purposes
requires a mathematical technique known as symmetric component analysis.
The 3PH Delta entity must be converted to the 3PH Wye equivalent, and
then the two vector tuples can be combined.

An EMS/BMS/NMS administrator should never try to figure this out on
their own.  It's a fairly complex process, and definitely part of a
specific domain of knowledge that is unknown to many network
administrators.  Therefore, we should let the equipment manufacturer who
has that specialized knowledge do all of the "heavy lifting" and just
simply expose the solution to the user as a logical entity.

Thanks,
Chris

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Mar 2011 17:44:54 +0100

> should we rollover first and find a contiugous block to use?

Usually, you count up until you roll over. But realistically speaking,
how fast do physical entities change in the real world and what is the
overall time it takes to roll over?
 
> gives the EMS/BMS/NMS a constant identifier for the entity.

Yes, entPhysicalUris can provide a persistent identifier for the
physical entity. That does however not imply that varying
entPhysicalIndex arbitrarily is going to be a good thing. You like to
keep the stable so that a EMS/BMS/NMS does not constantly have to
resynchronize.

> simply expose the solution to the user as a logical entity.

See, I am all ignorant about power supplies. ;-)

/js