Subject: [OPSAWG] monitoring power state and energy consumption: draft-claise-energy-monitoring-mib-00.txt is a new draft

From: Benoit Claise <[email-masked]>
Date: Thu, 14 Jan 2010 17:06:14 +0100

Dear all,

This new draft is about a MIB module that contains the energy monitoring 
and power states of network elements, addressing the requirements in 
draft-quittek-power-monitoring-requirements-00.txt.
This works has been inspired by an existing MIB module, already 
implemented: CISCO-ENERGYWISE-MIB.my
Please review it. As always, your feedback is welcome.

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Jan 2010 17:26:43 +0100

> Please review it. As always, your feedback is welcome.

My main question is why we can't leverage better the ENTITY-MIBs we
have in place for reporting energy levels etc, extending them were
needed.

- If it is important to report a UUID, we could generalize this as an
  extension of the ENTITY-MIB.

- EnergyMonitorPowerScale seems to achieve the same goals as
  EntitySensorDataScale - why not use the standard TC?

- I suggest to disallow 0 for emIndex so that it can be used as a NULL
  value in cases references are ever made to emTable.

- It is unclear what "non-null" means for emDeviceId since
  EnergyMonitorId has a fixed length of 16 octets.

- The concept of a domain remains unclear to me. It seems that all
  emEntries tagged with the same value in emDomainName form a domain -
  but then what is such a domain good for? There is nothing I can
  really do at a domain level - so this is really just some tagging
  mechanism, no?

- It seems that the notion of a 'domain' in the description of
  EnergyMonitorId is different from the notion of a 'domain' mentioned
  above. If they are the same, the uniqueness constraint and indexing
  scheme probably do not match up.

- Some emEntry attributes seem to duplicate ENTITY-MIB objects.

- Am I correct that negative energy usage applies to power sources?
  If so, please spell this out in the emEnergyUsage description
  clause and the emEnergyUsageNameplate description clause (should
  this not be named emEnergyMaxUsage?).

- emEnergyUsageCategory could have been modelled as a BITS object, but
  that does not really make a big difference.

- emVersion and emEnable seem to overlap with existing ENTITY-MIB /
  ENTITY-STATE-MIB objects

- It needs to be clarified whether changes via SNMP write operations
  are persistent or not

- The security considerations of course need some work at some point
  in time...

- Perhaps "PowerState" is a better name for EnergyMonitorLevel and
  emPowerState might be clearer than emEnergyLevel.

- There was an interesting paper recently pointing out that reporting
  the current state is often not as useful as reporting the time spent
  in each state. This is also mentioned in the requirements ID and I
  think valuable to consider to consider here (so I do not have to do
  aggressive monitoring to find out the distribution of power states a
  component used during the last 24 hours or so).

Bottom line: I believe this is useful input for work on MIB modules
but I consider a solution that is more tightly integrated into the
ENTITY-MIBs, extending them where necessary, a better approach. Is it
really too hard to assume devices implement the basic table of the
ENTITY-MIB? Or is there another reason why extending the ENTITY-MIB
was not considered?

/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: "Kalbfleisch, Carl W" <[email-masked]>
Date: Fri, 15 Jan 2010 10:32:38 -0600

I concur with the suggestion to leverage the ENTITY MIB.

Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juergen Schoenwaelder
Sent: Friday, January 15, 2010 10:27 AM
To: Benoit Claise
Cc: John Parello (jparello); [email-masked]; Brad Schoening
Subject: Re: [OPSAWG] monitoring power state and energy consumption:
draft-claise-energy-monitoring-mib-00.txt is a new draft

/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/>
_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jan 2010 10:24:21 -0800

> I concur with the suggestion to leverage the ENTITY MIB.

I agree (and not because I co-wrote those MIB modules :-)

<tangent>
I have been getting asked lately by YANG module authors
why they can't use SMIv2 T-Cs as data types.  It would
be nice to have a standard for converting a TEXTUAL-CONVENTION
macro to typedef-stmt.
</tangent>

> Carl

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Jan 2010 13:05:18 +0100

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Friday, January 15, 2010 8:24 PM
> To: Kalbfleisch, Carl W
> Subject: Re: [OPSAWG] monitoring power state and energy 
> consumption: draft-claise-energy-monitoring-mib-00.txt is a new draft
> 

+1

> 
> <tangent>
> I have been getting asked lately by YANG module authors why 
> they can't use SMIv2 T-Cs as data types.  It would be nice to 
> have a standard for converting a TEXTUAL-CONVENTION macro to 
> typedef-stmt.
> </tangent>
> 

We discussed this item while debating the roadmap to YANG a couple of
years ago. We decided not to make it part of the first round of work
items then, but now with the YANG charter close to completion maybe it's
time to revisit. I am not sure it's a OPSAWG item. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Jan 2010 09:07:42 -0800

Hi Dan,

> time to revisit. I am not sure it's a OPSAWG item. 

The NETMOD WG has not shown much interest in standardizing
a mapping from some subset of SMIv2 to some subset of YANG.
Instead, a half dozen data types have been selected (e.g.,
Counter32 is now counter32), and reinvented in ietf-yang-types.yang.

