Subject: [eman] review of draft-ietf-eman-energy-aware-mib-04 (MIB structure)

From: Juergen Quittek <[email-masked]>
Date: Thu, 8 Mar 2012 11:05:58 +0000

Dear all,

Here is a comment on the structure of the ENERGY-AWARE-MIB module,
particularly on Sections 5.4 and 5.5 of
draft-ietf-eman-energy-aware-mib-04.

The current structure looks like the following:

        +- eoTable(2)
           +- eoEntry(1) [entPhysicalIndex]
           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
           |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
           |  +-- rwn SnmpAdminString              eoDomainName(4)
           |  +-- rwn SnmpAdminString              eoRoleDescription(5)
           |  +-- rwn MacAddress                   eoMgmtMacAddress(6)
           |  +-- r-n eoMgmtAddressType            eoMgmtAddressType(7)
           |  +-- r-n InetAddress                  eoMgmtAddress(8)
           |  +-- r-n SnmpAdminString              eoMgmtDNSName(9)
           |  +-- rwn SnmpAdminString              eoAlternateKey(10)
           |  +-- rwn EnergyObjectKeywordList      eoKeywords(11)
           |  +-- rwn Integer32                    eoImportance(12)
           |  +-- r-n INTEGER                      eoPowerCategory(13)
           |  +-- r-n OCTET STRING                 eoMeteredBy(14)
           |  +-- r-n OCTET STRING                 eoPoweredBy(15)
           |  +-- r-n OCTET STRING                 eoDependentOf(16)
           |  +-- r-n OCTET STRING                 eoAggregatedBy(17)
           |  +-- r-n OCTET STRING                 eoAggregatedBy(18)
           |  +-- r-n OCTET STRING                 eoChildrenList(19)
           | 
         
        +- eoProxyTable(3)
           | 
           +- eoProxyEntry (1)[eoProxyChild, eoProxyParentUUID]
           |  |  
           |  +-- --n PhysicalIndex           eoProxyChild(1)
           |  +-- --n OCTET STRING            eoProxyParentUUID(2)
           |  +-- r-n BITS                    eoProxyAbilities(3)

Almost half of it is dealing with the relations between EOs:
eoMeteredBy(14), eoPoweredBy(15), eoDependentOf(16),
eoAggregatedBy(17), eoAggregatedBy(18), eoChildrenList(19),
eoProxyTable(3), eoProxyChild(1), eoProxyParentUUID(2),
eoProxyAbilities(3).

There are several issues that I don't like here:

1. Using whitespace-separated list for the content of
   eoMeteredBy(14), eoPoweredBy(15), eoDependentOf(16),
   eoAggregatedBy(17), eoAggregatedBy(18), eoChildrenList(19).
   Whitespace separation is error-prone, particularly for
   insert and remove operations and definitely not a preferred
   methods for representing lists of values in MIB modules.
   Tables would be much preferable.
2. Modelling relationships is asymmetric.  For children, there
   is a different list (eoMeteredBy, ... eoAggregatedBy) for
   each kind of realtionship.  For parents, there is just a single
   whitespace-separated list of all children eoChildrenList(19)
   independent of the relationship type.  If I want to find out
   which relationship type a parent has for a child, then I need to
   go to the child and ask it about its relationship to the parent.
3. While all other relationships (see 1. and 2.) are provided as
   whitespace-separated lists, the proxy relationship is provided
   by a separate table.  This is a cumbersome mixture of methods
   and will make access to this information more difficult than
   a single method.  By mixing both methods, we have the worst
   from both sides: hard-to-handle whitespace-separated list and
   SMI table overhead.

I propose a different structure using just a single method, reducing
the number of objects, providing full information for parents and
children and treating child and parent in the same symmetric way.

My proposal is to 
  - remove all whitespace-separated elements from the eoTable
    (eoMeteredBy, ..., eoAggregatedBy,eoChildrenList) and to
  - extend and rename the eoProxyTable such that it fully covers
    all kinds of relationships for parents and for children.
This is illustrated by the following object tree:
  +- eoRelationTable(3)
     | 
     +- eoRelationEntry (1)[eoPeerUUID]
        |  
        +-- --n OCTET STRING            eoPeerUUID(1)
        +-- r-n BITS                    eoRelationships(2)
This table is even simpler than the one in the current draft.
eoPeerUUID identified the other peer of any kind of relationship.
The only magic in here is the eoRelationships. The bit field
has a first flag for the role(1) in the relationship indicating
either provider/parent (bit set) or receiver/child (bit not set).
This guarantees that we can report symmetrically on parents and
children.  The following bit fields would represent different
relaionships with one bit for each of {meteredBy(2), poweredBy(3),
dependentOf(4), aggregatedBy(5), aggregatedBy(6)}. Finally, three
bits from eoProxyAbilities are adopted indicating kinds of proxy
relationships: report(7), configuration(8), wakeonlan(9).
All bits can be set independent of each other.  This way a single
table row (containing just a single element eoRelationships)
indicates ALL existing relationships to a given other EO.
And this includes relations to patrents and children.

The resulting MIB tree for the entire module would reduce to

        +- eoTable(2)
           +- eoEntry(1) [entPhysicalIndex]
           |  +-- r-n PethPsePortIndexOrZero       eoEthPortIndex(1)
           |  +-- r-n PethPsePortGroupIndexOrZero  eoEthPortGrpIndex(2)
           |  +-- r-n LldpPortNumberOrZero         eoLldpPortNumber(3)
           |  +-- rwn SnmpAdminString              eoDomainName(4)
           |  +-- rwn SnmpAdminString              eoRoleDescription(5)
           |  +-- rwn MacAddress                   eoMgmtMacAddress(6)
           |  +-- r-n eoMgmtAddressType            eoMgmtAddressType(7)
           |  +-- r-n InetAddress                  eoMgmtAddress(8)
           |  +-- r-n SnmpAdminString              eoMgmtDNSName(9)
           |  +-- rwn SnmpAdminString              eoAlternateKey(10)
           |  +-- rwn EnergyObjectKeywordList      eoKeywords(11)
           |  +-- rwn Integer32                    eoImportance(12)
           |  +-- r-n INTEGER                      eoPowerCategory(13)
         
        +- eoRelationTable(3)
           | 
           +- eoRelationEntry (1)[eoPeerUUID]
           |  |  
           |  +-- --n PhysicalIndex           eoPeerUUID(1)
           |  +-- r-n BITS                    eoRelationships(2)

Thanks,
    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Thu, 8 Mar 2012 06:48:33 -0600

Hello Juergen,

Thanks for the email.  The suggestion of partitioning in sub-tables is
useful -  identity, context and relationships. 

I can see that the proposed table would work for 1-1 bijective
relationships.

Either there should be a mechanism to identify the "relevant eoPeerUUIDs
for a given UUID  or this table has to be a large table. 

+- eoRelationTable(3)
           | 
           +- eoRelationEntry (1)[eoPeerUUID] ----> should this eoUUID ?
           |  |  
           |  +-- --n PhysicalIndex           eoPeerUUID(1)
           |  +-- r-n BITS                    eoRelationships(2)

Consider the example, 

Switch  ----->  Phone  ------> PC   <-----(meter)------------ PDU 
UUID 100        UUID 101      UUID 201     UUID 202         UUID 200

Phone is powered by the switch and the PC is powered from a PDU

Phone has a poweredBy, controlledBy, meteredBy the switch.  

PC is poweredBy the PDU
PC is controlledBy by switch 
PC is meteredBy the meter  

How can this table help in this setting. 

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Thursday, March 08, 2012 4:36 PM
To: eman mailing list
Subject: [eman] review of draft-ietf-eman-energy-aware-mib-04 (MIB
structure)

Dear all,

YCM>>> Either there should be a mechanism to identify the "relavant
eoPeerUUIDs for a given UUID.  or this table has to be large table. 

        +- eoRelationTable(3)
           | 

Thanks,
    Juergen

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

---

From: Ira McDonald <[email-masked]>
Date: Thu, 8 Mar 2012 11:59:36 -0500

Hi,

All of those relationship objects should be of datatype
SnmpAdminString (UTF-8 superset of DisplayString
US-ASCII).

