Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 11 Oct 2012 12:04:02 +0000

Hello Hiroto, 

Regarding your question - eoEnergyDiscontinuityTime - is defined so that it can be useful to help in understanding if any of the energy meters in the device had a discontinuity during the last window.  

Case 1 - if NMS had rebooted is not an issue; the historical data would have been stored in the disk
Case 2-  if the table is destroyed; the meters would start afresh 
Case 3 - when the meters wrap around is time of discontinuity of the energy meter reading 

This is object is quite similar to 	ifCounterDiscontinuityTime . 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 06, 2012 6:56 AM
To: Mouli Chandramouli (moulchan); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; John Parello (jparello)
Subject: Re:Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

Hi, Mouli

Thank you for updating your draft.

Now, we have a problem implementing EMAN monitoring MIB. 
In your draft, eoEnergyDiscontinuityTime is defined as the value of SysUpTime on the most recent occasion
at which one or  more of this entity's energy consumption counters suffered a discontinuity. 
But, we are confused which following case is applied to eoEnergyDiscontinuityTime.

1. sysUpTime at which one of the energy consumption counters is deleted 
   because network management portion of the system is re-initialized.

2. sysUpTime at which eoEnergyTable is deleted by setting up the eoEnergyParametersStatus to 
   destroy(1) or notInService(2).

3. sysUpTime at which one of the energy consumption counters is wrapped around.

4. other

Please let us know and add to the document.

         eoEnergyDiscontinuityTime OBJECT-TYPE
            SYNTAX       TimeStamp
            MAX-ACCESS  read-only
            STATUS      current
            DESCRIPTION
     
              "The value of sysUpTime [RFC3418] on the most recent
              occasion at which any one or more of this entity's energy
              counters in this table suffered a discontinuity:
              eoEnergyConsumed, eoEnergyProduced or eoEnergyNet. If no
              such discontinuities have occurred since the last re-
              initialization of the local management subsystem, then
              this object contains a zero value."
            ::= { eoEnergyEntry 9 }

Best regards,
Hiroto
--
Hiroto Ogaki
Alaxala Networks Corp.

>Hello all, 
>
>An updated draft of the Power and Energy Monitoring MIB has been submitted. 
>
>The modifications in this version are: 
>
> -  the use of eoMeterCapabilities object which can be useful to quickly infer the capabilities of an "energy object".  
> -  closing the open issues that were discussed at IETF EMAN WG 
> -  terminology definitions deferred to EMAN-FRAMEWORK 
>
>Please let us know if you have questions. 
>
>Thanks
>Brad, Juergen, Thomas, Benoit and Mouli
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
>Sent: Wednesday, July 11, 2012 2:27 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Energy Management Working Group of the IETF.
>
>	Title           : Power and Energy Monitoring MIB
>	Author(s)       : Mouli Chandramouli
>                          Brad Schoening
>                          Juergen Quittek
>                          Thomas Dietz
>                          Benoit Claise
>	Filename        : draft-ietf-eman-energy-monitoring-mib-03.txt
>	Pages           : 81
>	Date            : 2012-07-11
>
>Abstract:
>        This document defines a subset of the Management Information
>        Base (MIB) for power and energy monitoring of devices.
>
>     
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-eman-energy-monitoring-mib
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03
>
>A diff from previous version is available at:
>http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-energy-monitoring-mib-03
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman
>_______________________________________________
>eman mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eman
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 12 Oct 2012 08:42:35 +0000

Hello Minoru,

I presume you can use getnext in the table eoEnergyTable to obtain the values of interest - eoEnergyConsumed, eoEnergyProduced ,  ... 

Suppose you did getnext of the table eoEnergyEntry Table    

- getnext (....5.1.1) - you would get the OID and the value of eoEnergyConsumed. 
  The OID would have eoEnergyParametersIndex and eoEnergyCollectionStartTime and eoEnergyCollectionStartTime is not accessible. 
  
Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 03, 2012 3:45 AM
To: Mouli Chandramouli (moulchan); [email-masked]
Subject: RE: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

Hi Mouli,

We are trying to implement EMAN monitoring MIB and are having difficulty.
In eoEnergyTable, there are two indices, eoEnergyParametersIndex and
eoEnergyCollectionStartTime.  The indices are needed to show which
parameters and when it started and ended.  At present, syntax of
eoEnergyCollectionStartTime is TimeTicks.  In this case, in order for NMS
to acquire information, it is necessary to guess the value of the index.
Although I am not an expert in MIB, I think that certain regularity is
required for the index.

        eoEnergyTable OBJECT-TYPE
            SYNTAX          SEQUENCE OF EoEnergyEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "This table lists Energy Object energy measurements.
               Entries in this table are only created if the
               corresponding value of object eoPowerMeasurementCaliber
               is active(2), i.e., if the power is actually metered."
            ::= { energyObjectMibObjects 5   }

        eoEnergyEntry OBJECT-TYPE
            SYNTAX          EoEnergyEntry
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
                "An entry describing energy measurements."
            INDEX  { eoEnergyParametersIndex,
        eoEnergyCollectionStartTime }
            ::= { eoEnergyTable 1 }

        EoEnergyEntry ::= SEQUENCE {
             eoEnergyCollectionStartTime       TimeTicks,
             eoEnergyConsumed                  Integer32,
             eoEnergyProduced                  Integer32,
             eoEnergyNet                       Integer32,
             eoEnergyUnitMultiplier            UnitMultiplier,
             eoEnergyAccuracy                  Integer32,
             eoEnergyMaxConsumed               Integer32,
             eoEnergyMaxProduced               Integer32,
             eoEnergyDiscontinuityTime         TimeStamp
        }

        eoEnergyCollectionStartTime OBJECT-TYPE
            SYNTAX          TimeTicks
            UNITS           "hundredths of seconds"
            MAX-ACCESS      not-accessible
            STATUS          current
            DESCRIPTION
               "The time (in hundredths of a second) since the
               network management portion of the system was last
               re-initialized, as specified in the sysUpTime [RFC3418].
               This object is useful for reference of interval periods
               for which the energy is measured."
            ::= { eoEnergyEntry 1 }

Best regards,
Minoru
--
Minoru Teraoka
Yokogawa Electric Corporation

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mouli Chandramouli (moulchan) [[email-masked]]
Sent: Wednesday, July 11, 2012 6:04 PM
To: [email-masked]
Subject: Re: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

Hello all,

Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 11, 2012 2:27 PM
To: [email-masked]
Cc: [email-masked]
Subject: [eman] I-D Action: draft-ietf-eman-energy-monitoring-mib-03.txt

Abstract:

-----
CONFIDENTIAL: This e-mail may contain information that is confidential or otherwise protected from disclosure and intended only for the party to whom it is addressed. If you are not the intended recipient, please notify the sender by return and delete this e-mail. You are hereby formally advised that any unauthorized use, disclosure or copying of this email is strictly prohibited and may be unlawful.

---

From: <[email-masked]>
Date: Thu, 25 Oct 2012 17:49:43 +0900

Hello Mouli,

Thank you for your comments.  I understood the operation of the table.
By the way, I'm concerned about using eoEnergyCollectionStartTime
(SYNTAX TimeTicks) as an index of eoEnergyTable.
Description of the eoEnergyParametersIntervalNumber object says that
when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one of)
the two oldest measurement(s), they are left untouched and the next
oldest measurement is replaced.  When sysUpTime wraps, it may be
possible that a value of eoEnergyCollectionStartTime repeats.
I'm sorry if I have not been clear.

Best regards,
Minoru

> From: Mouli Chandramouli (moulchan) [mailto:[email-masked]]
> Sent: Friday, October 12, 2012 5:43 PM
> To: Teraoka, Minoru ([email-masked]); [email-masked]
> Subject: RE: [eman] I-D Action:
> draft-ietf-eman-energy-monitoring-mib-03.txt
>
> Hello Minoru,
>
> I presume you can use getnext in the table eoEnergyTable to obtain the values
> of interest - eoEnergyConsumed, eoEnergyProduced ,  ...
>
>   The OID would have eoEnergyParametersIndex and
> eoEnergyCollectionStartTime and eoEnergyCollectionStartTime is not
> accessible.
>
> Thanks
> Mouli
>
> Subject: RE: [eman] I-D Action:
> draft-ietf-eman-energy-monitoring-mib-03.txt
>
> Hi Mouli,
>
> From: [email-masked] [[email-masked]] On Behalf Of Mouli
> Chandramouli (moulchan) [[email-masked]]
> Subject: Re: [eman] I-D Action:
> draft-ietf-eman-energy-monitoring-mib-03.txt
>
> Hello all,
>
>  -  the use of eoMeterCapabilities object which can be useful to quickly
> infer the capabilities of an "energy object".
> CONFIDENTIAL: This e-mail may contain information that is confidential or
> otherwise protected from disclosure and intended only for the party to whom
> it is addressed. If you are not the intended recipient, please notify the
> sender by return and delete this e-mail. You are hereby formally advised
> that any unauthorized use, disclosure or copying of this email is strictly
> prohibited and may be unlawful.

-----

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Oct 2012 10:56:16 +0200

> I'm sorry if I have not been clear.

RFC 2578:

7.1.8.  TimeTicks

   The TimeTicks type represents a non-negative integer which represents
   the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
   between two epochs.  When objects are defined which use this ASN.1
   type, the description of the object identifies both of the reference
   epochs.

   For example, [3] defines the TimeStamp textual convention which is
   based on the TimeTicks type.  With a TimeStamp, the first reference
   epoch is defined as the time when sysUpTime [5] was zero, and the
   second reference epoch is defined as the current value of sysUpTime.

Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is
but TimeTicks is not.

/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, 25 Oct 2012 19:25:26 +0900

Hello Juergen,

I see I did not understand correctly about TimeTicks.
In EoEnergyCollectionStartTime, it begins from 0 at the time of an
observation start.  What I just wanted to say is that if there is an entry
that updated maximum 16 months ago in the table, old and new index may exist.
Is it too strict?

Best regards,
Minoru

> From: Juergen Schoenwaelder
> [mailto:[email-masked]]
> Sent: Thursday, October 25, 2012 5:56 PM
> To: Teraoka, Minoru ([email-masked])
> Cc: [email-masked]; [email-masked]
> > when the eoEnergyMaxConsumed and/or eoEnergyMaxProduced are in (one
> > of) the two oldest measurement(s), they are left untouched and the
> > next oldest measurement is replaced.  When sysUpTime wraps, it may be
> Note that TimeTicks itself is not linked to sysUpTime. TimeStamp is but
> TimeTicks is not.
>
> /js
>
> --

-----

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 25 Oct 2012 12:53:08 +0200

My point here was that TimeTicks does not imply sysUpTime. I did not
look at the object in question. Now that I do that, I read:

This really seems to be a TimeStamp object. I do agree that using
sysUpTime as an epoch needs to be carefully thought through since any
discontinuity that resets sysUpTime makes the value of this object
meaningless. I am also not sure I understand the meaning of "for
reference of interval periods".

/js