Subject: [eman] Outlet Gang addition to draft-ietf-eman-requirements-00

From: [email-masked]
Date: Fri, 4 Mar 2011 11:02:16 -0800

Hi Juergen,

I wrote an additon to the various scenarios described in
draft-ietf-eman-requirements-00 to address the "Outlet Gang" scenario
found on Smart PDUs.  Please let me know if you have any questions while
integrating it.

$ diff draft-ietf-eman-requirements-00.txt draft-ietf-eman-requirements-01.txt
416a417,449
> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
>
>    Some PDUs allow physical entities like outlets to be "ganged" together as a
>    logical entity for simplified management purposes.  This is particularly
>    useful for servers with multiple power supplies, where each power supply is
>    connected to a different physical outlet.  Other implementations allow
>    "gangs" to be created based on common ownership of outlets, such as
>    business units or load shed priority or other non-physical relationships.
>
>    Current implementations allow for an "M-to-N" mapping between outlet
>    "gangs" and physical outlets.  An example of this mapping includes the
>    following:
>
>       Outlet 1             (physical entity)
>       Outlet 2             (physical entity)
>       Outlet 3             (physical entity)
>       Outlet 4             (physical entity)
>       Outlet Gang A        (virtual entity)
>       Outlet Gang B        (virtual entity)
>
>       Gang A -> Outlets 1, 2 and 3
>       Gang B -> Outlets 3 and 4
>
>    Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both
>    "gangs."
>
>    Each "Outlet Gang" entity reports the aggregated data from the individual
>    outlet entities that comprise it and enables a single point of control for
>    all the individual outlet entities.  For example, turning "Outlet Gang A"
>    to the "off" state would turn outlets 1, 2, and 3 "off" in some
>    implementations.  (The impact of this action on "Outlet Gang B" is to be
>    defined by the equipment manufacturer.)
>

Thanks,
Chris
416a417,449
> 2.9.  Scenario 9: Ganged outlets on a Smart Power Strip
> 
>    Some PDUs allow physical entities like outlets to be "ganged" together as a
>    logical entity for simplified management purposes.  This is particularly
>    useful for servers with multiple power supplies, where each power supply is
>    connected to a different physical outlet.  Other implementations allow
>    "gangs" to be created based on common ownership of outlets, such as
>    business units or load shed priority or other non-physical relationships.
> 
>    Current implementations allow for an "M-to-N" mapping between outlet
>    "gangs" and physical outlets.  An example of this mapping includes the
>    following:
> 
>       Outlet 1             (physical entity)
>       Outlet 2             (physical entity)
>       Outlet 3             (physical entity)
>       Outlet 4             (physical entity)
>       Outlet Gang A        (virtual entity)
>       Outlet Gang B        (virtual entity)
> 
>       Gang A -> Outlets 1, 2 and 3
>       Gang B -> Outlets 3 and 4
> 
>    Note the allowed overlap on Outlet 3, where Outlet 3 belongs to both
>    "gangs."
> 
>    Each "Outlet Gang" entity reports the aggregated data from the individual
>    outlet entities that comprise it and enables a single point of control for
>    all the individual outlet entities.  For example, turning "Outlet Gang A"
>    to the "off" state would turn outlets 1, 2, and 3 "off" in some
>    implementations.  (The impact of this action on "Outlet Gang B" is to be
>    defined by the equipment manufacturer.)
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Mar 2011 11:12:58 +0100

Hi Chris,

Thanks for your proposal.
I also believe we should be solving the case of multiple power supplies
However, we will have to pay attention that we don't double count the 
traffic in the Power Monitor Metering Domain.
See http://tools.ietf.org/html/draft-ietf-eman-framework-00 ->   Section 
5.2. Power Monitor Topologies: Metering versus Control versus Power 
Distribution. So, even if there are two topologies for power 
distribution, we would need a single Power Monitor Parent.

Regarding the gang, could we solve this one with the context 
information? For example, the pmKeywords in 
http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01

Regards, Benoit.
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: "Chris Verges" <[email-masked]>
Date: Mon, 14 Mar 2011 09:16:11 -0700

Hi Benoit,

Could we solve it with a "keywords" style field?  Perhaps.  However, the
relationship of an outlet gang to its physical outlets is more
structural than that.  It should be a separate field/mechanism so that
modifying one does not inadvertently affect the other.  Trying to
combine the two is not the best solution and will bring up limitations
of the schema later.

For example, why use pmParentId rather than including this information
in pmKeywords?  The pmParentId/pmIndex relationship is separate from the
pmIndex/pmKeywords relationship in an object class diagram and for good
reason.  

Chris

From: Benoit Claise [mailto:[email-masked]] 
Sent: Monday, March 14, 2011 3:13 AM
To: Chris Verges
Cc: [email-masked]
Subject: Re: [eman] Outlet Gang addition to
draft-ietf-eman-requirements-00

