Subject: Re: [eman] Feedback regarding the EMAN monitoring

From: Benoit Claise <[email-masked]>
Date: Mon, 05 Dec 2011 17:53:03 +0100

Hiroto-san,

(Mouli, there are some changes for the draft in line)

Thanks for your review.
See inline
> Hi, Benoit
> cc  Mouli
>
> Thank you for providing me with the opportunity to talk with you.
> I enjoyed newcomer's meeting and had a good time with you.
>
> Following are the minutes which we discuss about.
>
> 1,
> Discussion
>    Why the following object is Counter64?
>    ・eoPowerStateEnterCount
It's true that, at first glance, 4294967295, i.e. Counter32, should be 
enough
Any other view?
I reviewed http://www.ietf.org/rfc/rfc4181.txt, and I could not find a 
guideline such as: "always use Counter64, just in case!"
>
> Actions/Decisions
>    Ask Mouli.
>
> 2,
> Discussion
>    How to update eoEnergyIntervalMaxConsumed(periodical).
I found an issue with the draft: the " Figure 2: UML diagram for the 
powerQualityMIB" doesn't contain the eoEnergyParametersTable. For 
example: eoEnergyIntervalMaxConsumed

>    ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
> 　　 Would that be OK?
Yes.
Note that we have two maxima now: eoEnergyIntervalMaxConsumed and 
eoEnergyIntervalMaxProduced

We need to updated the draft
OLD:

eoEnergyParametersIntervalNumber OBJECT-TYPE
             SYNTAX          Integer32
             MAX-ACCESS      read-create
             STATUS          current
             DESCRIPTION
                "The number of intervals maintained in the eoEnergyTable.
                Each interval is characterized by a specific
                eoEnergyIntervalStartTime, used as an index to the table
                eoEnergyTable . Whenever the maximum number of entries is
                reached, the measurement over the new interval replaces
                the oldest measurement , except if the oldest measurement
                were to be the maximum eoEnergyIntervalMax, in which case
                the measurement the measurement over the next oldest
                interval is replaced."
              DEFVAL { 10 }

NEW:
eoEnergyParametersIntervalNumber OBJECT-TYPE
             SYNTAX          Integer32
             MAX-ACCESS      read-create
             STATUS          current
             DESCRIPTION
                "The number of intervals maintained in the eoEnergyTable.
                Each interval is characterized by a specific
                eoEnergyIntervalStartTime, used as an index to the table
                eoEnergyTable . Whenever the maximum number of entries is
                reached, the measurement over the new interval replaces
                the oldest measurement. There is one exception to this rule:
                when the eoEnergyIntervalMaxConsumed and/or eoEnergyIntervalMaxProduced
                are in (one of) the two oldest measurement(s), they are left untouched
                and the next oldest measurement is replaced."
              DEFVAL { 10 }

