Subject: [OPSAWG] Fwd: New Version Notification for draft-asai-vmm-mib-05.txt

From: Hirochika Asai <[email-masked]>
Date: Mon, 14 Oct 2013 12:05:13 +0900

Hi folks,

Thanks to comments from the mailing list, we've uploaded new version
of our I-D: http://tools.ietf.org/html/draft-asai-vmm-mib-05

We would like to submit our I-D as a working group draft soon and
have a discussion in the next IETF as a working group draft.
Chairs, could you please poll for adoption as a working group item
on the mailing list?

I've already noticed an error: RFC4133 must be RFC6933.  Please let
us know if you find any other errors.  These errors will be
corrected in the next version (the first version for working group
draft if adopted).

Here, I summarize the updates from the previous version.

* According to the thread Joe-1
Modified a paragraph as follows:

The design of this MIB module has been derived from enterprise
specific MIB modules, namely a MIB module for managing guests of the
Xen hypervisor, a MIB module for managing virtual machines controlled
by the VMware hypervisor, and a MIB module using the libvirt
programming interface to access different hypervisors.
+ However, this MIB module attempts to generalize
+ the managed objects to support other hypervisors.

* According to the thread Joe-2
Added description of an example of hypervisor-specific case
using ENTITY-MIB, but not modified the MIB definition.

* According to the thread Joe-3
 vmAutoStart --> read-only
 vmCur* --> read-write
 vm*Mem vm*Cpu --> description w/ MUST NOT: "Changes to these objects MUST NOT persist"

* According to the thread Joe-5
For the network portion of the hypervisor, added a note on a case
equipping virtual switches on the hypervisor as follows:
   The objects related to virtual switches
   are not also included in this MIB module
   though virtual switches shall be placed on a hypervisor.
   This is because the virtual network interfaces are
   the lowest abstraction of network resources allocated
   to a virtual machine.
   Instead of including the objects related to virtual switches,
   for example, <xref target="RFC4188">BRIDGE-MIB</xref>
   and <xref target="RFC4363">Q-BRIDGE-MIB</xref> could be used.

* According to the thread Joe-7
Added Notifications for shuttingDown, resuming suspending, migrating, and blocked
# I think we still need discussion at this point.

* Others
Modified VirtualMachineOperState to be more clear.
Revised the description of VirtualMachine*Index.
Fixed some typos.

Best regards,
Hirochika

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-asai-vmm-mib-05.txt
> Date: October 13, 2013 3:19:14 PM GMT+09:00
> To: Yuji Sekiya <[email-masked]>, Cathy Zhou <[email-masked]>, Tina Tsou <[email-masked]>, Keiichi Shima <[email-masked]>, Juergen Schoenwaelder <[email-masked]>, Michael MacFaden <[email-masked]>, Hirochika Asai <[email-masked]>, Hiroshi Esaki <[email-masked]>
> 
> 
> A new version of I-D, draft-asai-vmm-mib-05.txt
> has been successfully submitted by Hirochika Asai and posted to the
> IETF repository.
> 
> Filename:	 draft-asai-vmm-mib
> Revision:	 05
> Title:		 Management Information Base for Virtual Machines Controlled by a Hypervisor
> Creation date:	 2013-10-13
> Group:		 Individual Submission
> Number of pages: 56
> URL:             http://www.ietf.org/internet-drafts/draft-asai-vmm-mib-05.txt
> Status:          http://datatracker.ietf.org/doc/draft-asai-vmm-mib
> Htmlized:        http://tools.ietf.org/html/draft-asai-vmm-mib-05
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-asai-vmm-mib-05
> 
> Abstract:
>   This document defines a portion of the Management Information Base
>   (MIB) for use with network management protocols in the Internet
>   community.  In particular, this specifies objects for managing
>   virtual machines controlled by a hypervisor (a.k.a. virtual machine
>   monitor).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo

---

From: Michael MacFaden <[email-masked]>
Date: Mon, 14 Oct 2013 06:47:44 -0700 (PDT)

>   and <xref target="RFC4363">Q-BRIDGE-MIB</xref> could be used.