Hi Chris,

Regards, Benoit.

Hi Juergen,

$ diff draft-ietf-eman-requirements-00.txt
draft-ietf-eman-requirements-01.txt
416a417,449

	   Some PDUs allow physical entities like outlets to be "ganged"
together as a
	   logical entity for simplified management purposes.  This is
particularly
	   useful for servers with multiple power supplies, where each
power supply is
	   connected to a different physical outlet.  Other
implementations allow
	   "gangs" to be created based on common ownership of outlets,
such as
	   business units or load shed priority or other non-physical
relationships.
	 
	   Current implementations allow for an "M-to-N" mapping between
outlet
	   "gangs" and physical outlets.  An example of this mapping
includes the
	   following:

	 
	   Note the allowed overlap on Outlet 3, where Outlet 3 belongs
to both
	   "gangs."
	 
	   Each "Outlet Gang" entity reports the aggregated data from
the individual
	   outlet entities that comprise it and enables a single point
of control for
	   all the individual outlet entities.  For example, turning
"Outlet Gang A"
	   to the "off" state would turn outlets 1, 2, and 3 "off" in
some
	   implementations.  (The impact of this action on "Outlet Gang
B" is to be
	   defined by the equipment manufacturer.)

Thanks,
Chris

---

From: Benoit Claise <[email-masked]>
Date: Fri, 18 Mar 2011 15:35:35 +0100

Hi Chris,

I understand your concern.
However, we can't redo the full ENTITY-MIB physical and logical entities 
in EMAN.
Would it be sufficient for you to implement the ENTITY-MIB, following 
the link to the
entityPhysicalIndex from 
http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-01?

Regards, Benoit.
>
> Hi Benoit,
>
> Could we solve it with a "keywords" style field?  Perhaps.  However, 
> the relationship of an outlet gang to its physical outlets is more 
> in pmKeywords?  The pmParentId/pmIndex relationship is separate from 
> the pmIndex/pmKeywords relationship in an object class diagram and for 
> good reason.
>
> Chris
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:* Monday, March 14, 2011 3:13 AM
> *To:* Chris Verges
> *Cc:* [email-masked]
> *Subject:* Re: [eman] Outlet Gang addition to 
> See http://tools.ietf.org/html/draft-ietf-eman-framework-00 ->   
> Section 5.2. Power Monitor Topologies: Metering versus Control versus 
> Power Distribution. So, even if there are two topologies for power 
> [email-masked]  <mailto:[email-masked]>

---

From: [email-masked]
Date: Fri, 18 Mar 2011 08:22:20 -0700

On Fri, Mar 18, 2011 at 03:35:35PM +0100, Benoit Claise wrote:
> I understand your concern.  However, we can't redo the full ENTITY-MIB
> physical and logical entities in EMAN.  Would it be sufficient for you
> to implement the ENTITY-MIB, following the link to the
> entityPhysicalIndex from

But we can't (shouldn't) represent "virtual entities" in the "physical
entity" table.  So I'm failing to see how this is supposed to help.

I agree with JS' point (different thread) that ENTITY-MIB should be
extended to provide a "Generic Entity" index that "Physical Entities"
and "Virtual Entities" and "Logical Entities" then become sparse tables
out of.  This allows for a single index and lets us worry about
structure inside this new EXTENDED-ENTITY-MIB.  However, we don't have
this (yet).

So if we decide to move forward with EMAN-MIB, then we are taking on the
responsibility of setting up the structure needed.  This includes
properly separating filter mechanisms (keywords) from object
relationship (structure).  You're proposing to use both, but mixing the
two confuses the unique purpose behind each.

This confusion can be best exemplified if we want to change keywords:

   Outlet A      -> outlet_gang_1, foo, bar
   Outlet B      -> outlet_gang_1, baz, fred
   Outlet Gang 1 -> outlet_gang_1, foo

Conceptually, we want to say that "Outlet Gang 1" has members "Outlet A"
and "Outlet B."  However, given that certain keywords ("foo") are shared
between "Outlet Gang 1" and "Outlet A," which keyword should actually be
used for the structural grouping identifier?

Furthermore, if we set a new collection of keywords, do we have to
ensure that we always copy the structurally-critical ones?

   snmpset ... "Outlet Gang 1".keywords.0 "fred"

Would the above snmpset automatically populate the keyword
"outlet_gang_1" on the agent side?  Not only does this seem confusing
(since it implies a hidden modality) but begs the question of what we do
in a simlar snmpset for a regular outlet.

EMAN-MIB should either build the entity structure needed or fully rely
on an external MIB to do so.  Let's not compromise the integrity of
EMAN-MIB on a desire to reduce duplication where there is no duplication
at this point anyway.

Chris