If they're names, the names should be UTF-8 and w/
display hints (from the SnmpAdminString datatype).

If they're URIs, then SnmpAdminString future-proofs
them from upgrades to allow unescaped non-ASCII
characters in the present ASCII-only generic URI
syntax.

Using OCTET STRING will result in poor display of
the contents by management stations (as hex octets).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2012 18:14:08 +0100

> the contents by management stations (as hex octets).

There is also the URI-TC-MIB defined in RFC 5017. The TCs use an ASCII
repertoire for the URIs, following STD 66. I am not sure were things
are wrt. internationalized URIs but in practice (whether we like it or
not) it seems we are increasingly faced with percent encodings (and it
seems this is also what IRIs [RFC3987] suggested). So I am not sure
how much future proofing we get by using SnmpAdminString.

/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: Juergen Quittek <[email-masked]>
Date: Thu, 8 Mar 2012 19:31:39 +0000

Hi Mouli,

First I apologize for a mistake I made.
I accidentally dropped an index in the table I suggested. It should read

  +- eoRelationTable(3)
     |
     +- eoRelationEntry (1)[entPhysicalIndex,eoPeerUUID]
     |  
     +-- --n OCTET STRING            eoPeerUUID(1)
     +-- r-n BITS                    eoRelationships(2)

Missing was the entPhysicalIndex of the EO on which relationships are
reported

>I can see that the proposed table would work for 1-1 bijective

With fixing my mistake, the table can be used for any relationship of the
EO identified by entPhysicalIndex.  You can list all parent and child
relationships
of this EO. Peering EOs are identified by their UUID eoPeerUUID.

>How can this table help in this setting.

Let's assume the values of entPhysicalIndex are the following:
Switch 2
Phone  4
PC 5
Meter 7
PDU 9

And the bits in eoRelationships are defined as follows:
  - role(1) (1=provider/parent, 0=receiver/child)
  - meteredBy(2) (1=there is such a relation)
  - poweredBy(3) (1=there is such a relation)
  - controlledBy(4) (1=there is such a relation)
  - aggregatedBy(5) (1=there is such a relation)
  - proxy report(6) (1=there is such a relation)
  - proxy configuration(7) (1=there is such a relation)
  - proxy wakeonlan(8) (1=there is such a relation)

Then the rows for the PC would look like the following:
2 | 101 | 11110000 : switch meters, powers, controls phone
2 | 201 | 10010000 : switch controls PC
4 | 100 | 01110000 : phone is metered, powered, controlled by switch
5 | 100 | 00010000 : the PC is controlled by switch
5 | 200 | 00100000 : the PC is powered by PDU
5  |  202  | 01000000  : the PC is metered by the meter

7  |  201  | 11000000 : meter meters PC
9  |  201  |  00100000 : PDU powers PC

Does this make it clearer?

Regards,
    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 Mar 2012 11:12:39 +0100

Hi Juergen,

We thought about indexing by UUID.
This is a 45 bytes string. So a very long OID. We were trying to avoid 
that...
I remember playing with the EXPRESSION-MIB (RFC2982) a long time ago:

     INDEX       { expExpressionOwner, expExpressionName }
     ...
     expExpressionOwner           SnmpAdminString,
     expExpressionName            SnmpAdminString,

And that was really a pain to troubleshoot...

Background info: http://tools.ietf.org/html/rfc2578#section-7.7

(2)  string-valued, fixed-length strings (or variable-length preceded by
      the IMPLIED keyword):  `n' sub-identifiers, where `n' is the length
      of the string (each octet of the string is encoded in a separate
      sub-identifier);

