Subject: Re: [eman] Two NMS configuring the Power Monitor with two different Power State Series

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Sun, 24 Jul 2011 23:30:31 -0500

I apologize for having gone silent for so long but I am here in Quebec and am working through old emails to come back up to speed.  I also apologize for perhaps covering old ground in some cases.  I plan to comment as I go chronologically through the list archive.  If I comment on something which was later resolved please bear with me as I will eventually find the resolution along the way.  Either way it is probably better that I record my comments in the event that I identify something that has not been considered fully.

Regarding the issue of 2 NMS's interacting with a single Managed Object using different power state series, my thinking all along was that the managed object would choose (align with) the power series that made sense for it and that the NMS's would have to adapt to talking to the managed object in its preferred  (supported) series.  So in this case there is no confusion, the series selected by the managed object is always the one that will be used by any NMS.  This approach is consistent with Juergen S. point that traditionally the NMS was assumed to be better able to deal with these types of variations rather then the managed object implementation.

How was this point ultimately resolved, assuming it was?

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, May 03, 2011 5:29 AM
> To: Benoit Claise
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor 
> with two different Power State Series
> 
> On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
>  
> > Let's discuss the following situation: what if we have 2 NMS', and
> > they speak different Power State Series for a specific Power
> > Monitor? Should this be allowed by the [EMAN-REQ]?
> 
> Traditionally, it was always assumed that an SNMP management system
> can more easily adapt to devices than the other way round.
> 
> > Actually this requirement has got some implications in terms of the
> > MIB design (taking
> > http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> > into account)
> > 
> > - If the answer is yes, then we need to have an extra index in the
> > power pmPowerTable. This index must abe a new TC, which is only for
> > the Power State Series.  Note: the table needs to redesigned because
> > the common variable (caliber, nameplate, etc...) are common per
> > Power State Series. Then we can have a new table, for discovery,
> > that will only contain  two indices: pmPowerMonitorIndex and the new
> > TC-defined pmPowerStateSeries.
> > - If the answer is no, then there is the risk that NMS1 will set the
> > DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the
> > Power Monitor supports both the DMTF and the EMAN Power State
> > Series), and there is a ping-pong game between two NMS's that don't
> > synchronize between the two.
> 
> If two management systems make changes without coordination, you
> always have a chance for ping-pong effects, even within a Power State
> Series. That said, it might be possible to provide guidelines such as
> if a device is reporting a value of a given Power State Series
> (e.g. DMTF:3), a management application should adapt and use DMTF
> power states.
> 
> > The alternative is that the first NMS would say: I will speak to the
> > Power Monitor with the DMTF Power State Series, and then all the
> > other NMS's will have to speak the same language (i.e. DMTF).
> 
> I think that is a reasonably assumption to make if the number of
> different Power State Series is kept limited (that is we prevent that
> every vendor/organization comes up with its own creative series of
> power states). A large number of different Power State Series will be
> hindering interoperability, with or without ping-pong effects.
> 
> /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/>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 01:11:55 -0400

Hi Bill,
> How was this point ultimately resolved, assuming it was?
By having an extra index in the tables. First the power state series, 
then the power state.
>From http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:

        pmPowerTable OBJECT-TYPE
             SYNTAX          SEQUENCE OF PmPowerEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "This table lists Power Monitors."
             ::= { powerMonitorMIBObjects 1 }

         pmPowerEntry OBJECT-TYPE
             SYNTAX          PmPowerEntry
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "An entry describes the power usage of a Power Monitor."
             INDEX           { pmPowerIndex, pmPowerStateSetIndex}

>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>

---

From: Thomas Dietz <[email-masked]>
Date: Mon, 25 Jul 2011 08:38:48 +0000

Dear Bill,

The way set forward in the recent draft that was pointed out by Benoit gives
the different NMS the freedom to choose which power series to take if the
managed object supports more than one. And I don't think it is much of an
overhead for the managed object to match one power series to another.

Best Regards,

Thomas

-- 
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115
Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: NEC House, 1 Victoria Road, London W3 6BL

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: Montag, 25. Juli 2011 07:12
> To: Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: Re: [eman] Two NMS configuring the Power Monitor with two
> different Power State Series
> 
> Hi Bill,
> > I apologize for having gone silent for so long but I am here in Quebec
> and am working through old emails to come back up to speed.  I also
> apologize for perhaps covering old ground in some cases.  I plan to
> comment as I go chronologically through the list archive.  If I comment on
> something which was later resolved please bear with me as I will
> eventually find the resolution along the way.  Either way it is probably
> better that I record my comments in the event that I identify something
> that has not been considered fully.
> >
> > Regarding the issue of 2 NMS's interacting with a single Managed Object
> using different power state series, my thinking all along was that the
> managed object would choose (align with) the power series that made sense
> for it and that the NMS's would have to adapt to talking to the managed
> object in its preferred  (supported) series.  So in this case there is no
> confusion, the series selected by the managed object is always the one
> that will be used by any NMS.  This approach is consistent with Juergen S.
> point that traditionally the NMS was assumed to be better able to deal
> with these types of variations rather then the managed object
> implementation.
> >