Just checking, you meant for this to be an informative reference right?
I'd prefer if we change the example mib module to the IEEE mib module.
RFC 4188 is the last of its kind. IETF gave this mib module and most layer 2 related mibs
over to IEEE. ESXi for example implements IEEE8021-Q-BRIDGE-MIB, REVISION 200810150000Z.

Thanks,
Mike MacFaden

---

From: Hirochika Asai <[email-masked]>
Date: Tue, 15 Oct 2013 16:28:57 +0900

Dear Mike,

Thank you for pointing that out.
I'll remove RFC4188 and RFC4363 from normative references and add them
to informative references in order to make sure these are informative.

Thank you.
Hirochika

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 15 Oct 2013 10:42:22 -0400

> corrected in the next version (the first version for working group

Overall, I like the changes.  Thanks!

NIT: VirtualMachineAdminState:

The destroy(5) state really doesn't match in terms of tense.  What about 
destroyed(5)?  That said, since this is something one can set, perhaps 
present tense like run, pause, suspend, etc. make sense.

Thanks for fleshing out the state definitions :-).

NIT (maybe a minor issue): VirtualMachineAutoStart:

Again, tense.  Here, I think past tense works best since we decided this 
would reflect a read-only state.  I think enabled and disabled work best.

In terms of the new notifications, why enumerate all states as 
notifications?  My original comment suggested a single state change 
notification where the new and previous state would be available as 
objects (note: this would require the definition of a previous state 
object).  It just seems like the way you've implemented it would be 
harder to scale if new states need to be added in the future.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 17 Oct 2013 17:55:13 +0900

Hello,

On 2013/10/15, at 23:42, Joe Marcus Clarke <[email-masked]> wrote:

> In terms of the new notifications, why enumerate all states as notifications?  My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object).  It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future.

Ah, I misunderstood your comment.  I did the change actually.

Consolidating all the notification messages (maybe we will have two eventually, one is for a per VM notification, and the other is for a bulk notification) may be reasonable.

# we can even unify a per vm notification and a bulk notification, but maybe it is not a good idea?

If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday).

---
Keiichi SHIMA (島 慶一)
WIDE project <[email-masked]>
Research Laboratory, IIJ Innovation Institute, Inc <[email-masked]>

On 2013/10/15, at 23:42, Joe Marcus Clarke <[email-masked]> wrote:

> The destroy(5) state really doesn't match in terms of tense.  What about destroyed(5)?  That said, since this is something one can set, perhaps present tense like run, pause, suspend, etc. make sense.
> 
> Again, tense.  Here, I think past tense works best since we decided this would reflect a read-only state.  I think enabled and disabled work best.
> 
> In terms of the new notifications, why enumerate all states as notifications?  My original comment suggested a single state change notification where the new and previous state would be available as objects (note: this would require the definition of a previous state object).  It just seems like the way you've implemented it would be harder to scale if new states need to be added in the future.
> 
> Joe
> 
>> 
>> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Oct 2013 11:17:08 +0200

> If there is no strong opinion for not to unify the notification messages, then we will do the change and resubmit an updated version before the cut-off date (next Monday).

I had this design (generic state change notifications) in my original
MIB module but then I got convinced by Michael that many real-world
applications prefer to have the notification type be specific so that
they can react to the different state changes by simply looking at the
notification type (without having to look into the notification
payload). This is why we got to the current design.

We should be careful here and take care to produce something that
existing notification receivers find 'easy' to process. The number of
states we have should be small and ideally not change over time, so
the implementation costs on the agent side likely are not big.

/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: Keiichi SHIMA <[email-masked]>
Date: Thu, 17 Oct 2013 18:38:13 +0900

Hello Juergen and Joe,

> the implementation costs on the agent side likely are not big.

I think this is a good point.

Joe, do you have any strong objection for the above approach?  If you can live with either ways, then we will keep the current style.

---
Keiichi SHIMA (島 慶一)

---

From: Keiichi SHIMA <[email-masked]>
Date: Thu, 17 Oct 2013 19:55:16 +0900

Hi,

> The destroy(5) state really doesn't match in terms of tense.  What about destroyed(5)?  That said, since this is something one can set, perhaps present tense like run, pause, suspend, etc. make sen…