I believe that the integration of your figures (updated with the two 
maxima) would be a useful addition to the document.
>    ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable
>     such as fig.2-A and fig.2-B?
Yes.
>
>        <condition>
>        ・eoEnergyParametersIntervalMode   : period
>   　  　 ・eoEnergyIntervalStartTime        : see fig.1
>        ・eoPowerIndex                     : 100
>        ・eoEnergyParametersIntervalNumber : 3
>
>
>            |             |             | =========== |
>            |============ |             |             |
>            |             |             |             |
>    　   　　  |             |============ |             | ・・・・・
>            |             |             |             |
>            |<--- L --->  |<--- L --->  |<--- L --->  |
>            |             |             |             |
>           S1            S2            S3             S4
>
>           <fig.1>  Period eoEnergyParametersIntervalMode
>
>
>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     390     |      390
>                100     |      －     |             |        0
>                100     |      －     |             |        0
>         --------------------------------------------------------
>                                    ↓
>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     390     |      390
>                100     |      S2     |     380     |      380
>                100     |      －     |       0     |        0
>         --------------------------------------------------------
>                                    ↓
>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     390     |      390
>                100     |      S2     |     380     |      380
>                100     |      S3     |     420     |      420
>         --------------------------------------------------------
>                                    ↓
>          eoPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S2     |     380     |      380
>                100     |      S3     |     420     |      420
>                100     |      S4     |     490     |      490
>         --------------------------------------------------------
>
>         <fig.2-A>  The oldest measurement were not to be the maximum eoEnergyIntervalMaxConsumed.
>
>
>
>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     490     |      490
>                100     |      －     |       0     |        0
>                100     |      －     |       0     |        0
>         --------------------------------------------------------
>                                    ↓
>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     490     |      490
>                100     |      S2     |     380     |      380
>                100     |      －     |       0     |        0
>         --------------------------------------------------------
>                                    ↓
>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     490     |      490
>                100     |      S2     |     380     |      380
>                100     |      S3     |     420     |      420
>         --------------------------------------------------------
>                                    ↓
>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         --------------------------------------------------------
>                100     |      S1     |     490     |      490
>                100     |      S3     |     420     |      420
>                100     |      S4     |     390     |      390
>         --------------------------------------------------------
>
>         <fig.2-B>  The oldest measurement were to be the maximum eoEnergyIntervalMaxConsumed.
>
> Actions/Decisions
>    ・eoEnergyIntervalMaxConsumed is updated below (fig.2-A,2-B) in case eoEnergyParametersIntervalMode is period,
> 　　 Would that be OK?
>    → Yes
>    ・Does eoEnergyParametersIntervalNumber indicate the number of intervals maintained in eoEnergyTable
>     such as fig.2-A and fig.2-B?
>    → Yes
Good, I'm still consistent with what I said during the newcomer meeting ;-)
>
> 3,
> Discussion
>    How to update eoEnergyIntervalMaxConsumed(total).
> 　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total,
> 　　　Would that be OK?
> 　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　
>    ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?   　
>   　
>        <condition>
>        ・eoEnergyParametersIntervalMode   : total
>   　　   ・eoEnergyIntervalStartTime        : see fig.3
>        ・eoPowerIndex                     : 100
>        ・eoEnergyParametersIntervalNumber : 1
>
>          |                          |
>          |========================= |
>          |                          |
>          |                          |
>          |                          |
>          |<--- Total length --->   |
>          |                          |
>          S1
>
>          <fig.3>  Total eoEnergyParametersIntervalMode
>
>          pmPowerIndex  |  StartTime  | MaxConsumed |  EnergyCons
>         ---------------------------------------------------------
>                100     |      S1     |   11,290    |    11,290
>         ---------------------------------------------------------
>
>          <fig.4>  Updating the eoEnergyIntervalMaxConsumed when Mode is total.
>
> Actions/Decisions
> 　　・eoEnergyIntervalMaxConsumed is updated below (fig.4) in case eoEnergyParametersIntervalMode is total,
> 　　　Would that be OK?
>    → Yes
> 　 ・Does eoEnergyIntervalMaxConsumed have an entry in the eoEnergyTable when eoEnergyIntervalMode is total? 　　
>    → Yes
>    ・Besides, the value of eoEnergyIntervalMaxConsumed equals to that of eoEnergyIntervalEnergyConsumed?
>    → Yes
Still yes, but let's pay attention that we now have 
eoEnergyIntervalMaxConsumed eoEnergyIntervalMaxProduced.
Again, a useful addition to the draft.
>
> 4,
> Discussion
>    MIBObject has a tabel missing.
>    ・"energyObjectMibObjects 3" can be non-existent?
>
>       eoPowerStateTable OBJECT-TYPE
>        ::= { energyObjectMibObjects 2 }
>
>       eoEnergyParametersTable OBJECT-TYPE
>        ::= { energyObjectMibObjects 4 }.
>
>    eoPowerStateEntry has a object missing.
>    ・"eoPowerStateEntry 2" can be non-existent?
>
>       eoPowerStateIndex OBJECT-TYPE
>        ::= { eoPowerStateEntry 1 }
>
>       eoPowerStateMaxPower OBJECT-TYPE
>        ::= { eoPowerStateEntry 3 }
>
> Actions/Decisions
>    Yes, both of them are mistakes.
>    Mouli shall correct those texts.
>
> 5,
> Discussion
>    eoEnergyTable about when Read-Create objects are modified.
>    ・An Object whose syntax is Read-Create such as eoEnergyParametersIntervalLength is changed by snmp manager,
>     eoEnergyTable is reset once?
Found an editorial mistake in

    eoPowerMeasurementCaliber   OBJECT-TYPE
                 SYNTAX          INTEGER  {
                                     unavailable(1) ,
                                     unknown(2),
                                     actual(3) ,
                                     estimated(4),
                                     presumed(5)                    }
                 MAX-ACCESS      read-only
                 STATUS          current
                 DESCRIPTION
                    "This object specifies how the usage value reported by
                    eoPower was obtained:

                    - unavailable(1): Indicates that the usage is not
                    available. In such a case, the eoPower value must be 0
                    For devices that can not measure or report power this
                    option can be used.

    Replace "For" by "for"