---

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 25 Jul 2011 11:06:06 -0700

Hi Thomas,

I agree with you. Having multiple series supported at the same time is
not an overhead. If a device cannot then it should advertise only the
one.

I don't see why a device would advertise more than one series then
restrict to one.

if a devices can do multiple series then advertise as such if not
advertise only one.

I have implementations that multiple series right now so it's not
difficult and makes the NMS discovery much more straight forward and
more importantly universal.

+1

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Dietz
Sent: Monday, July 25, 2011 1:39 AM
To: Benoit Claise (bclaise); Mielke, William F (Bill)
Cc: eman mailing list
Subject: Re: [eman] Two NMS configuring the Power Monitor with two
different Power State Series

Dear Bill,

The way set forward in the recent draft that was pointed out by Benoit
gives the different NMS the freedom to choose which power series to take
if the managed object supports more than one. And I don't think it is
much of an overhead for the managed object to match one power series to
another.

Best Regards,

Thomas

NEC Europe Limited, Registered in England 2832014 Registered Office: NEC
House, 1 Victoria Road, London W3 6BL

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Benoit Claise
> comment as I go chronologically through the list archive.  If I 
> comment on something which was later resolved please bear with me as I

> will eventually find the resolution along the way.  Either way it is 
> probably better that I record my comments in the event that I identify

> something that has not been considered fully.
> >

> managed object would choose (align with) the power series that made 
> sense for it and that the NMS's would have to adapt to talking to the 
> managed object in its preferred  (supported) series.  So in this case 
> there is no confusion, the series selected by the managed object is 
> always the one that will be used by any NMS.  This approach is
consistent with Juergen S.

> > Distinguished Member of Technical Staff 6200 East Broad Street
> > Room: 4B01-1V
> > Columbus, OH  43213-1530

> >>> Actually this requirement has got some implications in terms of 
> >>> the MIB design (taking

> >>> power pmPowerTable. This index must abe a new TC, which is only 
> >>> for the Power State Series.  Note: the table needs to redesigned 
> >>> because the common variable (caliber, nameplate, etc...) are 
> >>> common per Power State Series. Then we can have a new table, for 
> >>> discovery, that will only contain  two indices: 
> >>> pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.

> >>> Series), and there is a ping-pong game between two NMS's that 
> >>> don't synchronize between the two.
> >> always have a chance for ping-pong effects, even within a Power 
> >> State Series. That said, it might be possible to provide guidelines

> >> such as if a device is reporting a value of a given Power State 
> >> Series (e.g. DMTF:3), a management application should adapt and use

> >> DMTF power states.
> >>
> >>> The alternative is that the first NMS would say: I will speak to 
> >>> the Power Monitor with the DMTF Power State Series, and then all 
> >>> the other NMS's will have to speak the same language (i.e. DMTF).
> >> different Power State Series is kept limited (that is we prevent 
> >> that every vendor/organization comes up with its own creative 
> >> series of power states). A large number of different Power State 
> >> Series will be hindering interoperability, with or without
ping-pong effects.

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 25 Jul 2011 17:31:59 -0500

OK, I think I understand now.  I have no problem with a given device being able to support multiple power series simultaneously if it chooses to do so.

So let me articulate the operational scenario and you tell me if I have the proper understanding.

1. Assume some device X supports multiple power series.

2. NMS 1 queries to determine which power series device X supports.

3. NMS 1 selects one power series from the available set and uses that to interact with X.

4. NMS 2 queries to determine which power series device X supports.

5. NMS 2 selects a potentially different power series from the available set and uses that to interact with X.

6. NMS 1 and 2 both continue to interact with X using their respective choices and these interactions can be interleaved without difficulty.

If a device decides to only support one power series then when queried it only reports that one.

Is this generally the correct idea?

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

> From: John Parello (jparello) [mailto:[email-masked]] 
> Sent: Monday, July 25, 2011 2:06 PM
> To: Thomas Dietz; Benoit Claise (bclaise); Mielke, William F (Bill)
> Cc: eman mailing list
> Subject: RE: [eman] Two NMS configuring the Power Monitor 
> Behalf Of
> > From 
> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09:
> > 
> >         pmPowerTable OBJECT-TYPE
> > >>> - If the answer is no, then there is the risk that NMS1 
> will set 
> > >>> the

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 25 Jul 2011 18:47:42 -0400

Hi Bill,

Yes, that's exactly the idea.

    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 27 Jul 2011 11:19:22 -0700

That's exactly my understanding.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, July 25, 2011 3:32 PM
To: eman mailing list
Subject: Re: [eman] Two NMS configuring the Power Monitor with two
different Power State Series

OK, I think I understand now.  I have no problem with a given device
being able to support multiple power series simultaneously if it chooses
to do so.

So let me articulate the operational scenario and you tell me if I have
the proper understanding.

3. NMS 1 selects one power series from the available set and uses that
to interact with X.

5. NMS 2 selects a potentially different power series from the available
set and uses that to interact with X.

6. NMS 1 and 2 both continue to interact with X using their respective
choices and these interactions can be interleaved without difficulty.

If a device decides to only support one power series then when queried
it only reports that one.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein