Skip to main content

Last Call Review of draft-ietf-opsawg-vmm-mib-02

Request Review of draft-ietf-opsawg-vmm-mib
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-05-18
Requested 2015-05-08
Authors Hirochika Asai , Michael MacFaden , Jürgen Schönwälder , Keiichi Shima , Tina Tsou (Ting ZOU)
I-D last updated 2015-05-15
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Genart Telechat review of -03 by Paul Kyzivat (diff)
Secdir Last Call review of -02 by Christian Huitema (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Opsdir Telechat review of -03 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-ietf-opsawg-vmm-mib by Ops Directorate Assigned
Reviewed revision 02 (document currently at 04)
Result Has issues
Completed 2015-05-15

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of

IETF drafts. Comments that are not addressed in last call may be included in AD

during the IESG review.  Document editors and WG chairs should treat these

just like any other last call comments.

Document Status: Ready with Issues

This is a MIB document – however my review focuses on the perspective of an
operational and manageability review. I assume that a separate RFC 4181 review
is or will be performed.

5706 check list:

A.1.  Operational Considerations

   1.  Has deployment been discussed?  See Section 2.1.

       *  Does the document include a description of how this protocol

          or technology is going to be deployed and managed?

       *  Is the proposed specification deployable?  If not, how could

          it be improved?

       *  Does the solution scale well from the operational and

          management perspective?  Does the proposed approach have any

          scaling issues that could affect usability for large-scale


       *  Are there any coexistence issues?

DR: there is some discussion about deployment, especially in relation to the
read-only vs. write capabilities.

   2.  Has installation and initial setup been discussed?  See

       Section 2.2.

       *  Is the solution sufficiently configurable?

       *  Are configuration parameters clearly identified?

       *  Are configuration parameters normalized?

       *  Does each configuration parameter have a reasonable default


       *  Will configuration be pushed to a device by a configuration

          manager, or pulled by a device from a configuration server?

       *  How will the devices and managers find and authenticate each


DR: no, but I do not believe that there are any special or different problems
than the ones encountered when installing any new SNMP agent.

   3.  Has the migration path been discussed?  See Section 2.3.

       *  Are there any backward compatibility issues?

DR: N/A – this is the first version of this MIB module. Relationship with other
MIB modules is discussed.

   4.  Have the Requirements on other protocols and functional

       components been discussed?  See Section 2.4.

     *  What protocol operations are expected to be performed relative

          to the new protocol or technology, and what protocols and data

          models are expected to be in place or recommended to ensure

          for interoperable management?


   5.  Has the impact on network operation been discussed?  See

       Section 2.5.

       *  Will the new protocol significantly increase traffic load on

          existing networks?

       *  Will the proposed management for the new protocol

          significantly increase traffic load on existing networks?

       *  How will the new protocol impact the behavior of other

          protocols in the network?  Will it impact performance (e.g.,

          jitter) of certain types of applications running in the same


       *  Does the new protocol need supporting services (e.g., DNS or

          Authentication, Authorization, and Accounting - AAA) added to

          an existing network?

DR: the number of notifications issued by the agent may be a problem and the
tuning is quite course. See the more detailed comments.

   6.  Have suggestions for verifying correct operation been discussed?

       See Section 2.6.

       *  How can one test end-to-end connectivity and throughput?

       *  Which metrics are of interest?

       *  Will testing have an impact on the protocol or the network?


   7.  Has management interoperability been discussed?  See Section 3.1.

       *  Is a standard protocol needed for interoperable management?

       *  Is a standard information or data model needed to make

          properties comparable across devices from different vendors?

DR: this is a standard data model, relationship with other MIB modules is

   8.  Are there fault or threshold conditions that should be reported?

       See Section 3.3.

       *  Does specific management information have time utility?

       *  Should the information be reported by notifications?  Polling?

          Event-driven polling?

       *  Is notification throttling discussed?

*  Is there support for saving state that could be used for root

          cause analysis?

DR: standard MIB implementation conditions apply (like system time for time
object). As in any SNMP agent implementations the operators strategy may be
notifications-triggered polling, but this is not explicitly mentioned.
Notification throttling is not applied, and it may be useful – see comment #18

   9.  Is configuration discussed?  See Section 3.4.

       *  Are configuration defaults and default modes of operation


       *  Is there discussion of what information should be preserved

          across reboots of the device or the management system?  Can

          devices realistically preserve this information through hard

          reboots where physical configuration might change (e.g., cards

          might be swapped while a chassis is powered down)?

DR: This is a mostly read-only MIB module. Two objects are defined to
enable/disable notifications, the compliance section does not make them

A.2.  Management Considerations

   Do you anticipate any manageability issues with the specification?

   1.  Is management interoperability discussed?  See Section 3.1.

       *  Will it use centralized or distributed management?

       *  Will it require remote and/or local management applications?

       *  Are textual or graphical user interfaces required?

       *  Is textual or binary format for management information


DR: remote management is possible, this MIB module makes possible interoperable

   2.  Is management information discussed?  See Section 3.2.

       *  What is the minimal set of management (configuration, faults,

          performance monitoring) objects that need to be instrumented

          in order to manage the new protocol?

DR: yes, this is a MIB specification

   3.  Is fault management discussed?  See Section 3.3.

       *  Is Liveness Detection and Monitoring discussed?

       *  Does the solution have failure modes that are difficult to

          diagnose or correct?  Are faults and alarms reported and


DR: Yes

   4.  Is configuration management discussed?  See Section 3.4.

       *  Is protocol state information exposed to the user?  How?  Are

          significant state transitions logged?

DR: Yes, configuration management is discussed, but only read operations are
possible with the exception of enabling and disabling notifications.

5.  Is accounting management discussed?  See Section 3.5.


   6.  Is performance management discussed?  See Section 3.6.

       *  Does the protocol have an impact on network traffic and

          network devices?  Can performance be measured?

       *  Is protocol performance information exposed to the user?

DR: Yes

   7.  Is security management discussed?  See Section 3.7.

       *  Does the specification discuss how to manage aspects of

          security, such as access controls, managing key distribution,


DR: Yes, see detailed comments

A few more detailed comments:


Page 5: s/the MIB objects are managed at a hypervisor/ the MIB objects are
managed at the hypervisor/


Page 6: s/the relationship between other MIB modules/ s/the relationship with
other MIB modules/


Page 8: figure 2 – at the top did you mean ‘Notation’ rather than


Same – in general this figure does not really help. It is not clear how are the
Blocked and Crashed states linked to the rest. I would at least add the numbers
of the states in the VirtualMachineOperState TC


Page 9: The statement about the MIB module providing writeable objects that can
be used for non-persistent changes like changing memory allocation or CPU
allocation seems to be a leftover from previous versions
 – in any case it is not true any longer for this version of the MIB module.


I frankly do not know if the OID tree structure that spreads in pages 9 to 11
is useful at all. Who needs it? And if anybody needs this, it can be obtained
from any MIB tool. I believe that a short list of the
 MIB groups and tables and a few words about what each of these does is


Page 12: I find the second paragraph in section 5 confusing – maybe it’s a
language issue. The last sentence for example does not makes sense (what does
‘the objects of this information’ mean?)


Same about the 4


 paragraph in the same section and page. What does the first sentence mean?
 (‘the objects … are not also included’)


Page 15:  the explanation of the destroy(5) value in the
VirtualMachineAdminState TC may confuse. We do not allow changing VM admin
states by write operations. Of course, an agent implementing this MIB module may
 read this state and reflect it in an object that uses this SYNTAX. I believe
 that some text about this usage of the TC needs to be added.


Page 20: is there any reason that the TC VirtualMachineStorageAccess has no
‘unknown’ enumeration defined?


Page 20-21: Why is the VirtualMachineStorageType limited to two media types
only? Would not an IANA-administered TC be more appropriate here?


Page 24: It is not clear to me what is an ‘administered region’ mentioned in
the DESCRIPTION clause of the vmUUID object


Page 25: why ‘power’ in the DESCRIPTION of the vmAdminState?


Page 26: it looks like the intent of the vmMemUnit is to use bytes as unit of
expressing memory size – this should be explicitly mentioned


Page 33: same comment relative to vmStorageSizeUnit


Page 34-35: I have a big question mark about how the vmStorageReadLatency and
vmStorageWriteLatency objects need to be used. First the usage of the Counter64
syntax seems odd as these objects do not count anything
 and their increase is not unitary. Second I do not know how to interpret them.
 What does say a reading of ‘a million’ or of ‘a billion’ mean? It really makes
 no sense if not interpreted in conjunction with the number of respective I/O
 operations, media type, etc. I guess that the implementation of these objects
 is not trivial and probably requires HW support taking into consideration the
 microseconds resolution. At a minimum I guess that some text recommending to
 the operators how they are supposed to be used is needed.


I am concerned that the current way of defining the notifications switches is
too course. Hypervisors may have many VMs in charge, and if each generates one
notification per each state changes the numbers can become
 big even in normal operation. Maybe some throttling mechanism would be useful.
 Or maybe a couple of more switches that allow to enable only ‘critical’
 notifications (e.g. vmCrashed).


The Security Considerations section does not include a description of the
security hazards of mis-configuration of the writeable objects (danger of
flooding the network with unwanted notifications)

Thanks and Regards,