> Actions/Decisions
>    maybe yes,
> 　　Confirm to mouli.
I would still say yes, but the document is not clear, so it requires a 
clarification. Good catch.
See

         eoEnergyParametersStatus OBJECT-TYPE
             SYNTAX          RowStatus
             MAX-ACCESS      read-create
             STATUS          current
             DESCRIPTION
               "The status of this row. The eoEnergyParametersStatus is
               used to start or stop energy usage logging. An entry
               status may not be active(1) unless all objects in the
               entry have an appropriate value.  If this object is not
               equal to active(1), all associated usage-data logged into
               the eoEnergyTable will be deleted. The data can be
               destroyed by setting up the eoEnergyParametersStatus to
               destroy(2)."

I read again the RowStatus TC in 
http://www.simpleweb.org/ietf/mibs/modules/IETF/txt/SNMPv2-TC, as 
read-create is always a difficult mattter.
Anyway, the goal is that, one of the parameters need to be changed in 
eoEnergyParametersTable, then eoEnergyParametersStatus must be set to 
"destroy" first.
The only exception might be eoEnergyParametersIntervalNumber, as we 
might want to extend the number while keeping the current values.
Note: we want to specifically mention this in the MIB module.

For reference in this discussion:

ForyoeoEnergyParametersTable
                 eoEnergyParametersIntervalLength     TimeInterval,
                 eoEnergyParametersIntervalNumber     Integer32,
                 eoEnergyParametersIntervalMode       Integer32,
                 eoEnergyParametersIntervalWindow     TimeInterval,
                 eoEnergyParametersSampleRate         Integer32,
                 eoEnergyParametersStatus             RowStatus

>
> 6,
> Discussion
>    Power State about whole chassis.
> 　　・Following case, How do I define Power State of whole chassis?
>
>     - whole chassis includes two line cards.
>     - each of line cards is different Power State, such as high(Power on) and sleep(Power off).
>
> Actions/Decisions
>    It's depends on implementation.

Regards, Benoit (as a contributor)
>
>
> Best regards,
> Hiroto
>
> ---------------------------------
>   Hiroto Ogaki
>   ALAXALA Networks, Corp.
>   E-mail:[email-masked]
>   URL:http://www.alaxala.com
> ---------------------------------
>
>> Hiroto-san,
>>
>> As we discussed, can you please post your feedback on the list.
>>
>> Regards, Benoit.
>>

---

From: <[email-masked]>
Date: Tue, 6 Dec 2011 14:45:44 +0900

Hi all,

There is a point which I would like to confirm.

> I found an issue with the draft: the " Figure 2: UML diagram for the powerQualityMIB" doesn't contain the eoEnergyParametersTable. For example: eoEnergyIntervalMaxConsumed 
> 
> 
> Note that we have two maxima now: eoEnergyIntervalMaxConsumed and eoEnergyIntervalMaxProduced

Does eoEnergyIntervalDiscontinuityTime need to be distinguished
between consuming and producing?  energyNet also?

Best regards,
Minoru

--
Minoru Teraoka
Yokogawa Electric Corporation

---

From: Benoit Claise <[email-masked]>
Date: Tue, 06 Dec 2011 08:33:26 +0100

Hi,
Yes.