The ietf-ipfix-psamp.yang module reinvents ifIndex, ifName,
and entPhysicalIndex.  I suspect the intent is that this
is temporary, since these objects don't even have description-stmts.

The task of building a modular library is not well-suited
to the ad-hoc, almost random WG chartering process.  If we
don't build the foundation before the walls, we will end
up starting over.

There are clearly some SMI types and data structures
that are going to be needed in YANG, as the IPFIX WG has demonstrated.
In fact, almost every new YANG module over the next 5 years
is likely to extend an SMI data structure of some sort.

I don't care what WG deals with this problem, as long
as the work gets done ASAP.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Jan 2010 19:08:08 +0100

Andy,

Speaking as a contributor I strongly resonate with what you say. 

I recommend that you take the issue to the NETMOD WG. Nothing wrong with
this WG and list, but any work item is adopted will need all the NETCONF
and YANG experts to be involved, and will probably end by being done in
NETCONF or NETMOD. 

Dan

> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Sunday, January 17, 2010 7:08 PM
> To: Romascanu, Dan (Dan)
> Cc: Kalbfleisch, Carl W; John Parello (jparello); 
> [email-masked]; Brad Schoening
> Subject: SMI to YANG mapping (was Re: [OPSAWG] monitoring 
> power state and energy consumption: 
> 
> Hi Dan,
> 
> 
> >> <tangent>
> >> I have been getting asked lately by YANG module authors why they 
> >> can't use SMIv2 T-Cs as data types.  It would be nice to have a 
> >> standard for converting a TEXTUAL-CONVENTION macro to typedef-stmt.
> >> </tangent>
> >>
> > 
> > items then, but now with the YANG charter close to completion maybe 
> > it's time to revisit. I am not sure it's a OPSAWG item.
> > 
> 
> The NETMOD WG has not shown much interest in standardizing a 
> mapping from some subset of SMIv2 to some subset of YANG.
> and entPhysicalIndex.  I suspect the intent is that this is 
> temporary, since these objects don't even have description-stmts.
> 
> The task of building a modular library is not well-suited to 
> the ad-hoc, almost random WG chartering process.  If we don't 
> build the foundation before the walls, we will end up starting over.
> 
> There are clearly some SMI types and data structures that are 
> going to be needed in YANG, as the IPFIX WG has demonstrated.
> I don't care what WG deals with this problem, as long as the 
> work gets done ASAP.
> 
> > Dan
> > 
> >>> Carl
> > 
> 
> Andy
>

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 18:13:11 +0900

Hi all,

>   EntitySensorDataScale - why not use the standard TC?

I agree to use the EntitySensorDataScale.
BTW, It seems that the order of EXA and PETA in EntitySensorDataScale is wrong.
Sorry if the issue has already been pointed out.

Minoru Teraoka

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jan 2010 10:43:31 +0100

On Mon, Jan 18, 2010 at 10:13:11AM +0100, [email-masked] wrote:
 
> BTW, It seems that the order of EXA and PETA in
> EntitySensorDataScale is wrong.  Sorry if the issue has already been
> pointed out.

Oops. Not sure what to do about this. The SMIv2 rules allow to change
the labels of enums so we could treat this as an editorial mistake.

OLD

        exa(14),    -- 10^15
        peta(15),   -- 10^18

NEW

        peta(14),   -- 10^15
        exa(15),    -- 10^18

I think an errata should filed <http://www.rfc-editor.org/errata.php>
so that this issue can be tracked. Can you open one?

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 18 Jan 2010 10:49:19 +0100

Opening an errata seems the right thing to do. I think that we can treat
this as editorial, implementations have probably followed the order of
the exponents and done the right thing. 

Dan

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Monday, January 18, 2010 11:44 AM
> To: [email-masked]
> Cc: [email-masked]
> EntitySensorDataScale 
> > is wrong.  Sorry if the issue has already been pointed out.
> 
> Oops. Not sure what to do about this. The SMIv2 rules allow 
> to change the labels of enums so we could treat this as an 
> editorial mistake.
> 
> OLD
> 
>         exa(14),    -- 10^15
>         peta(15),   -- 10^18
> 
> NEW
> 
>         peta(14),   -- 10^15
>         exa(15),    -- 10^18
>

---

From: <[email-masked]>
Date: Mon, 18 Jan 2010 19:20:40 +0900

Hi,

I have submitted a errata report.
It was the first time for me to report the errata.
Please let me know if I did anything wrong.

Minoru

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Monday, January 18, 2010 6:49 PM
> To: Juergen Schoenwaelder; Teraoka, Minoru 
> ([email-masked])
> Cc: [email-masked]
> Subject: RE: [OPSAWG] monitoring power state and energy 
> Opening an errata seems the right thing to do. I think that 
> we can treat this as editorial, implementations have probably 
> followed the order of the exponents and done the right thing. 
> 
> Dan
>  
> 
> to change

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 18 Jan 2010 11:37:48 +0100

You did well, thank you. 

As the Entity WG is close, I will solicit comments to this Errata on
this list before approving it.

Dan

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, January 18, 2010 12:21 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Cc: [email-masked]
> > Opening an errata seems the right thing to do. I think that we can 
> > treat this as editorial, implementations have probably followed the 
> > order of the exponents and done the right thing.
> > 
> > Dan
> >  
> >