(3)  string-valued, variable-length strings (not preceded by the IMPLIED
      keyword):  `n+1' sub-identifiers, where `n' is the length of the
      string (the first sub-identifier is `n' itself, following this,
      each octet of the string is encoded in a separate sub-identifier);

So, MIB experts, is this an issue or not?
I searched through http://tools.ietf.org/html/rfc4181 but could not find 
the answer.

Regards, Benoit.
> On 08.03.12 13:48, "Mouli Chandramouli (moulchan)"<[email-masked]>
> wrote:
>
>> Hello Juergen,
>>
>> Switch  ----->   Phone  ------>  PC<-----(meter)------------ PDU

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 Mar 2012 11:23:00 +0100

Hi Juergen,
>     go to the child and ask it about its relationship to the parent.
This was the open issue discussed at the last IETF meeting: 
http://www.ietf.org/proceedings/82/slides/eman-1.pdf
Do we need eoMeteringChildrenList, eoPoweringChildrenList, 
eoDependentChildrenList, eoAggregatingChildrenList, eoProxyingChildrenList?
Sure, we could solve that one.

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2012 11:25:06 +0100

On Fri, Mar 09, 2012 at 11:12:39AM +0100, Benoit Claise wrote:
> This is a 45 bytes string. So a very long OID. We were trying to
> avoid that...

To be a bit more precise, a UUID is 128 bits (16 octets). The ASCII
rendering of it is 36 octets and the URN rendering makes it 45 octets.

> And that was really a pain to troubleshoot...

Because of what? Was it a pain to use names or was it a pain to
implement the name indexing?

> So, MIB experts, is this an issue or not?

It remains unclear what you think the issue is. Perhaps you are
referring to the length prefixed sort order? 

> I searched through http://tools.ietf.org/html/rfc4181 but could not
> find the answer.

I guess it is a design decision whether to use integer indexes (and to
think careful about there persistency properties), UUIDs in some fixed
size compact binary format (perhaps rendered by DISPLAY-HINTS), or a
string based UUID representation or even a URN based UUID
representation. Its a tradeoff design decision RFC 4181 likely can't
help with.

/js

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 Mar 2012 11:43:35 +0100

Hi Juergen,
> rendering of it is 36 octets and the URN rendering makes it 45 octets.
Thanks for the clarification.
> implement the name indexing?
As TAC engineer, it was a pain to troubleshoot the (OID,  name) mappings 
with snmpwalk
It also lead to a few bugs in the implementation.
All in all, that MIB module was deemed too difficult, and its use never 
took off.
Ok, let's be fair, it was not the only reason why it never took off but 
let's not restart this discussion here.
> referring to the length prefixed sort order?
The length of the OID ,because the index was a string
The fact that you have to extract an UUID out of the OID and do a 
conversion to get the string.
Thanks

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Mar 2012 12:41:46 +0100

> conversion to get the string.

Thats a tool issue. Tools that only provide you an encoded OID just
have not caught up with SMIv2.

/js

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 9 Mar 2012 12:36:47 +0000

Hi Benoit,

>Sure, we could solve that one.

The alternative I proposed (with the fix I sent yesterday) will give you
all this without adding any new MIB objects.

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Fri, 09 Mar 2012 14:04:42 +0100

Hi Juergen,
> Hi Benoit,
>
> On 09.03.12 11:23, "Benoit Claise"<[email-masked]>  wrote:
>
>> Hi Juergen,
>>> Dear all,
>>>
No disagreement.
So far, nobody commented on the open issue (btw, also listed in the 
draft itself), i.e. whether we needed to model children list.
So that's good that you did comment.

Regards, Benoit.

---

From: Juergen Quittek <[email-masked]>
Date: Fri, 9 Mar 2012 15:48:50 +0000

Hi Benoit,

>We thought about indexing by UUID.

You did not just think about it.  You even use it already for
indexing the eoProxyTable in the ENERGY-AWARE-MIB.
And that's where I took it from.
I just reduced this table by one object.

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 14 Mar 2012 07:47:34 -0500

Hello Juergen,

Thanks for the proposal for the modified design; which simplifies the
MIB OID. 

We need more time to evaluate this proposal and have listed this an open
issue. 

Thanks
Mouli

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Friday, March 09, 2012 1:02 AM
To: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] review of draft-ietf-eman-energy-aware-mib-04 (MIB
structure)

Hi Mouli,

  +- eoRelationTable(3)
     |

>I can see that the proposed table would work for 1-1 bijective

With fixing my mistake, the table can be used for any relationship of
the
EO identified by entPhysicalIndex.  You can list all parent and child
relationships
of this EO. Peering EOs are identified by their UUID eoPeerUUID.

Regards,
    Juergen