one improvement though
OLD:

          eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
             SYNTAX      TimeTicks
             MAX-ACCESS  read-only

             STATUS      current
             DESCRIPTION
               "The value of sysUpTime [RFC3418  <http://tools.ietf.org/html/rfc3418>] on the most recent
               occasion at which any one or more of this entity's energy
               consumption counters suffered a discontinuity. If no such
               discontinuities have occurred since the last re-
               initialization of the local management subsystem, then
               this object contains a zero value."
             ::= { eoEnergyIntervalEntry 9 }

NEW:
          eoEnergyIntervalDiscontinuityTime OBJECT-TYPE
             SYNTAX      TimeTicks
             MAX-ACCESS  read-only
             STATUS      current
             DESCRIPTION
               "The value of sysUpTime [RFC3418  <http://tools.ietf.org/html/rfc3418>] on the most recent
               occasion at which any one or more of this entity's energy
               counters in this table suffered a discontinuity:
               eoEnergyIntervalEnergyConsumed, eoEnergyIntervalEnergyProduced,
               or eoEnergyIntervalEnergyNet. If no such
               discontinuities have occurred since the last re-
               initialization of the local management subsystem, then
               this object contains a zero value."
             ::= { eoEnergyIntervalEntry 9 }

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 6 Dec 2011 01:40:17 -0600

Hi Minoru-san,

eoEnergyIntervalDiscontinuityTime indicates if there was a disruption or re-initialization of NMS.

The Energy measurement values would be reset when there is a disruption in measurement. 
This would be particularly important if the eoEnergyParametersIntervalMode is total (3). Whereas with
eoEnergyParametersIntervalMode Period (1), Sliding (2)  the measurement values would be ok, 

Thinking about this more, I feel that SYNTAX perhaps should be TimeStamp instead of TimeTicks, analogous to 

ifCounterDiscontinuityTime OBJECT-TYPE
           SYNTAX      TimeStamp
         
Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, December 06, 2011 11:16 AM
To: Benoit Claise (bclaise); [email-masked]
Cc: [email-masked]; Mouli Chandramouli (moulchan); [email-masked]
Subject: RE: Feedback regarding the EMAN monitoring

Hi all,

Best regards,
Minoru

---

From: <[email-masked]>
Date: Tue, 6 Dec 2011 18:20:52 +0900

Hi Mouli, Benoit,

I checked rfc2863, and I think the same thought.  The SYNTAX of
eoEnergyIntervalDiscontinuityTime similar to ifCounterDiscontinuityTime
is appropriate.

I must confess the fact that I get the picture to use DiscontinuityTime
at last.

Thanks,
Minoru

> ________________________________________
> From: Mouli Chandramouli (moulchan) [[email-masked]]
> Sent: Tuesday, December 06, 2011 4:40 PM
> To: Teraoka, Minoru ([email-masked]); Benoit Claise (bclaise); [email-masked]
> Cc: [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Thu, 8 Dec 2011 10:34:52 +0900

Hi, Benoit
Cc, Mouli

Thanks for your comment.
See inline,

>guideline such as: "always use Counter64, just in case!"

I agree on your thought.
It's enough for Counter32.
We need to update the draft.

>maxima) would be a useful addition to the document.

Though you agreed on my figure indicated how to update the two maxima,
I've another idea.
I'll send details of my idea later on. 

>>                100     |      −     |             |        0
>>                100     |      −     |             |        0
>>                100     |      −     |       0     |        0
>>                100     |      −     |       0     |        0
>>                100     |      −     |       0     |        0
>>                100     |      −     |       0     |        0

How kind of you to remember.

>eoEnergyParametersTable, then eoEnergyParametersStatus must be set to 

Yes,
it's need to be following procedure.

   1. snmpset parametersStatus.xx destroy
   2. snmpset parametersStatus.xx createAndWait
   3. snmpset parametersIntervalLength.xx 1800
   4. snmpset parametersIntervalNumber.xx 30
   5. snmpset parametersStatus.xx active

>For reference in this discussion:

This exception needs to be mentioned, but it looks difficult to extend the number while keeping the current value.
Any idea ?

>Regards, Benoit (as a contributor)

Regards, Hiroto