The original intention of the naming of VirtualMachineAdminState was, 'to transit the operation state of a virtual machine to X by setting its admin state as X'.  For example, when we set 'suspended' to the admin state of a virtual machine, then the virtual machine will start transition to the suspended operation state.  We intentionally used the same state names here.  That is because the tense is past.

For the 'destroy' admin state, since we didn't have any operation state of a destroyed virtual machine (that is same as the shutdown operation state), we didn't pay any attention to the naming.  I can live with either destroy(5) or destroyed(5).  It is a matter of taste to me.

> Again, tense.  Here, I think past tense works best since we decided this would reflect a read-only state.  I think enabled and disabled work best.

Do you mean changing the name to something like 'VirtualMachineAutoStartEnabled'?  Here again, I don't have any strong opinion on this.  I am open to change the name, if most people agree on this.

Regards,
---
Keiichi SHIMA (島 慶一)

---

From: Michael MacFaden <[email-masked]>
Date: Thu, 17 Oct 2013 05:48:53 -0700 (PDT)

Yes and I continue to hold that generic notifications are not useful in practice.  It causes intrroperability problems.

Mike

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Keiichi SHIMA [[email-masked]]
Received: Thursday, 17 Oct 2013, 2:38am
To: Joe Marcus Clarke [[email-masked]]; Juergen Schoenwaelder [[email-masked]]
CC: [email-masked]
Subject: Re: [OPSAWG] New Version Notification for draft-asai-vmm-mib-05.txt

Hello Juergen and Joe,

---
Keiichi SHIMA (島 慶一)

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 17 Oct 2013 14:59:10 -0400

> the implementation costs on the agent side likely are not big.

Okay.  Good to know the back story.  I know we have precedence for the 
consolidated approach as well.  If we feel that the states won't change, 
then listing them out shouldn't be a scalability issue.

Joe

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 17 Oct 2013 15:04:02 -0400

> For the 'destroy' admin state, since we didn't have any operation state of a destroyed virtual machine (that is same as the shutdown operation state), we didn't pay any attention to the naming.  I…

I think destroy(5) sounds better, but I'll admit it is a nit.

> Do you mean changing the name to something like 'VirtualMachineAutoStartEnabled'?  Here again, I don't have any strong opinion on this.  I am open to change the name, if most people agree on this.

No, TC stays the same, but the tense of the states should change to:

unknown(1)
enabled(2)
disabled(3)

Since the associated object is now read-only.

Joe

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Oct 2013 13:10:52 -0800

> Chairs, could you please poll for adoption as a working group item

Just a note that we haven't forgotten about you!  I think we're
generally not very comfortable that we've got an appropriate
level of VM/hypervisor expertise in the IETF to provide thorough,
expert review of the document, although clearly we've got very
deep SNMP/MIB expertise.  So, we've contacted some people
who are not regular IETF participants for feedback, and we're
waiting to hear from them.  You may recall from recent meetings
that we're making an effort to improve document quality, and
here's what Benoit outlined during our session at IETF 86:

	1. reach out to other people for review,
	2. potentially put the bar higher for WG adoption (like in BMWG)
	3. solicit reviews from chairs and AD
	4. if no feedback, kill it. Demonstrate support.
	5. bring the expert to the WG, e.g., as guest speaker.

Melinda

---

From: Keiichi SHIMA <[email-masked]>
Date: Fri, 18 Oct 2013 15:33:50 +0900

Joe,

> Since the associated object is now read-only.

It makes sense.

I'm OK to update the above values.  Any objections from other authors?

---
Keiichi SHIMA (島 慶一)

---

From: Tina TSOU <[email-masked]>
Date: Fri, 18 Oct 2013 15:27:55 +0000

Dear SHIMA-San,
No objection.

Thank you,
Tina

---

From: Keiichi SHIMA <[email-masked]>
Date: Sun, 20 Oct 2013 21:28:58 +0900

Tina,

Thank you for the response.  I updated the draft.

---
Keiichi SHIMA ($)GU5 lcD!)
WIDE project <[email-masked]>
Research Laboratory, IIJ Innovation Institute, Inc <[email-masked]>

On 2013/10/19, at 0:27, Tina TSOU <[email-masked]> wrote:

>> Keiichi SHIMA ($)GU5 lcD!)
>>>> Keiichi SHIMA ($)GU5 lcD!)