From ramk@Brocade.com Sun Aug 4 16:22:50 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB5F11E8101 for ; Sun, 4 Aug 2013 16:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN4ZBOpTxkhR for ; Sun, 4 Aug 2013 16:22:45 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 44BED11E80FC for ; Sun, 4 Aug 2013 16:22:44 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r74NEkjr006764; Sun, 4 Aug 2013 16:22:41 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1e0fb0sc52-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 04 Aug 2013 16:22:41 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 4 Aug 2013 16:22:40 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Sun, 4 Aug 2013 16:22:40 -0700 From: ramki Krishnan To: Fan Peng , "opsawg@ietf.org" Date: Sun, 4 Aug 2013 16:22:38 -0700 Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt Thread-Index: Ac55iWvw4ki8XM1uTqaaMMRB/yWpzAX3+ZNw Message-ID: References: <009901ce798f$c39243b0$4ab6cb10$@chinamobile.com> In-Reply-To: <009901ce798f$c39243b0$4ab6cb10$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-04_08:2013-08-02, 2013-08-04, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308040282 Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 23:22:50 -0000 Pj4gSWYgdGhpcyBtZXRob2QgaXMgdG8gYmUgdXNlZCBvbiBhIHJvdXRlciwgb25lIGlzDQogYWR2 aXNlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgSUNNUCBwYWNrZXRzIGV4cGVyaWVuY2UgdGhlIHNh bWUNCiBmb3J3YXJkaW5nIGFuZCBkaXNjYXJkaW5nIGNvdXJzZXMgYXMgdGhlIHNlcnZpY2UgdHJh ZmZpYyAob2YNCiB3aGljaCB0aGUgcGFja2V0IGxvc3MgcmF0ZSBpcyB0byBiZSBtZWFzdXJlZCkg ZG9lcywgb3RoZXJ3aXNlIHRoZQ0KbWVhc3VyZW1lbnQgd2lsbCBub3QgbWFrZSBzZW5zZS4gDQoN Ckkgd291bGRu4oCZdCBxdWl0ZSBhZ3JlZSB3aXRoIHRoaXMuIFRoZSByZWFzb24gaXQgaXMgZG9u ZSBzbyB0b2RheSBpcyB0byBwcmV2ZW50IHBpbmcgZmxvb2QgdHlwZSBvZiBERG9TIGF0dGFja3Mu DQoNClRoYW5rcywNClJhbWtpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBv cHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgRmFuIFBlbmcNClNlbnQ6IEZyaWRheSwgSnVseSAwNSwgMjAxMyA3OjU2IEFN DQpUbzogb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBbT1BTQVdHXSBGd2Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMS50eHQNCg0K RGVhciBhbGwsDQoNCldlIGhhdmUgdXBkYXRlZCBhIGNvbXBsZXRlIHJldmlzaW9uIHRvIHRoZSBJ LUQgcmVnYXJkaW5nIHBhY2tldCBsb3NzIG1lYXN1cmVtZW50ICwgYW5kIHdvdWxkIGxpa2UgdG8g Z2V0IGZlZWRiYWNrIGZyb20geW91Og0KDQpJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50 IFRlc3RpbmcgYW5kIFByb2JsZW0gU3RhdGVtZW50DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxDQoNClRoZSBkb2N1bWVudCBhaW1zIHRv IHJldmlldyBtZXRob2RzIGZvciBwYWNrZXQgbG9zcyByYXRlIG1lYXN1cmVtZW50IGFuZCBwcm9i bGVtcyB3aXRoIHRoZW0sIGFuZCBwcm92aWRlIHNvbWUgZ3VpZGVsaW5lcyB3aGVuIHBlcmZvcm1p bmcgdGhlIG1lYXN1cmVtZW50LiBUaGUgZG9jdW1lbnQgaXMgYmFzZWQgb24gb3BlcmF0aW9uYWwg ZXhwZXJpZW5jZSBhbmQgbmVlZHMgZXNwZWNpYWxseSB3aGVuIGRvaW5nIHBlcmZvcm1hbmNlIG1v bml0b3Jpbmcgb24gdGhlIGludGVyY29ubmVjdGluZyBsaW5rIGJldHdlZW4gdHdvIHByb3ZpZGVy cycgbmV0d29ya3MuIFdlIGFsc28gaG9wZSB3ZSBjYW4gZmluZCBhZnRlciB0aGUgZGlzY3Vzc2lv biBhIG1lYXN1cmVtZW50IHNjaGVtZSB0aGF0IGlzIGNvbnZlbmllbnQgZW5vdWdoIGFuZCBwcm92 aWRlcyBjb25zaXN0ZW50IHJlc3VsdHMuDQoNCkFueSBjb21tZW50IHdvdWxkIGJlIGFwcHJlY2lh dGVkLiBUaGFuayB5b3UhDQoNClJlZ2FyZHMsDQpQZW5nDQoNCg0KLS0tLS3pgq7ku7bljp/ku7Yt LS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDXml6UgMjE6NDQN CuaUtuS7tuS6ujogUGVuZyBGYW47IE1hY2ggQ2hlbjsgTHUgSHVhbmc7IE1hY2ggKEd1b3lpKSBD aGVuOyBOYWdlbmRyYSBLdW1hcg0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBlbmcgRmFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzDQpSZXZp c2lvbjoJIDAxDQpUaXRsZToJCSBJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50IFRlc3Rp bmcgYW5kIFByb2JsZW0gU3RhdGVtZW50DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0wNQ0KR3Jv dXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE1DQpVUkw6ICAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZhbi1v cHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcw0KSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tl dC1sb3NzLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBjb21tb24gbWV0aG9kcyBmb3IgbWVhc3VyaW5nIHBhY2tldCBs b3NzIHJhdGUNCiAgIGFuZCB0aGVpciBlZmZlY3RpdmVuZXNzLiAgSXNzdWVzIGVuY291bnRlcmVk IHdoZW4gdXNpbmcgdGhlIG1ldGhvZHMNCiAgIGFuZCBuZWNlc3NhcnkgY29uc2lkZXJhdGlvbnMg YXJlIGFsc28gZGlzY3Vzc2VkIGFuZCByZWNvbW1lbmRlZC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpP UFNBV0dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3Bz YXdnDQo= From ramk@Brocade.com Mon Aug 5 11:16:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EDB21F944C for ; Mon, 5 Aug 2013 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYGt5tQKYFap for ; Mon, 5 Aug 2013 11:16:11 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id BEDAD21F9EF8 for ; Mon, 5 Aug 2013 11:16:10 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r75IAQO0026725; Mon, 5 Aug 2013 11:16:02 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1e2g2k01a5-3 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Aug 2013 11:16:02 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Aug 2013 11:16:01 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Mon, 5 Aug 2013 09:42:43 -0700 From: ramki Krishnan To: Fan Peng , "opsawg@ietf.org" Date: Mon, 5 Aug 2013 09:42:39 -0700 Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt Thread-Index: Ac55iWvw4ki8XM1uTqaaMMRB/yWpzAX3+ZNwACRGWOA= Message-ID: References: <009901ce798f$c39243b0$4ab6cb10$@chinamobile.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-05_05:2013-08-05, 2013-08-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308050163 Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 18:16:16 -0000 U29ycnksIG1pc3NlZCB0aGUgc2VjdGlvbiAtLSBJIGFtIGluY2x1ZGluZyBpdC4gTXkgY29tbWVu dHMgYXJlIG9uIFNlY3Rpb24gNSBhLg0KDQo+PiBJZiB0aGlzIG1ldGhvZCBpcyB0byBiZSB1c2Vk IG9uIGEgcm91dGVyLCBvbmUgaXMNCj4+IGFkdmlzZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIElD TVAgcGFja2V0cyBleHBlcmllbmNlIHRoZSBzYW1lICBmb3J3YXJkaW5nIGFuZCBkaXNjYXJkaW5n IGNvdXJzZXMgYXMgdGhlIHNlcnZpY2UgdHJhZmZpYyAob2YgIHdoaWNoIHRoZSBwYWNrZXQgbG9z cyByYXRlIGlzIHRvIGJlIG1lYXN1cmVkKSBkb2VzLCBvdGhlcndpc2UgdGhlIG1lYXN1cmVtZW50 IHdpbGwgbm90IG1ha2Ugc2Vuc2UuIA0KDQpJIHdvdWxkbuKAmXQgcXVpdGUgYWdyZWUgd2l0aCB0 aGlzLiBUaGUgcmVhc29uIGl0IGlzIGRvbmUgc28gdG9kYXkgaXMgdG8gcHJldmVudCBwaW5nIGZs b29kIHR5cGUgb2YgRERvUyBhdHRhY2tzDQoNClRoYW5rcywNClJhbWtpDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9w c2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgcmFta2kgS3Jpc2huYW4NClNlbnQ6 IFN1bmRheSwgQXVndXN0IDA0LCAyMDEzIDQ6MjMgUE0NClRvOiBGYW4gUGVuZzsgb3BzYXdnQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FXR10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQoNCj4+IElmIHRoaXMg bWV0aG9kIGlzIHRvIGJlIHVzZWQgb24gYSByb3V0ZXIsIG9uZSBpcw0KIGFkdmlzZWQgdG8gbWFr ZSBzdXJlIHRoYXQgdGhlIElDTVAgcGFja2V0cyBleHBlcmllbmNlIHRoZSBzYW1lICBmb3J3YXJk aW5nIGFuZCBkaXNjYXJkaW5nIGNvdXJzZXMgYXMgdGhlIHNlcnZpY2UgdHJhZmZpYyAob2YgIHdo aWNoIHRoZSBwYWNrZXQgbG9zcyByYXRlIGlzIHRvIGJlIG1lYXN1cmVkKSBkb2VzLCBvdGhlcndp c2UgdGhlIG1lYXN1cmVtZW50IHdpbGwgbm90IG1ha2Ugc2Vuc2UuIA0KDQpJIHdvdWxkbuKAmXQg cXVpdGUgYWdyZWUgd2l0aCB0aGlzLiBUaGUgcmVhc29uIGl0IGlzIGRvbmUgc28gdG9kYXkgaXMg dG8gcHJldmVudCBwaW5nIGZsb29kIHR5cGUgb2YgRERvUyBhdHRhY2tzLg0KDQpUaGFua3MsDQpS YW1raQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb3BzYXdnLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEZh biBQZW5nDQpTZW50OiBGcmlkYXksIEp1bHkgMDUsIDIwMTMgNzo1NiBBTQ0KVG86IG9wc2F3Z0Bp ZXRmLm9yZw0KU3ViamVjdDogW09QU0FXR10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQoNCkRlYXIgYWxsLA0KDQpX ZSBoYXZlIHVwZGF0ZWQgYSBjb21wbGV0ZSByZXZpc2lvbiB0byB0aGUgSS1EIHJlZ2FyZGluZyBw YWNrZXQgbG9zcyBtZWFzdXJlbWVudCAsIGFuZCB3b3VsZCBsaWtlIHRvIGdldCBmZWVkYmFjayBm cm9tIHlvdToNCg0KSVAgUGFja2V0IExvc3MgUmF0ZSBNZWFzdXJlbWVudCBUZXN0aW5nIGFuZCBQ cm9ibGVtIFN0YXRlbWVudA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFuLW9w c2F3Zy1wYWNrZXQtbG9zcy0wMQ0KDQpUaGUgZG9jdW1lbnQgYWltcyB0byByZXZpZXcgbWV0aG9k cyBmb3IgcGFja2V0IGxvc3MgcmF0ZSBtZWFzdXJlbWVudCBhbmQgcHJvYmxlbXMgd2l0aCB0aGVt LCBhbmQgcHJvdmlkZSBzb21lIGd1aWRlbGluZXMgd2hlbiBwZXJmb3JtaW5nIHRoZSBtZWFzdXJl bWVudC4gVGhlIGRvY3VtZW50IGlzIGJhc2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYW5k IG5lZWRzIGVzcGVjaWFsbHkgd2hlbiBkb2luZyBwZXJmb3JtYW5jZSBtb25pdG9yaW5nIG9uIHRo ZSBpbnRlcmNvbm5lY3RpbmcgbGluayBiZXR3ZWVuIHR3byBwcm92aWRlcnMnIG5ldHdvcmtzLiBX ZSBhbHNvIGhvcGUgd2UgY2FuIGZpbmQgYWZ0ZXIgdGhlIGRpc2N1c3Npb24gYSBtZWFzdXJlbWVu dCBzY2hlbWUgdGhhdCBpcyBjb252ZW5pZW50IGVub3VnaCBhbmQgcHJvdmlkZXMgY29uc2lzdGVu dCByZXN1bHRzLg0KDQpBbnkgY29tbWVudCB3b3VsZCBiZSBhcHByZWNpYXRlZC4gVGhhbmsgeW91 IQ0KDQpSZWdhcmRzLA0KUGVuZw0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6 ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXQ0K5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDXml6UgMjE6NDQNCuaUtuS7tuS6ujogUGVu ZyBGYW47IE1hY2ggQ2hlbjsgTHUgSHVhbmc7IE1hY2ggKEd1b3lpKSBDaGVuOyBOYWdlbmRyYSBL dW1hcg0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZhbi1vcHNh d2ctcGFja2V0LWxvc3MtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZh bi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IFBlbmcgRmFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmls ZW5hbWU6CSBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzDQpSZXZpc2lvbjoJIDAxDQpUaXRs ZToJCSBJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50IFRlc3RpbmcgYW5kIFByb2JsZW0g U3RhdGVtZW50DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0wNQ0KR3JvdXA6CQkgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE1DQpVUkw6ICAgICAgICAgICAgIGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxv c3MtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxDQpEaWZm OiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWZhbi1v cHNhd2ctcGFja2V0LWxvc3MtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBjb21tb24gbWV0aG9kcyBmb3IgbWVhc3VyaW5nIHBhY2tldCBsb3NzIHJhdGUNCiAgIGFu ZCB0aGVpciBlZmZlY3RpdmVuZXNzLiAgSXNzdWVzIGVuY291bnRlcmVkIHdoZW4gdXNpbmcgdGhl IG1ldGhvZHMNCiAgIGFuZCBuZWNlc3NhcnkgY29uc2lkZXJhdGlvbnMgYXJlIGFsc28gZGlzY3Vz c2VkIGFuZCByZWNvbW1lbmRlZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPUFNBV0cgbWFpbGluZyBsaXN0DQpPUFNBV0dAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT1BTQVdHIG1haWxpbmcgbGlz dA0KT1BTQVdHQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29wc2F3Zw0K From melinda.shore@gmail.com Mon Aug 5 14:41:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B456021F9E43 for ; Mon, 5 Aug 2013 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYp5aqBaKfQ7 for ; Mon, 5 Aug 2013 14:41:03 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5524B21F9D5C for ; Mon, 5 Aug 2013 14:41:03 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx1so3814248pab.41 for ; Mon, 05 Aug 2013 14:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=3vXGodsjuY0spPhLS36BLJjCqOSFX3aBZawLhVRiP6s=; b=XN/fk09UkQKB4RkED2TIXS2vL/Pw7jc0c1RVz68pDvcAoRFSC88ZJTrt+zOzUOM+jq 8vqxeKVX3J0tRvMOCfddQWHdoyNEiMjPakE4Fss91dWqZZLtSz/OiV+HQ5moyeHI6ejv BvSYAFQLL7BkoxdWm/NpfgY9I2YIZ4Y/QTMMwc6+HzSkiCAxbAt3+7Qjs2qyPPBw+3KY CvFzeaOduBmK6ISfihyrg1vE4dyq3MW9/E6itl+bNSAR3lf/T3PbLxN+PI9O0x49iFSR mqIp5Xw34OmsFoPmxV2G93jwtnoP/R9kP3w0J6m0+OrI96yTnZYG0wTQnDy7IWK16rqW 2mwA== X-Received: by 10.66.163.164 with SMTP id yj4mr27691818pab.91.1375738862956; Mon, 05 Aug 2013 14:41:02 -0700 (PDT) Received: from spandex.local (66-230-112-156-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.156]) by mx.google.com with ESMTPSA id ss8sm1657710pab.6.2013.08.05.14.41.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 14:41:02 -0700 (PDT) Message-ID: <52001BEC.3090205@gmail.com> Date: Mon, 05 Aug 2013 13:41:00 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Working group last call on "CGN Deployment with BGP/MPLS IP VPNs" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:41:03 -0000 This is to announce the start of working group last call on: CGN Deployment with BGP/MPLS IP VPNs https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list by August 12, 2013. Thanks, opsawg chairs From melinda.shore@gmail.com Mon Aug 5 14:42:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E784421F9D50 for ; Mon, 5 Aug 2013 14:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6mjWHDbBWO6 for ; Mon, 5 Aug 2013 14:42:10 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A46A021F9E80 for ; Mon, 5 Aug 2013 14:42:06 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so3850862pbc.18 for ; Mon, 05 Aug 2013 14:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=wqCjGSpyX2/Ounfsio+5fLYl4PqnpOEr6gjWkFNrs08=; b=hvuRutYL5zmxbgNUJ2apba2gxPX1YC4WWKZBopRsK3Sb4QX6XumgzcN25cy3d6CUYe 7okyYCQE7hdeziVFl6yk9BR2ilQaRIAnj4zPAvHkWnciT6d8IGSGF47bl0L4S3RXloTy R09fGb9lN+tatQxIN8gHv7UPBqV1WoIQ/IQ4hvM7LzoQ7ZlzWOfqe22ETVh8nnrc7aH2 dMVX699ApBqiNWGN4j0qP2IUfGxon7epEO7m2klAnRRGYULy3JyFU04/s/4DmBqHxgRh fMJq2ZA0ow723fAJUK7iK1WYpp9yfc8PwFAHrLLnYr6uQR2JEqbEJcNvxBM9RySkmiWd Lcvw== X-Received: by 10.66.229.106 with SMTP id sp10mr27571294pac.117.1375738926381; Mon, 05 Aug 2013 14:42:06 -0700 (PDT) Received: from spandex.local (66-230-112-156-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.156]) by mx.google.com with ESMTPSA id is3sm1028255pbc.25.2013.08.05.14.42.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 14:42:05 -0700 (PDT) Message-ID: <52001C2B.7070108@gmail.com> Date: Mon, 05 Aug 2013 13:42:03 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <51F09636.1040102@gmail.com> In-Reply-To: <51F09636.1040102@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 21:42:11 -0000 Reminder: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ is in working group last call, which closes August 7. Please have a look at it and post any comments to the opsawg mailing list. Melinda -------- Original Message -------- Subject: Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Date: Wed, 24 Jul 2013 11:42:13 -0800 From: Melinda Shore To: opsawg@ietf.org This is to announce the start of working group last call on: Ethernet in the First Mile Copper (EFMCu) Interfaces MIB https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ It is intended for publication as a standards track RFC. Please give it a careful read and provide any feedback to this mailing list by August 7, 2013. Thanks, opsawg chairs From melinda.shore@gmail.com Mon Aug 5 20:32:34 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9149E21F9F97 for ; Mon, 5 Aug 2013 20:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2X0f28IcuBl for ; Mon, 5 Aug 2013 20:32:34 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2833B21F9C22 for ; Mon, 5 Aug 2013 20:32:34 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id fa1so159115pad.5 for ; Mon, 05 Aug 2013 20:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=yo0Lp2TvXMOf7qgBAYzUXDHn1iOlkJttNzImScfBWg0=; b=F2Egc0AqzcXcG2XkM5JIB3SYswm6FuVa6NhMvm4T2IwN0zFJxDQGFFHM3iwY6ql3qe SnUO2/CV1mMJkOIb7cFo1ogtKnAnAZs9WXjkPBadU0P560/Mhuzgu1EzfOi4TZ7wIYGu 6qaufAt/ETy9Mz2VeFtjQi7NzR6Ldbjw0e6eVlUynQeCUaUaX2735nVRojddOnkF67BL wl8nKZW/IfX28paC9LA17FxD74j9KD7B7zUJBevwJpAkG9RNhDyDLTrYGbtd59VQdqcZ l+MmJRna+Ikxf3t001LCoeI5J5DwK21ZIfEt2M027RKtteADAvsTZKPoZD9+DTPjltNM SQbg== X-Received: by 10.68.191.231 with SMTP id hb7mr25383719pbc.82.1375759953900; Mon, 05 Aug 2013 20:32:33 -0700 (PDT) Received: from spandex.local (66-230-112-156-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.156]) by mx.google.com with ESMTPSA id bb1sm2331027pbc.10.2013.08.05.20.32.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 20:32:32 -0700 (PDT) Message-ID: <52006E4E.8040003@gmail.com> Date: Mon, 05 Aug 2013 19:32:30 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <52001BEC.3090205@gmail.com> In-Reply-To: <52001BEC.3090205@gmail.com> X-Forwarded-Message-Id: <52001BEC.3090205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: Working group last call on "CGN Deployment with BGP/MPLS IP VPNs" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 03:32:34 -0000 Messed up the data again! This will be closing on August 19, not August 12. Please read the document and raise any issues you've identified on this mailing list. Melinda -------- Original Message -------- Subject: Working group last call on "CGN Deployment with BGP/MPLS IP VPNs" Date: Mon, 05 Aug 2013 13:41:00 -0800 From: Melinda Shore To: opsawg@ietf.org , opsawg-chairs@tools.ietf.org This is to announce the start of working group last call on: CGN Deployment with BGP/MPLS IP VPNs https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list by August 12, 2013. Thanks, opsawg chairs From fanpeng@chinamobile.com Mon Aug 5 20:53:30 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32621F9FF2 for ; Mon, 5 Aug 2013 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.44 X-Spam-Level: *** X-Spam-Status: No, score=3.44 tagged_above=-999 required=5 tests=[AWL=3.817, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmAy9aymv-w1 for ; Mon, 5 Aug 2013 20:53:26 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 6EE4321F9F9B for ; Mon, 5 Aug 2013 20:53:25 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2520072e8012-ca012; Tue, 06 Aug 2013 11:52:10 +0800 (CST) X-RM-TRANSID: 2ee2520072e8012-ca012 Received: from X6X8D79D8F49E2 (unknown[10.2.52.152]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee1520072e8a0f-fadff; Tue, 06 Aug 2013 11:52:10 +0800 (CST) X-RM-TRANSID: 2ee1520072e8a0f-fadff From: "Fan, Peng" To: "'ramki Krishnan'" , Date: Tue, 6 Aug 2013 11:54:21 +0800 Message-ID: <004401ce9258$a2610e10$e7232a30$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6SSdpLFHeEe4fQSw6g8gM0X8WZ+g== Content-Language: zh-cn Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 03:53:30 -0000 Hi Ramki, Thanks for commenting. Let me clarify your statement first. Are you = saying that the reason why ICMP is given a different treatment by = routers is to prevent DDoS attacks? There may be different reasons for which ICMP is treated specially, for = example routers may give high priority in processing and forwarding to = packets of network control protocols, e.g. ICMP, routing protocols, etc. = This section is explaining that if ICMP packets and service packets to = be measured experience different treatments, then using ICMP to = measurement packet loss is not advised. A basic requirement for using = ICMP (and other active measurement approaches) is to let probing traffic = and service traffic have the same drop probability, though it is usually = difficult to guarantee this. Regards, Peng > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: ramki Krishnan [mailto:ramk@Brocade.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B48=E6=9C=886=E6=97=A5 0:43 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Fan Peng; opsawg@ietf.org > =E4=B8=BB=E9=A2=98: RE: [OPSAWG] Fwd: New Version Notification for > draft-fan-opsawg-packet-loss-01.txt >=20 > Sorry, missed the section -- I am including it. My comments are on = Section 5 a. >=20 > >> If this method is to be used on a router, one is advised to make = sure > >> that the ICMP packets experience the same forwarding and = discarding > courses as the service traffic (of which the packet loss rate is to = be measured) > does, otherwise the measurement will not make sense. >=20 > I wouldn=E2=80=99t quite agree with this. The reason it is done so = today is to prevent ping > flood type of DDoS attacks >=20 > Thanks, > Ramki >=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf > Of ramki Krishnan > Sent: Sunday, August 04, 2013 4:23 PM > To: Fan Peng; opsawg@ietf.org > Subject: Re: [OPSAWG] Fwd: New Version Notification for > draft-fan-opsawg-packet-loss-01.txt >=20 > >> If this method is to be used on a router, one is > advised to make sure that the ICMP packets experience the same = forwarding > and discarding courses as the service traffic (of which the packet = loss rate is to > be measured) does, otherwise the measurement will not make sense. >=20 > I wouldn=E2=80=99t quite agree with this. The reason it is done so = today is to prevent ping > flood type of DDoS attacks. >=20 > Thanks, > Ramki >=20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf > Of Fan Peng > Sent: Friday, July 05, 2013 7:56 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: New Version Notification for > draft-fan-opsawg-packet-loss-01.txt >=20 > Dear all, >=20 > We have updated a complete revision to the I-D regarding packet loss > measurement , and would like to get feedback from you: >=20 > IP Packet Loss Rate Measurement Testing and Problem Statement > http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 >=20 > The document aims to review methods for packet loss rate measurement = and > problems with them, and provide some guidelines when performing the > measurement. The document is based on operational experience and needs > especially when doing performance monitoring on the interconnecting = link > between two providers' networks. We also hope we can find after the = discussion > a measurement scheme that is convenient enough and provides consistent > results. >=20 > Any comment would be appreciated. Thank you! >=20 > Regards, > Peng >=20 >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B47=E6=9C=885=E6=97=A5 21:44 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Peng Fan; Mach Chen; Lu Huang; Mach = (Guoyi) Chen; Nagendra Kumar > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt >=20 >=20 > A new version of I-D, draft-fan-opsawg-packet-loss-01.txt > has been successfully submitted by Peng Fan and posted to the IETF = repository. >=20 > Filename: draft-fan-opsawg-packet-loss > Revision: 01 > Title: IP Packet Loss Rate Measurement Testing and Problem > Statement > Creation date: 2013-07-05 > Group: Individual Submission > Number of pages: 15 > URL: > = http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-01.txt > Status: = http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss > Htmlized: = http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-fan-opsawg-packet-loss-01 >=20 > Abstract: > This document describes common methods for measuring packet loss = rate > and their effectiveness. Issues encountered when using the methods > and necessary considerations are also discussed and recommended. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ramk@Brocade.com Mon Aug 5 21:07:57 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4111E80E1 for ; Mon, 5 Aug 2013 21:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0rLcq54y8kA for ; Mon, 5 Aug 2013 21:07:52 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id F284321E804E for ; Mon, 5 Aug 2013 21:07:49 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r7642mo2017587; Mon, 5 Aug 2013 21:07:46 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1e2g2k0bed-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Aug 2013 21:07:45 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 5 Aug 2013 21:07:45 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Mon, 5 Aug 2013 21:07:45 -0700 From: ramki Krishnan To: "Fan, Peng" , "opsawg@ietf.org" Date: Mon, 5 Aug 2013 21:07:40 -0700 Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt Thread-Index: Ac6SSdpLFHeEe4fQSw6g8gM0X8WZ+gAECYeg Message-ID: References: <004401ce9258$a2610e10$e7232a30$@chinamobile.com> In-Reply-To: <004401ce9258$a2610e10$e7232a30$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-05_07:2013-08-05, 2013-08-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308050320 Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 04:07:57 -0000 SGkgUGVuZywNCg0KV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IEREb1MgYXR0YWNrIHByZXZlbnRp b24gaXMgb25lIG9mIHRoZSBwcmltYXJ5IHJlYXNvbnMuIFdpdGggdGhhdCBpbiBtaW5kLCBpdCBt YXkgbm90IGJlIHBydWRlbnQgZm9yIElDTVAgcGFja2V0cyB0byBleHBlcmllbmNlIHRoZSBzYW1l IGZvcndhcmRpbmcgYW5kIGRpc2NhcmRpbmcgY291cnNlcyAob3IgZHJvcCBwcm9iYWJpbGl0eSkg YXMgdGhlIHNlcnZpY2UgdHJhZmZpYy4NCg0KVGhhbmtzLA0KUmFta2kNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IEZhbiwgUGVuZyBbbWFpbHRvOmZhbnBlbmdAY2hpbmFtb2Jp bGUuY29tXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDA1LCAyMDEzIDg6NTQgUE0NClRvOiByYW1r aSBLcmlzaG5hbjsgb3BzYXdnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FXR10gRndkOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3Mt MDEudHh0DQoNCkhpIFJhbWtpLA0KDQpUaGFua3MgZm9yIGNvbW1lbnRpbmcuIExldCBtZSBjbGFy aWZ5IHlvdXIgc3RhdGVtZW50IGZpcnN0LiBBcmUgeW91IHNheWluZyB0aGF0IHRoZSByZWFzb24g d2h5IElDTVAgaXMgZ2l2ZW4gYSBkaWZmZXJlbnQgdHJlYXRtZW50IGJ5IHJvdXRlcnMgaXMgdG8g cHJldmVudCBERG9TIGF0dGFja3M/DQoNClRoZXJlIG1heSBiZSBkaWZmZXJlbnQgcmVhc29ucyBm b3Igd2hpY2ggSUNNUCBpcyB0cmVhdGVkIHNwZWNpYWxseSwgZm9yIGV4YW1wbGUgcm91dGVycyBt YXkgZ2l2ZSBoaWdoIHByaW9yaXR5IGluIHByb2Nlc3NpbmcgYW5kIGZvcndhcmRpbmcgdG8gcGFj a2V0cyBvZiBuZXR3b3JrIGNvbnRyb2wgcHJvdG9jb2xzLCBlLmcuIElDTVAsIHJvdXRpbmcgcHJv dG9jb2xzLCBldGMuIFRoaXMgc2VjdGlvbiBpcyBleHBsYWluaW5nIHRoYXQgaWYgSUNNUCBwYWNr ZXRzIGFuZCBzZXJ2aWNlIHBhY2tldHMgdG8gYmUgbWVhc3VyZWQgZXhwZXJpZW5jZSBkaWZmZXJl bnQgdHJlYXRtZW50cywgdGhlbiB1c2luZyBJQ01QIHRvIG1lYXN1cmVtZW50IHBhY2tldCBsb3Nz IGlzIG5vdCBhZHZpc2VkLiBBIGJhc2ljIHJlcXVpcmVtZW50IGZvciB1c2luZyBJQ01QIChhbmQg b3RoZXIgYWN0aXZlIG1lYXN1cmVtZW50IGFwcHJvYWNoZXMpIGlzIHRvIGxldCBwcm9iaW5nIHRy YWZmaWMgYW5kIHNlcnZpY2UgdHJhZmZpYyBoYXZlIHRoZSBzYW1lIGRyb3AgcHJvYmFiaWxpdHks IHRob3VnaCBpdCBpcyB1c3VhbGx5IGRpZmZpY3VsdCB0byBndWFyYW50ZWUgdGhpcy4NCg0KUmVn YXJkcywNClBlbmcNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogcmFt a2kgS3Jpc2huYW4gW21haWx0bzpyYW1rQEJyb2NhZGUuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIw MTPlubQ45pyINuaXpSAwOjQzDQo+IOaUtuS7tuS6ujogRmFuIFBlbmc7IG9wc2F3Z0BpZXRmLm9y Zw0KPiDkuLvpopg6IFJFOiBbT1BTQVdHXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgDQo+IGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQo+IA0KPiBTb3JyeSwg bWlzc2VkIHRoZSBzZWN0aW9uIC0tIEkgYW0gaW5jbHVkaW5nIGl0LiBNeSBjb21tZW50cyBhcmUg b24gU2VjdGlvbiA1IGEuDQo+IA0KPiA+PiBJZiB0aGlzIG1ldGhvZCBpcyB0byBiZSB1c2VkIG9u IGEgcm91dGVyLCBvbmUgaXMgYWR2aXNlZCB0byBtYWtlIA0KPiA+PiBzdXJlIHRoYXQgdGhlIElD TVAgcGFja2V0cyBleHBlcmllbmNlIHRoZSBzYW1lICBmb3J3YXJkaW5nIGFuZCANCj4gPj4gZGlz Y2FyZGluZw0KPiBjb3Vyc2VzIGFzIHRoZSBzZXJ2aWNlIHRyYWZmaWMgKG9mICB3aGljaCB0aGUg cGFja2V0IGxvc3MgcmF0ZSBpcyB0byANCj4gYmUgbWVhc3VyZWQpIGRvZXMsIG90aGVyd2lzZSB0 aGUgbWVhc3VyZW1lbnQgd2lsbCBub3QgbWFrZSBzZW5zZS4NCj4gDQo+IEkgd291bGRu4oCZdCBx dWl0ZSBhZ3JlZSB3aXRoIHRoaXMuIFRoZSByZWFzb24gaXQgaXMgZG9uZSBzbyB0b2RheSBpcyB0 byANCj4gcHJldmVudCBwaW5nIGZsb29kIHR5cGUgb2YgRERvUyBhdHRhY2tzDQo+IA0KPiBUaGFu a3MsDQo+IFJhbWtpDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBv cHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBP biANCj4gQmVoYWxmIE9mIHJhbWtpIEtyaXNobmFuDQo+IFNlbnQ6IFN1bmRheSwgQXVndXN0IDA0 LCAyMDEzIDQ6MjMgUE0NCj4gVG86IEZhbiBQZW5nOyBvcHNhd2dAaWV0Zi5vcmcNCj4gU3ViamVj dDogUmU6IFtPUFNBV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCj4gZHJh ZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMS50eHQNCj4gDQo+ID4+IElmIHRoaXMgbWV0aG9k IGlzIHRvIGJlIHVzZWQgb24gYSByb3V0ZXIsIG9uZSBpcw0KPiAgYWR2aXNlZCB0byBtYWtlIHN1 cmUgdGhhdCB0aGUgSUNNUCBwYWNrZXRzIGV4cGVyaWVuY2UgdGhlIHNhbWUgIA0KPiBmb3J3YXJk aW5nIGFuZCBkaXNjYXJkaW5nIGNvdXJzZXMgYXMgdGhlIHNlcnZpY2UgdHJhZmZpYyAob2YgIHdo aWNoIA0KPiB0aGUgcGFja2V0IGxvc3MgcmF0ZSBpcyB0byBiZSBtZWFzdXJlZCkgZG9lcywgb3Ro ZXJ3aXNlIHRoZSBtZWFzdXJlbWVudCB3aWxsIG5vdCBtYWtlIHNlbnNlLg0KPiANCj4gSSB3b3Vs ZG7igJl0IHF1aXRlIGFncmVlIHdpdGggdGhpcy4gVGhlIHJlYXNvbiBpdCBpcyBkb25lIHNvIHRv ZGF5IGlzIHRvIA0KPiBwcmV2ZW50IHBpbmcgZmxvb2QgdHlwZSBvZiBERG9TIGF0dGFja3MuDQo+ IA0KPiBUaGFua3MsDQo+IFJhbWtpDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2VzQGll dGYub3JnXSBPbiANCj4gQmVoYWxmIE9mIEZhbiBQZW5nDQo+IFNlbnQ6IEZyaWRheSwgSnVseSAw NSwgMjAxMyA3OjU2IEFNDQo+IFRvOiBvcHNhd2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogW09QU0FX R10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIA0KPiBkcmFmdC1mYW4tb3BzYXdn LXBhY2tldC1sb3NzLTAxLnR4dA0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiBXZSBoYXZlIHVwZGF0 ZWQgYSBjb21wbGV0ZSByZXZpc2lvbiB0byB0aGUgSS1EIHJlZ2FyZGluZyBwYWNrZXQgbG9zcyAN Cj4gbWVhc3VyZW1lbnQgLCBhbmQgd291bGQgbGlrZSB0byBnZXQgZmVlZGJhY2sgZnJvbSB5b3U6 DQo+IA0KPiBJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50IFRlc3RpbmcgYW5kIFByb2Js ZW0gU3RhdGVtZW50DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhbi1vcHNh d2ctcGFja2V0LWxvc3MtMDENCj4gDQo+IFRoZSBkb2N1bWVudCBhaW1zIHRvIHJldmlldyBtZXRo b2RzIGZvciBwYWNrZXQgbG9zcyByYXRlIG1lYXN1cmVtZW50IA0KPiBhbmQgcHJvYmxlbXMgd2l0 aCB0aGVtLCBhbmQgcHJvdmlkZSBzb21lIGd1aWRlbGluZXMgd2hlbiBwZXJmb3JtaW5nIA0KPiB0 aGUgbWVhc3VyZW1lbnQuIFRoZSBkb2N1bWVudCBpcyBiYXNlZCBvbiBvcGVyYXRpb25hbCBleHBl cmllbmNlIGFuZCANCj4gbmVlZHMgZXNwZWNpYWxseSB3aGVuIGRvaW5nIHBlcmZvcm1hbmNlIG1v bml0b3Jpbmcgb24gdGhlIA0KPiBpbnRlcmNvbm5lY3RpbmcgbGluayBiZXR3ZWVuIHR3byBwcm92 aWRlcnMnIG5ldHdvcmtzLiBXZSBhbHNvIGhvcGUgd2UgDQo+IGNhbiBmaW5kIGFmdGVyIHRoZSBk aXNjdXNzaW9uIGEgbWVhc3VyZW1lbnQgc2NoZW1lIHRoYXQgaXMgY29udmVuaWVudCANCj4gZW5v dWdoIGFuZCBwcm92aWRlcyBjb25zaXN0ZW50IHJlc3VsdHMuDQo+IA0KPiBBbnkgY29tbWVudCB3 b3VsZCBiZSBhcHByZWNpYXRlZC4gVGhhbmsgeW91IQ0KPiANCj4gUmVnYXJkcywNCj4gUGVuZw0K PiANCj4gDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6OiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IOWPkemA geaXtumXtDogMjAxM+W5tDfmnIg15pelIDIxOjQ0DQo+IOaUtuS7tuS6ujogUGVuZyBGYW47IE1h Y2ggQ2hlbjsgTHUgSHVhbmc7IE1hY2ggKEd1b3lpKSBDaGVuOyBOYWdlbmRyYSBLdW1hcg0KPiDk uLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmFuLW9wc2F3Zy1wYWNr ZXQtbG9zcy0wMS50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmFu LW9wc2F3Zy1wYWNrZXQtbG9zcy0wMS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBQZW5nIEZhbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+IA0K PiBGaWxlbmFtZToJIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MNCj4gUmV2aXNpb246CSAw MQ0KPiBUaXRsZToJCSBJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1cmVtZW50IFRlc3RpbmcgYW5k IFByb2JsZW0NCj4gU3RhdGVtZW50DQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTA3LTA1DQo+IEdy b3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDE1DQo+IFVS TDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZmFuLW9wc2F3 Zy1wYWNrZXQtbG9zcy0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MNCj4gSHRtbGl6ZWQ6 ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tl dC1sb3NzLTAxDQo+IERpZmY6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBjb21tb24gbWV0aG9kcyBmb3IgbWVhc3VyaW5nIHBhY2tldCBs b3NzIHJhdGUNCj4gICAgYW5kIHRoZWlyIGVmZmVjdGl2ZW5lc3MuICBJc3N1ZXMgZW5jb3VudGVy ZWQgd2hlbiB1c2luZyB0aGUgbWV0aG9kcw0KPiAgICBhbmQgbmVjZXNzYXJ5IGNvbnNpZGVyYXRp b25zIGFyZSBhbHNvIGRpc2N1c3NlZCBhbmQgcmVjb21tZW5kZWQuDQo+IA0KPiANCj4gDQo+IA0K PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT1BTQVdHIG1haWxpbmcgbGlzdA0K PiBPUFNBV0dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNhd2cNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gT1BTQVdHIG1haWxpbmcgbGlzdA0KPiBPUFNBV0dAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNhd2cNCg0KDQoNCg== From fanpeng@chinamobile.com Mon Aug 5 23:17:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E041011E80D5 for ; Mon, 5 Aug 2013 23:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.532 X-Spam-Level: * X-Spam-Status: No, score=1.532 tagged_above=-999 required=5 tests=[AWL=1.909, BAYES_00=-2.599, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xq5Xei2UwJr8 for ; Mon, 5 Aug 2013 23:17:55 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 27B5921E8088 for ; Mon, 5 Aug 2013 23:17:54 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.12]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee2520094c759e-cc59e; Tue, 06 Aug 2013 14:16:39 +0800 (CST) X-RM-TRANSID: 2ee2520094c759e-cc59e Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp02-12002 (RichMail) with SMTP id 2ee2520094c6590-f57ff; Tue, 06 Aug 2013 14:16:39 +0800 (CST) X-RM-TRANSID: 2ee2520094c6590-f57ff From: "Fan, Peng" To: "'ramki Krishnan'" , Date: Tue, 6 Aug 2013 14:18:46 +0800 Message-ID: <004801ce926c$cee37720$6caa6560$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6SYAR9Cm00CDXMTXSneqv2j7xPfA== Content-Language: zh-cn Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 06:18:00 -0000 Hi Ramki, Yes I agree with you on this point. This is also one of the reasons why = ICMP may not be a proper way to do performance measurement, especially = when we want to get results precise enough. In fact ICMP has been = imposed on so many functions that it is hardly as "ordinary" as internet = traffic, and the processing of ICMP is closely related with vendor = implementation which may not be adjustable by configuration. But alas we = don't have structured IP OAM tools like MPLS OAM or ETH OAM, and = sometimes people just choose ICMP for its convenience. Thanks, Peng > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: ramki Krishnan [mailto:ramk@Brocade.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B48=E6=9C=886=E6=97=A5 12:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Fan, Peng; opsawg@ietf.org > =E4=B8=BB=E9=A2=98: RE: [OPSAWG] Fwd: New Version Notification for > draft-fan-opsawg-packet-loss-01.txt >=20 > Hi Peng, >=20 > What I am saying is that DDoS attack prevention is one of the primary = reasons. > With that in mind, it may not be prudent for ICMP packets to = experience the > same forwarding and discarding courses (or drop probability) as the = service > traffic. >=20 > Thanks, > Ramki >=20 > -----Original Message----- > From: Fan, Peng [mailto:fanpeng@chinamobile.com] > Sent: Monday, August 05, 2013 8:54 PM > To: ramki Krishnan; opsawg@ietf.org > Subject: Re: [OPSAWG] Fwd: New Version Notification for > draft-fan-opsawg-packet-loss-01.txt >=20 > Hi Ramki, >=20 > Thanks for commenting. Let me clarify your statement first. Are you = saying that > the reason why ICMP is given a different treatment by routers is to = prevent DDoS > attacks? >=20 > There may be different reasons for which ICMP is treated specially, = for example > routers may give high priority in processing and forwarding to packets = of network > control protocols, e.g. ICMP, routing protocols, etc. This section is = explaining that > if ICMP packets and service packets to be measured experience = different > treatments, then using ICMP to measurement packet loss is not advised. = A basic > requirement for using ICMP (and other active measurement approaches) = is to let > probing traffic and service traffic have the same drop probability, = though it is > usually difficult to guarantee this. >=20 > Regards, > Peng >=20 > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ramki Krishnan = [mailto:ramk@Brocade.com] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B48=E6=9C=886=E6=97=A5 0:43 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Fan Peng; opsawg@ietf.org > > =E4=B8=BB=E9=A2=98: RE: [OPSAWG] Fwd: New Version Notification for > > draft-fan-opsawg-packet-loss-01.txt > > > > Sorry, missed the section -- I am including it. My comments are on = Section 5 a. > > > > >> If this method is to be used on a router, one is advised to make > > >> sure that the ICMP packets experience the same forwarding and > > >> discarding > > courses as the service traffic (of which the packet loss rate is to > > be measured) does, otherwise the measurement will not make sense. > > > > I wouldn=E2=80=99t quite agree with this. The reason it is done so = today is to > > prevent ping flood type of DDoS attacks > > > > Thanks, > > Ramki > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of ramki Krishnan > > Sent: Sunday, August 04, 2013 4:23 PM > > To: Fan Peng; opsawg@ietf.org > > Subject: Re: [OPSAWG] Fwd: New Version Notification for > > draft-fan-opsawg-packet-loss-01.txt > > > > >> If this method is to be used on a router, one is > > advised to make sure that the ICMP packets experience the same > > forwarding and discarding courses as the service traffic (of which > > the packet loss rate is to be measured) does, otherwise the = measurement will > not make sense. > > > > I wouldn=E2=80=99t quite agree with this. The reason it is done so = today is to > > prevent ping flood type of DDoS attacks. > > > > Thanks, > > Ramki > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of Fan Peng > > Sent: Friday, July 05, 2013 7:56 AM > > To: opsawg@ietf.org > > Subject: [OPSAWG] Fwd: New Version Notification for > > draft-fan-opsawg-packet-loss-01.txt > > > > Dear all, > > > > We have updated a complete revision to the I-D regarding packet loss > > measurement , and would like to get feedback from you: > > > > IP Packet Loss Rate Measurement Testing and Problem Statement > > http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 > > > > The document aims to review methods for packet loss rate measurement > > and problems with them, and provide some guidelines when performing > > the measurement. The document is based on operational experience and > > needs especially when doing performance monitoring on the > > interconnecting link between two providers' networks. We also hope = we > > can find after the discussion a measurement scheme that is = convenient > > enough and provides consistent results. > > > > Any comment would be appreciated. Thank you! > > > > Regards, > > Peng > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2013=E5=B9=B47=E6=9C=885=E6=97=A5 21:44 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Peng Fan; Mach Chen; Lu Huang; Mach = (Guoyi) Chen; Nagendra > Kumar > > =E4=B8=BB=E9=A2=98: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt > > > > > > A new version of I-D, draft-fan-opsawg-packet-loss-01.txt > > has been successfully submitted by Peng Fan and posted to the IETF = repository. > > > > Filename: draft-fan-opsawg-packet-loss > > Revision: 01 > > Title: IP Packet Loss Rate Measurement Testing and Problem > > Statement > > Creation date: 2013-07-05 > > Group: Individual Submission > > Number of pages: 15 > > URL: > > = http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-01.txt > > Status: > http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss > > Htmlized: = http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01 > > Diff: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-fan-opsawg-packet-loss-01 > > > > Abstract: > > This document describes common methods for measuring packet loss = rate > > and their effectiveness. Issues encountered when using the = methods > > and necessary considerations are also discussed and recommended. > > > > > > > > > > The IETF Secretariat > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 From ghanwani@gmail.com Tue Aug 6 07:33:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC5F21F99FD for ; Tue, 6 Aug 2013 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2JVd-KzVXAN for ; Tue, 6 Aug 2013 07:33:37 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6621F99FB for ; Tue, 6 Aug 2013 07:33:36 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id m46so427113wev.8 for ; Tue, 06 Aug 2013 07:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=29Qk/hwchNh8ma2PKUfvYbs/VAVIfYVR8jRWtIwXN+Q=; b=ovyzEwJR/oAi2WmLfzGu1IpTYXOsrqxKK8BVngV2wawtEAhAYhlB0Iv+1gsLCbaaf/ ALosazL3Riwa5wMdyCCfNi32V0HpXsnxmvkgUWdCbp+3VIUjcGF6f4HuVILH+SRr4h90 iFRnuznBRoqN4e2SGSyh7NIf+pankqcbgBaR11CxxdZGOjHHQVNe+mjKJyuZMBBBYigg jbzM8I89MZLYkJUdrEUcaKwYd8g8SOLOECAnApKtzoRbth5juOb3zhxTWCytnvJfjeX2 Cmvh+3PCO0JNMIr0k6oschmro8dZTcuhCtubqJ4numleW+uYD7oSNMTK2YiTnN9LrhLn Loyg== MIME-Version: 1.0 X-Received: by 10.180.187.17 with SMTP id fo17mr1178523wic.60.1375799616040; Tue, 06 Aug 2013 07:33:36 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.70.73 with HTTP; Tue, 6 Aug 2013 07:33:36 -0700 (PDT) In-Reply-To: <004401ce9258$a2610e10$e7232a30$@chinamobile.com> References: <004401ce9258$a2610e10$e7232a30$@chinamobile.com> Date: Tue, 6 Aug 2013 07:33:36 -0700 X-Google-Sender-Auth: QgU9MZS5bOGCh9b2kksFUD95H7A Message-ID: From: Anoop Ghanwani To: "Fan, Peng" Content-Type: multipart/alternative; boundary=001a11c26a5e65760004e3484fa3 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 14:33:37 -0000 --001a11c26a5e65760004e3484fa3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng wrote: > > A basic requirement for using ICMP (and other active measurement > approaches) is to let probing traffic and service traffic have the same > drop probability, though it is usually difficult to guarantee this. > It seems like this would be further complicated if something like ECN is in use. While ECT packets would be marked with CE and thus not contribute to the loss rate, ICMP packets would end up being discarded. Anoop --001a11c26a5e65760004e3484fa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng <fanpeng@chinamobi= le.com> wrote:

A basic requirement for using ICMP (and = other active measurement approaches) is to let probing traffic and service = traffic have the same drop probability, though it is usually difficult to g= uarantee this.

It seems like this would be further compli= cated if something like ECN is in use. =A0While ECT packets would be marked= with CE and thus not contribute to the loss rate, ICMP packets would end u= p being discarded.

Anoop =A0
--001a11c26a5e65760004e3484fa3-- From cpignata@cisco.com Tue Aug 6 11:32:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC7321F938E for ; Tue, 6 Aug 2013 11:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.22 X-Spam-Level: X-Spam-Status: No, score=-108.22 tagged_above=-999 required=5 tests=[AWL=-2.163, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX4vFoNqGiQo for ; Tue, 6 Aug 2013 11:32:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9477611E80A2 for ; Tue, 6 Aug 2013 11:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10050; q=dns/txt; s=iport; t=1375813948; x=1377023548; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2X7BIonAKFgHi8C3D/6iqmSjN4ka8LpzNpuqfUHIf48=; b=KxbVTRFq1oL+viSYcMex+/soe4wKS007TdM0xuZenAq3pXrynoubzkkl w/mDrvBYk069b0cxSa97ZtcJITgCb7vqCF3JjAnstwoGW5JIwbZCYFRpn XNrCbhOHQ+vk1A9rA+f4v/QK9KDPoJ8iLWkbeT3MoUSqsjs2i5mysfpbx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADhAAVKtJV2c/2dsb2JhbABagwY1SoMWu20XgQgWdIIkAQEBAwEBAQExOgkCBQcEAgEGAhEEAQEFIwUCAiULFAkIAQEEDgUJiAEGBwWJeJtCCJFagSSOQxgbBwaCXTd0A5dhgSqQJIFegTk X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244029814" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2013 18:32:28 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r76IWSBl002293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 18:32:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 13:32:27 -0500 From: "Carlos Pignataro (cpignata)" To: "Fan, Peng" Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt Thread-Index: Ac6SYAR9V/xhS4LP3UqSpkS4cGYBawAc0jg4 Date: Tue, 6 Aug 2013 18:32:27 +0000 Message-ID: <4EF3D76E-C168-482C-8BCF-99E3847CD206@cisco.com> References: <004801ce926c$cee37720$6caa6560$@chinamobile.com> In-Reply-To: <004801ce926c$cee37720$6caa6560$@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:32:39 -0000 SGVsbG8sIEZhbiwgUmFta2ksDQoNCkp1c3QgYmVjYXVzZSB0aGVyZSBpcyBhIGhhbW1lciwgaXQg ZG9lcyBub3QgbWVhbiB0aGF0IGV2ZXJ5IHByb2JsZW0gaXMgYSBuYWlsLiBTb21lb25lIG1lbnRp b25lZCB0aGlzIG9uIHRoZSBwcmVzZW50YXRpb24gYXQgQmVybGluLg0KDQpGYW4sDQoNCkl0IHJl YWxseSBpcyBhbGwgYWJvdXQgc2NvcGUgYW5kIGdvYWxzLiBZb3UgbWVudGlvbiB0aGF0IElDTVAg aXMgbm90IGFwcHJvcHJpYXRlLCBhbmQgdGhlbiB0aGF0IGl0IGlzIGFwcHJvcHJpYXRlLiBJIHN1 c3BlY3QgdGhlIHJlYWwgY29uY2x1c2lvbiBpcyBjb250ZXh0IGRlcGVuZGVudC4gDQoNClRodW1i IHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQpFeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MN Cg0KT24gQXVnIDYsIDIwMTMsIGF0IDg6MTggQU0sICJGYW4sIFBlbmciIDxmYW5wZW5nQGNoaW5h bW9iaWxlLmNvbT4gd3JvdGU6DQoNCj4gSGkgUmFta2ksDQo+IA0KPiBZZXMgSSBhZ3JlZSB3aXRo IHlvdSBvbiB0aGlzIHBvaW50LiBUaGlzIGlzIGFsc28gb25lIG9mIHRoZSByZWFzb25zIHdoeSBJ Q01QIG1heSBub3QgYmUgYSBwcm9wZXIgd2F5IHRvIGRvIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50 LCBlc3BlY2lhbGx5IHdoZW4gd2Ugd2FudCB0byBnZXQgcmVzdWx0cyBwcmVjaXNlIGVub3VnaC4g SW4gZmFjdCBJQ01QIGhhcyBiZWVuIGltcG9zZWQgb24gc28gbWFueSBmdW5jdGlvbnMgdGhhdCBp dCBpcyBoYXJkbHkgYXMgIm9yZGluYXJ5IiBhcyBpbnRlcm5ldCB0cmFmZmljLCBhbmQgdGhlIHBy b2Nlc3Npbmcgb2YgSUNNUCBpcyBjbG9zZWx5IHJlbGF0ZWQgd2l0aCB2ZW5kb3IgaW1wbGVtZW50 YXRpb24gd2hpY2ggbWF5IG5vdCBiZSBhZGp1c3RhYmxlIGJ5IGNvbmZpZ3VyYXRpb24uIEJ1dCBh bGFzIHdlIGRvbid0IGhhdmUgc3RydWN0dXJlZCBJUCBPQU0gdG9vbHMgbGlrZSBNUExTIE9BTSBv ciBFVEggT0FNLCBhbmQgc29tZXRpbWVzIHBlb3BsZSBqdXN0IGNob29zZSBJQ01QIGZvciBpdHMg Y29udmVuaWVuY2UuDQo+IA0KPiBUaGFua3MsDQo+IFBlbmcNCj4gDQo+PiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4+ILeivP7IyzogcmFta2kgS3Jpc2huYW4gW21haWx0bzpyYW1rQEJyb2NhZGUuY29t XQ0KPj4gt6LLzcqxvOQ6IDIwMTPE6jjUwjbI1SAxMjowOA0KPj4gytW8/sjLOiBGYW4sIFBlbmc7 IG9wc2F3Z0BpZXRmLm9yZw0KPj4g1vfM4jogUkU6IFtPUFNBV0ddIEZ3ZDogTmV3IFZlcnNpb24g Tm90aWZpY2F0aW9uIGZvcg0KPj4gZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMS50eHQN Cj4+IA0KPj4gSGkgUGVuZywNCj4+IA0KPj4gV2hhdCBJIGFtIHNheWluZyBpcyB0aGF0IEREb1Mg YXR0YWNrIHByZXZlbnRpb24gaXMgb25lIG9mIHRoZSBwcmltYXJ5IHJlYXNvbnMuDQo+PiBXaXRo IHRoYXQgaW4gbWluZCwgaXQgbWF5IG5vdCBiZSBwcnVkZW50IGZvciBJQ01QIHBhY2tldHMgdG8g ZXhwZXJpZW5jZSB0aGUNCj4+IHNhbWUgZm9yd2FyZGluZyBhbmQgZGlzY2FyZGluZyBjb3Vyc2Vz IChvciBkcm9wIHByb2JhYmlsaXR5KSBhcyB0aGUgc2VydmljZQ0KPj4gdHJhZmZpYy4NCj4+IA0K Pj4gVGhhbmtzLA0KPj4gUmFta2kNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+IEZyb206IEZhbiwgUGVuZyBbbWFpbHRvOmZhbnBlbmdAY2hpbmFtb2JpbGUuY29tXQ0KPj4g U2VudDogTW9uZGF5LCBBdWd1c3QgMDUsIDIwMTMgODo1NCBQTQ0KPj4gVG86IHJhbWtpIEtyaXNo bmFuOyBvcHNhd2dAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBGd2Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+IGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3Mt MDEudHh0DQo+PiANCj4+IEhpIFJhbWtpLA0KPj4gDQo+PiBUaGFua3MgZm9yIGNvbW1lbnRpbmcu IExldCBtZSBjbGFyaWZ5IHlvdXIgc3RhdGVtZW50IGZpcnN0LiBBcmUgeW91IHNheWluZyB0aGF0 DQo+PiB0aGUgcmVhc29uIHdoeSBJQ01QIGlzIGdpdmVuIGEgZGlmZmVyZW50IHRyZWF0bWVudCBi eSByb3V0ZXJzIGlzIHRvIHByZXZlbnQgRERvUw0KPj4gYXR0YWNrcz8NCj4+IA0KPj4gVGhlcmUg bWF5IGJlIGRpZmZlcmVudCByZWFzb25zIGZvciB3aGljaCBJQ01QIGlzIHRyZWF0ZWQgc3BlY2lh bGx5LCBmb3IgZXhhbXBsZQ0KPj4gcm91dGVycyBtYXkgZ2l2ZSBoaWdoIHByaW9yaXR5IGluIHBy b2Nlc3NpbmcgYW5kIGZvcndhcmRpbmcgdG8gcGFja2V0cyBvZiBuZXR3b3JrDQo+PiBjb250cm9s IHByb3RvY29scywgZS5nLiBJQ01QLCByb3V0aW5nIHByb3RvY29scywgZXRjLiBUaGlzIHNlY3Rp b24gaXMgZXhwbGFpbmluZyB0aGF0DQo+PiBpZiBJQ01QIHBhY2tldHMgYW5kIHNlcnZpY2UgcGFj a2V0cyB0byBiZSBtZWFzdXJlZCBleHBlcmllbmNlIGRpZmZlcmVudA0KPj4gdHJlYXRtZW50cywg dGhlbiB1c2luZyBJQ01QIHRvIG1lYXN1cmVtZW50IHBhY2tldCBsb3NzIGlzIG5vdCBhZHZpc2Vk LiBBIGJhc2ljDQo+PiByZXF1aXJlbWVudCBmb3IgdXNpbmcgSUNNUCAoYW5kIG90aGVyIGFjdGl2 ZSBtZWFzdXJlbWVudCBhcHByb2FjaGVzKSBpcyB0byBsZXQNCj4+IHByb2JpbmcgdHJhZmZpYyBh bmQgc2VydmljZSB0cmFmZmljIGhhdmUgdGhlIHNhbWUgZHJvcCBwcm9iYWJpbGl0eSwgdGhvdWdo IGl0IGlzDQo+PiB1c3VhbGx5IGRpZmZpY3VsdCB0byBndWFyYW50ZWUgdGhpcy4NCj4+IA0KPj4g UmVnYXJkcywNCj4+IFBlbmcNCj4+IA0KPj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4+ILeivP7I yzogcmFta2kgS3Jpc2huYW4gW21haWx0bzpyYW1rQEJyb2NhZGUuY29tXQ0KPj4+ILeiy83Ksbzk OiAyMDEzxOo41MI2yNUgMDo0Mw0KPj4+IMrVvP7IyzogRmFuIFBlbmc7IG9wc2F3Z0BpZXRmLm9y Zw0KPj4+INb3zOI6IFJFOiBbT1BTQVdHXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3INCj4+PiBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxLnR4dA0KPj4+IA0KPj4+IFNv cnJ5LCBtaXNzZWQgdGhlIHNlY3Rpb24gLS0gSSBhbSBpbmNsdWRpbmcgaXQuIE15IGNvbW1lbnRz IGFyZSBvbiBTZWN0aW9uIDUgYS4NCj4+PiANCj4+Pj4+IElmIHRoaXMgbWV0aG9kIGlzIHRvIGJl IHVzZWQgb24gYSByb3V0ZXIsIG9uZSBpcyBhZHZpc2VkIHRvIG1ha2UNCj4+Pj4+IHN1cmUgdGhh dCB0aGUgSUNNUCBwYWNrZXRzIGV4cGVyaWVuY2UgdGhlIHNhbWUgIGZvcndhcmRpbmcgYW5kDQo+ Pj4+PiBkaXNjYXJkaW5nDQo+Pj4gY291cnNlcyBhcyB0aGUgc2VydmljZSB0cmFmZmljIChvZiAg d2hpY2ggdGhlIHBhY2tldCBsb3NzIHJhdGUgaXMgdG8NCj4+PiBiZSBtZWFzdXJlZCkgZG9lcywg b3RoZXJ3aXNlIHRoZSBtZWFzdXJlbWVudCB3aWxsIG5vdCBtYWtlIHNlbnNlLg0KPj4+IA0KPj4+ IEkgd291bGRuoa90IHF1aXRlIGFncmVlIHdpdGggdGhpcy4gVGhlIHJlYXNvbiBpdCBpcyBkb25l IHNvIHRvZGF5IGlzIHRvDQo+Pj4gcHJldmVudCBwaW5nIGZsb29kIHR5cGUgb2YgRERvUyBhdHRh Y2tzDQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IFJhbWtpDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv Om9wc2F3Zy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+IEJlaGFsZiBPZiByYW1raSBLcmlzaG5h bg0KPj4+IFNlbnQ6IFN1bmRheSwgQXVndXN0IDA0LCAyMDEzIDQ6MjMgUE0NCj4+PiBUbzogRmFu IFBlbmc7IG9wc2F3Z0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbT1BTQVdHXSBGd2Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+PiBkcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1s b3NzLTAxLnR4dA0KPj4+IA0KPj4+Pj4gSWYgdGhpcyBtZXRob2QgaXMgdG8gYmUgdXNlZCBvbiBh IHJvdXRlciwgb25lIGlzDQo+Pj4gYWR2aXNlZCB0byBtYWtlIHN1cmUgdGhhdCB0aGUgSUNNUCBw YWNrZXRzIGV4cGVyaWVuY2UgdGhlIHNhbWUNCj4+PiBmb3J3YXJkaW5nIGFuZCBkaXNjYXJkaW5n IGNvdXJzZXMgYXMgdGhlIHNlcnZpY2UgdHJhZmZpYyAob2YgIHdoaWNoDQo+Pj4gdGhlIHBhY2tl dCBsb3NzIHJhdGUgaXMgdG8gYmUgbWVhc3VyZWQpIGRvZXMsIG90aGVyd2lzZSB0aGUgbWVhc3Vy ZW1lbnQgd2lsbA0KPj4gbm90IG1ha2Ugc2Vuc2UuDQo+Pj4gDQo+Pj4gSSB3b3VsZG6hr3QgcXVp dGUgYWdyZWUgd2l0aCB0aGlzLiBUaGUgcmVhc29uIGl0IGlzIGRvbmUgc28gdG9kYXkgaXMgdG8N Cj4+PiBwcmV2ZW50IHBpbmcgZmxvb2QgdHlwZSBvZiBERG9TIGF0dGFja3MuDQo+Pj4gDQo+Pj4g VGhhbmtzLA0KPj4+IFJhbWtpDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+PiBGcm9tOiBvcHNhd2ctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9wc2F3Zy1ib3VuY2Vz QGlldGYub3JnXSBPbg0KPj4+IEJlaGFsZiBPZiBGYW4gUGVuZw0KPj4+IFNlbnQ6IEZyaWRheSwg SnVseSAwNSwgMjAxMyA3OjU2IEFNDQo+Pj4gVG86IG9wc2F3Z0BpZXRmLm9yZw0KPj4+IFN1Ympl Y3Q6IFtPUFNBV0ddIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4+IGRyYWZ0 LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0DQo+Pj4gDQo+Pj4gRGVhciBhbGwsDQo+Pj4g DQo+Pj4gV2UgaGF2ZSB1cGRhdGVkIGEgY29tcGxldGUgcmV2aXNpb24gdG8gdGhlIEktRCByZWdh cmRpbmcgcGFja2V0IGxvc3MNCj4+PiBtZWFzdXJlbWVudCAsIGFuZCB3b3VsZCBsaWtlIHRvIGdl dCBmZWVkYmFjayBmcm9tIHlvdToNCj4+PiANCj4+PiBJUCBQYWNrZXQgTG9zcyBSYXRlIE1lYXN1 cmVtZW50IFRlc3RpbmcgYW5kIFByb2JsZW0gU3RhdGVtZW50DQo+Pj4gaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMQ0KPj4+IA0KPj4+IFRo ZSBkb2N1bWVudCBhaW1zIHRvIHJldmlldyBtZXRob2RzIGZvciBwYWNrZXQgbG9zcyByYXRlIG1l YXN1cmVtZW50DQo+Pj4gYW5kIHByb2JsZW1zIHdpdGggdGhlbSwgYW5kIHByb3ZpZGUgc29tZSBn dWlkZWxpbmVzIHdoZW4gcGVyZm9ybWluZw0KPj4+IHRoZSBtZWFzdXJlbWVudC4gVGhlIGRvY3Vt ZW50IGlzIGJhc2VkIG9uIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgYW5kDQo+Pj4gbmVlZHMgZXNw ZWNpYWxseSB3aGVuIGRvaW5nIHBlcmZvcm1hbmNlIG1vbml0b3Jpbmcgb24gdGhlDQo+Pj4gaW50 ZXJjb25uZWN0aW5nIGxpbmsgYmV0d2VlbiB0d28gcHJvdmlkZXJzJyBuZXR3b3Jrcy4gV2UgYWxz byBob3BlIHdlDQo+Pj4gY2FuIGZpbmQgYWZ0ZXIgdGhlIGRpc2N1c3Npb24gYSBtZWFzdXJlbWVu dCBzY2hlbWUgdGhhdCBpcyBjb252ZW5pZW50DQo+Pj4gZW5vdWdoIGFuZCBwcm92aWRlcyBjb25z aXN0ZW50IHJlc3VsdHMuDQo+Pj4gDQo+Pj4gQW55IGNvbW1lbnQgd291bGQgYmUgYXBwcmVjaWF0 ZWQuIFRoYW5rIHlvdSENCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IFBlbmcNCj4+PiANCj4+PiAN Cj4+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4+PiC3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4+PiC3osvNyrG85DogMjAx M8TqN9TCNcjVIDIxOjQ0DQo+Pj4gytW8/sjLOiBQZW5nIEZhbjsgTWFjaCBDaGVuOyBMdSBIdWFu ZzsgTWFjaCAoR3VveWkpIENoZW47IE5hZ2VuZHJhDQo+PiBLdW1hcg0KPj4+INb3zOI6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZmFuLW9wc2F3Zy1wYWNrZXQtbG9zcy0wMS50 eHQNCj4+PiANCj4+PiANCj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZmFuLW9wc2F3 Zy1wYWNrZXQtbG9zcy0wMS50eHQNCj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFBlbmcgRmFuIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4+PiANCj4+ PiBGaWxlbmFtZTogICAgIGRyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MNCj4+PiBSZXZpc2lv bjogICAgIDAxDQo+Pj4gVGl0bGU6ICAgICAgICAgSVAgUGFja2V0IExvc3MgUmF0ZSBNZWFzdXJl bWVudCBUZXN0aW5nIGFuZCBQcm9ibGVtDQo+Pj4gU3RhdGVtZW50DQo+Pj4gQ3JlYXRpb24gZGF0 ZTogICAgIDIwMTMtMDctMDUNCj4+PiBHcm91cDogICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4+PiBOdW1iZXIgb2YgcGFnZXM6IDE1DQo+Pj4gVVJMOg0KPj4+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZhbi1vcHNhd2ctcGFja2V0LWxvc3MtMDEudHh0 DQo+Pj4gU3RhdHVzOg0KPj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m YW4tb3BzYXdnLXBhY2tldC1sb3NzDQo+Pj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1mYW4tb3BzYXdnLXBhY2tldC1sb3NzLTAxDQo+Pj4gRGlmZjoN Cj4+PiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1mYW4tb3BzYXdnLXBh Y2tldC1sb3NzLTAxDQo+Pj4gDQo+Pj4gQWJzdHJhY3Q6DQo+Pj4gICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBjb21tb24gbWV0aG9kcyBmb3IgbWVhc3VyaW5nIHBhY2tldCBsb3NzIHJhdGUNCj4+ PiAgIGFuZCB0aGVpciBlZmZlY3RpdmVuZXNzLiAgSXNzdWVzIGVuY291bnRlcmVkIHdoZW4gdXNp bmcgdGhlIG1ldGhvZHMNCj4+PiAgIGFuZCBuZWNlc3NhcnkgY29uc2lkZXJhdGlvbnMgYXJlIGFs c28gZGlzY3Vzc2VkIGFuZCByZWNvbW1lbmRlZC4NCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+ PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gT1BTQVdHIG1h aWxpbmcgbGlzdA0KPj4+IE9QU0FXR0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+PiBPUFNBV0cgbWFpbGluZyBsaXN0DQo+Pj4gT1BTQVdH QGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNh d2cNCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4gT1BTQVdHQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzYXdnDQo= From cpignata@cisco.com Tue Aug 6 11:35:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3AF21F9798 for ; Tue, 6 Aug 2013 11:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.267 X-Spam-Level: X-Spam-Status: No, score=-110.267 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+p7sRgqPHeo for ; Tue, 6 Aug 2013 11:35:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E83F21F9633 for ; Tue, 6 Aug 2013 11:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4120; q=dns/txt; s=iport; t=1375814105; x=1377023705; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=KrU6cM4Pp7Kg0xcI0991VDYhrnK4KfhzX8GRNAgLZ5w=; b=KbAdRHM5uNHV/Yb+njVLeOqrAnw9VnXuOUKKLPrCUWi2HCoQysgOzHRj 9az4+/gvkMT+9sGnOGI+m3ALFvj42RBlq2qTRgi1Q75m8+n2+S+thK2uy EOIqQtzIcuHd7z15ACjLbwD6tYX0Fnw4i0vm02RW7oKbRM/03uX8LG8Pd k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAC1BAVKtJV2c/2dsb2JhbABaDoJ4Nb9NgR8WdIIlAQEEAQEBawkCEAIBCAQ7BycLFBECBA4FiBAMtx0Ejl+BNwQHgxp0A5dhkU6BXns+gWk X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208,217";a="244031047" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Aug 2013 18:35:05 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r76IZ5lh006492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Aug 2013 18:35:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.110]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 13:35:04 -0500 From: "Carlos Pignataro (cpignata)" To: Anoop Ghanwani Thread-Topic: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt Thread-Index: AQHOkrHz3xVp93R47UCeKgdHLe0C95mIgfHl Date: Tue, 6 Aug 2013 18:35:03 +0000 Message-ID: References: <004401ce9258$a2610e10$e7232a30$@chinamobile.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A9CBA98414544CF7B4CE3AC4131A5424ciscocom_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 18:35:10 -0000 --_000_A9CBA98414544CF7B4CE3AC4131A5424ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There are two other considerations: 1. ICMP packets might follow a different path than the application in the p= resence of ECMP 2. The ICMP responder might rate limit and drop if it's a router regardless= of the drop characteristics of the path -- RFC 6192. Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Aug 6, 2013, at 4:33 PM, "Anoop Ghanwani" > wrote: On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng > wrote: A basic requirement for using ICMP (and other active measurement approaches= ) is to let probing traffic and service traffic have the same drop probabil= ity, though it is usually difficult to guarantee this. It seems like this would be further complicated if something like ECN is in= use. While ECT packets would be marked with CE and thus not contribute to= the loss rate, ICMP packets would end up being discarded. Anoop _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_A9CBA98414544CF7B4CE3AC4131A5424ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
There are two other considerations:

1. ICMP packets might follow a different path than the application in = the presence of ECMP
2. The ICMP responder might rate limit and drop if it's a router regar= dless of the drop characteristics of the path -- RFC 6192. 

Thanks,

Excuze typofraphicak errows

On Aug 6, 2013, at 4:33 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> wrote:




On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng <fanpeng@ch= inamobile.com> wrote:

A basic requirement for using ICMP (and other active measurement approaches= ) is to let probing traffic and service traffic have the same drop probabil= ity, though it is usually difficult to guarantee this.

It seems like this would be further complicated if something like ECN = is in use.  While ECT packets would be marked with CE and thus not con= tribute to the loss rate, ICMP packets would end up being discarded.

Anoop  
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.= ietf.org/mailman/listinfo/opsawg
--_000_A9CBA98414544CF7B4CE3AC4131A5424ciscocom_-- From fanpeng@chinamobile.com Wed Aug 7 01:17:34 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815E921E80FE for ; Wed, 7 Aug 2013 01:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[AWL=1.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_221=2.222] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huyvhrb3p7aL for ; Wed, 7 Aug 2013 01:17:30 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id 527FF21E8083 for ; Wed, 7 Aug 2013 01:17:28 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee25202024f86a-e586a; Wed, 07 Aug 2013 16:16:15 +0800 (CST) X-RM-TRANSID: 2ee25202024f86a-e586a Received: from X6X8D79D8F49E2 (unknown[10.2.43.104]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee15202024d9a8-03fbc; Wed, 07 Aug 2013 16:16:15 +0800 (CST) X-RM-TRANSID: 2ee15202024d9a8-03fbc From: "Fan, Peng" To: "'Carlos Pignataro \(cpignata\)'" , "'Anoop Ghanwani'" References: <004401ce9258$a2610e10$e7232a30$@chinamobile.com>, In-Reply-To: Date: Wed, 7 Aug 2013 16:17:50 +0800 Message-ID: <004c01ce9346$9bd47930$d37d6b90$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01CE9389.A9FEE520" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxPMcNZfi10m5Qg0lkqiAgh/jZpwE64gCqAXoPA4WZrmowwA== Content-Language: zh-cn Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 08:17:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01CE9389.A9FEE520 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Dear Carlos, Anoop, We shall take these items into consideration. The first thing we have to do is to reconsider the scope and architecture of the draft. Thank you for reminding! Regards, Peng From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] Sent: Wednesday, August 07, 2013 2:35 AM To: Anoop Ghanwani Cc: Fan, Peng; opsawg@ietf.org Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt There are two other considerations: 1. ICMP packets might follow a different path than the application in the presence of ECMP 2. The ICMP responder might rate limit and drop if it's a router regardless of the drop characteristics of the path -- RFC 6192. Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Aug 6, 2013, at 4:33 PM, "Anoop Ghanwani" wrote: On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng wrote: A basic requirement for using ICMP (and other active measurement approaches) is to let probing traffic and service traffic have the same drop probability, though it is usually difficult to guarantee this. It seems like this would be further complicated if something like ECN is in use. While ECT packets would be marked with CE and thus not contribute to the loss rate, ICMP packets would end up being discarded. Anoop _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ------=_NextPart_000_004D_01CE9389.A9FEE520 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear Carlos, Anoop,

 

We shall take these items into consideration. The first thing we have = to do is to reconsider the scope and architecture of the draft. Thank = you for reminding!

 

Regards,

Peng

 

From:= Carlos = Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: = Wednesday, August 07, 2013 2:35 AM
To: Anoop = Ghanwani
Cc: Fan, Peng; opsawg@ietf.org
Subject: Re: = [OPSAWG] Fwd: New Version Notification for = draft-fan-opsawg-packet-loss-01.txt

 

There are two other = considerations:

 

1. ICMP packets might follow a = different path than the application in the presence of = ECMP

2. The ICMP responder might rate limit and drop if it's a = router regardless of the drop characteristics of the path -- RFC = 6192. 

 

Thanks,

Thumb typed by Carlos Pignataro. =

Excuze typofraphicak = errows


On Aug 6, 2013, at = 4:33 PM, "Anoop Ghanwani" <anoop@alumni.duke.edu> = wrote:

 

 

On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng <fanpeng@chinamobile.com> = wrote:


A basic requirement for using ICMP (and other active = measurement approaches) is to let probing traffic and service traffic = have the same drop probability, though it is usually difficult to = guarantee this.

 

It seems like this would be further = complicated if something like ECN is in use.  While ECT packets = would be marked with CE and thus not contribute to the loss rate, ICMP = packets would end up being discarded.

 

Anoop =  

_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

------=_NextPart_000_004D_01CE9389.A9FEE520-- From dromasca@avaya.com Wed Aug 7 05:45:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4BA21F9808 for ; Wed, 7 Aug 2013 05:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoWLOSwhZDmd for ; Wed, 7 Aug 2013 05:45:08 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D021F9A04 for ; Wed, 7 Aug 2013 05:45:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFADFAAlLGmAcV/2dsb2JhbABagmUhNVC+R4EcFnSCJAEBAQEDAQEBDyg0FwQCAQgNBAMBAQELFAkHIQYLFAkIAgQBEggMDodcAw8BC5xGkzINiEcTBI0qgj84BoMUdAOVdwGIMoVfhSeBXoE5gio X-IronPort-AV: E=Sophos;i="4.89,833,1367985600"; d="scan'208";a="19211420" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Aug 2013 08:45:02 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Aug 2013 08:41:42 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Wed, 7 Aug 2013 14:45:00 +0200 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Thread-Index: AQHOkiSoFRbPspJMYEGEjdu1L6FohpmJsF3A Date: Wed, 7 Aug 2013 12:45:00 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A6252@AZ-FFEXMB04.global.avaya.com> References: <51F09636.1040102@gmail.com> <52001C2B.7070108@gmail.com> In-Reply-To: <52001C2B.7070108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 12:45:14 -0000 Hi, I support this document and I believe that it is almost ready for submissio= n to the IESG. I have a number of editorial comments, their resolution does= not require IMO to re-do the WGLC.=20 1. In the Abstract:=20 OLD:=20 It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. NEW:=20 It amends that specification by informing the community about the transition of the EFM-CU-MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. 2. In the Introduction:=20 s/the Institute of Electrical and Electronics Engineers (IEEE) [802.3] work= ing group/the Institute of Electrical and Electronics Engineers (IEEE) 802.= 3 [802.3] working group/ 3. Also in the Introduction: In 2011 the IEEE developed IEEE8023-EFM-CU-MIB module, defined in IEEE Std 802.3.1-2011 [802.3.1] and based on the EFM-CU-MIB, defined in RFC 5066. Better drop 'In 2011' - this information is not relevant and is probably no= t accurate, as 2011 is the year of the publication (obvious from the name),= development took longer 4. Also in the Introduction:=20 s/The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules, which = can coexist./ The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexis= t./ 5. In Section 4:=20 OLD:=20 Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3.1 task force mailing list: [stds-802-3-mib@listserv.ieee.org]. NEW:=20 Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 802.3 Working Group. Currently the IEEE 802.3.1=20 task force (chartered with MIB development) mailing list is=20 [stds-802-3-mib@listserv.ieee.org]. 6. Also in section 4:=20 s/jurisdiction/control/ Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Tuesday, August 06, 2013 12:42 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile > Copper (EFMCu) Interfaces MIB" >=20 > Reminder: https://datatracker.ietf.org/doc/draft-ietf-opsawg- > rfc5066bis/ > is in working group last call, which closes August 7. Please have a > look at it and post any comments to the opsawg mailing list. >=20 > Melinda >=20 >=20 > -------- Original Message -------- > Subject: Working group last call on "Ethernet in the First Mile Copper > (EFMCu) Interfaces MIB" > Date: Wed, 24 Jul 2013 11:42:13 -0800 > From: Melinda Shore > To: opsawg@ietf.org >=20 > This is to announce the start of working group last call on: >=20 > Ethernet in the First Mile Copper (EFMCu) Interfaces MIB > https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ >=20 > It is intended for publication as a standards track RFC. >=20 > Please give it a careful read and provide any feedback to this mailing > list by August 7, 2013. >=20 > Thanks, >=20 > opsawg chairs >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Wed Aug 7 07:33:46 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4021E811F for ; Wed, 7 Aug 2013 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIlFuj5L5fwG for ; Wed, 7 Aug 2013 07:33:46 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0508A21E811A for ; Wed, 7 Aug 2013 07:33:45 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so2224781pad.32 for ; Wed, 07 Aug 2013 07:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=B8c1wrqtw6k4wrd13S3wOBRedYFaQ2mIsDGVHOzvITA=; b=vhOZST0WdF0V8FuebkiVsCMFZxpcRZ/Ykd9IyBvAAjTT5+/NlCjVoTWSSAV7ufQcfY 2XeszuwOh2PNB9vSUydQxIBV4fWsw4hVrmpb5Uc4gFtPHueHcWahEmHL2BAQ/W9cXRxX i/Ohd2px+xPM3P41nh6xQt0mryhfrJQx2krk48e9aKsqkSCtEIi2QuY/qZnoiD1iXdLa 8lCkpMI6pRRP4FbHwtHEHP9H2Awom4/lwCEDQT0PHaq7BLWxQfhTq0WjE0BUavesYkOz 9eDo1HsNpoyR7R/vKqLszli2qsStlaxMXralMnl3UGSVflNe6W7wt9loqHxDHyHuWDX+ Hvfg== X-Received: by 10.66.149.73 with SMTP id ty9mr1011319pab.36.1375886025773; Wed, 07 Aug 2013 07:33:45 -0700 (PDT) Received: from spandex.local (66-230-112-160-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.160]) by mx.google.com with ESMTPSA id om2sm8570863pbc.30.2013.08.07.07.33.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 07:33:44 -0700 (PDT) Message-ID: <52025AC6.9050203@gmail.com> Date: Wed, 07 Aug 2013 06:33:42 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] WG last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" closes today X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 14:33:46 -0000 Reminder: working group last call on https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ closes today. Thanks, Chairs From melinda.shore@gmail.com Wed Aug 7 15:49:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B3F21F9DFB for ; Wed, 7 Aug 2013 15:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NohUyh5QepRc for ; Wed, 7 Aug 2013 15:49:00 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 887D421F99F3 for ; Wed, 7 Aug 2013 15:49:00 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id uo5so2458352pbc.9 for ; Wed, 07 Aug 2013 15:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zsIj498XEX/gDWvRuD/+oyT53iuvZ2ha0lRm/J/h3e4=; b=za1rWW9yxw+oHUh3arOcjoIFzIAjYio7O1ryXTX4WBz/L2xIDvdV5omqDK6M7smDcG vDt+Ide1vAmBn9rqG2HflUS3uc+8n79+Zih2Ot7dCpifE6x+SlkPahjhG645wj/F7Khv 3VR3A01GSk+v6W2xuO/ZyM8fCyfeifBxIpzRtyy3geG7rSHo9EsyFWfNX6bcsfi1G9h8 Raed7Mh61zXp5lGoLLgqXt5iCIr5op8FKcL3TMFO+t/L62RfqLOX9c9Yttr85dBxuDqc XuFZtYtcY4syiI440dQ+E0rfb270e213v3kFDmWWKMh7kJ3jMX9rpl2Hb5D3n1DfZ0ob Trcw== X-Received: by 10.68.60.132 with SMTP id h4mr2812670pbr.177.1375915740276; Wed, 07 Aug 2013 15:49:00 -0700 (PDT) Received: from spandex.local (66-230-112-160-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.160]) by mx.google.com with ESMTPSA id om2sm10390951pbc.30.2013.08.07.15.48.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 15:48:59 -0700 (PDT) Message-ID: <5202CED9.2070700@gmail.com> Date: Wed, 07 Aug 2013 14:48:57 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Ping on chair situation X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 22:49:01 -0000 Just checking in to see where things stand with the chair situation. I am trying to close working group last call on the Ethernet MIB and have been getting no responses from the other chairs. Melinda From melinda.shore@gmail.com Wed Aug 7 18:22:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430A711E819A for ; Wed, 7 Aug 2013 18:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JxUiXAqUuMP for ; Wed, 7 Aug 2013 18:22:14 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CD5E111E8190 for ; Wed, 7 Aug 2013 18:22:11 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so2812428pad.9 for ; Wed, 07 Aug 2013 18:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=c7cguMB96lZVZKEYwLZjEmqMuWSiEIaeCdrUDTISzuo=; b=Hd3l+VLQVtfx/2xnmL8r9sol45eGUJrQgAZhiCLhxcnB8rLRQvIQDNu89AwdaNzliZ mWdjUUlJS+RhCPsKDDzH1f9aEeEPVIUkDJBe9+bdyi1+NjhIvWNROxWvwhDJnOCdKfNL 4xWUyMQLxAggOd8cE6btBoW+SqnqL2CNQju4X9E7zuJBh53HCnfjrzWlAW6MkczWHt4C R8aRwZqMFnKKfpS7ExjziNhoHBPf/1GvmLYIJ5/ziPLlJFV48MG/YSpTuQj/aBNH3UaX /39jpqfaR/fOiG8cUUpbXuXa4N2E8EoisFEOi5HIvFO1DD/1TfBU/7iS9cgbvNTm/Ld3 XUcA== X-Received: by 10.66.187.34 with SMTP id fp2mr3446413pac.12.1375924906664; Wed, 07 Aug 2013 18:21:46 -0700 (PDT) Received: from spandex.local (66-230-112-160-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.160]) by mx.google.com with ESMTPSA id s5sm10873615pbo.38.2013.08.07.18.21.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 18:21:45 -0700 (PDT) Message-ID: <5202F2A7.2010606@gmail.com> Date: Wed, 07 Aug 2013 17:21:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" , Edward Beili Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: [OPSAWG] WG last call closed X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 01:22:16 -0000 And thus ends another working group last call, this one for "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/). The only comments were from Dan Romascanu and they were largely editorial, and Ed has said that he's okay with Dan's suggestions. Note that ordinarily we wouldn't be particularly comfortable sending a document through with so little comment from the working group, but this draft is largely procedural, describing the handoff of responsibility for EFM-CU-MIB to IEEE 802. Many thanks to Ed for timely edits and his work on getting it through wg last call. Melinda From ietfc@btconnect.com Thu Aug 8 02:43:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9C11E81CA for ; Thu, 8 Aug 2013 02:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyitHtVsuA7F for ; Thu, 8 Aug 2013 02:43:54 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 44FDC11E8116 for ; Thu, 8 Aug 2013 02:43:53 -0700 (PDT) Received: from mail193-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE004.bigfish.com (10.174.14.67) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Aug 2013 09:43:52 +0000 Received: from mail193-db9 (localhost [127.0.0.1]) by mail193-db9-R.bigfish.com (Postfix) with ESMTP id 4ED6C30006E; Thu, 8 Aug 2013 09:43:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz9371I542I1432I1418I4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail193-db9 (localhost.localdomain [127.0.0.1]) by mail193-db9 (MessageSwitch) id 1375955030604751_25790; Thu, 8 Aug 2013 09:43:50 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.232]) by mail193-db9.bigfish.com (Postfix) with ESMTP id 8FF084E0046; Thu, 8 Aug 2013 09:43:50 +0000 (UTC) Received: from AMXPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.69) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 8 Aug 2013 09:43:49 +0000 Received: from DBXPRD0210HT003.eurprd02.prod.outlook.com (157.56.253.181) by pod51017.outlook.com (10.242.9.165) with Microsoft SMTP Server (TLS) id 14.16.341.1; Thu, 8 Aug 2013 09:43:48 +0000 Message-ID: <02ce01ce941b$ba447700$4001a8c0@gateway.2wire.net> From: t.petch To: "Romascanu, Dan (Dan)" , Melinda Shore , References: <51F09636.1040102@gmail.com> <52001C2B.7070108@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA128A6252@AZ-FFEXMB04.global.avaya.com> Date: Thu, 8 Aug 2013 10:40:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 09:44:00 -0000 Some more editorial suggestions. OLD " With the conclusion of the [HUBMIB] working group, the responsibility for the maintenance and further development of the EFM-CU-MIB module has been transfered to the Institute of Electrical and Electronics Engineers (IEEE) [802.3] working group." NEW " With the conclusion of the [HUBMIB] working group, the responsibility for the maintenance and further development of a MIB module for managing 10PASS-TS and 2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces; has been transfered to the Institute of Electrical and Electronics Engineers (IEEE) [802.3] working group." [I trust that the IEEE will not be reissuing the IETF MIB module!] OLD " The names of the objects in IEEE8023-EFM-CU-MIB are identical to those in EFM-CU-MIB." NEW " The names of the objects in the first version of the IEEE8023-EFM-CU-MIB are identical to those in EFM-CU-MIB." [Again, remove the implied update of the IETF MIB module} OLD becomes the last valid version of that MIB. NEW becomes the last valid version of that MIB module. [It is a MIB module not the MIB - not sure about the valid, I would omit that ] Overall, I think that the thrust is right, which I did not say about version -00. Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Melinda Shore" ; Sent: Wednesday, August 07, 2013 1:45 PM > Hi, > > I support this document and I believe that it is almost ready for submission to the IESG. I have a number of editorial comments, their resolution does not require IMO to re-do the WGLC. > > 1. In the Abstract: > > OLD: > > It amends that specification by > informing the internet community about the transition of the EFM-CU- > MIB module from the IETF Ethernet Interfaces and Hub MIB Working > Group to the Institute of Electrical and Electronics Engineers (IEEE) > 802.3 working group. > > NEW: > > It amends that specification by > informing the community about the transition of the EFM-CU-MIB > module from the concluded IETF Ethernet Interfaces and Hub MIB Working > Group to the Institute of Electrical and Electronics Engineers (IEEE) > 802.3 working group. > > 2. In the Introduction: > > s/the Institute of Electrical and Electronics Engineers (IEEE) [802.3] working group/the Institute of Electrical and Electronics Engineers (IEEE) 802.3 [802.3] working group/ > > 3. Also in the Introduction: > > In 2011 the IEEE developed > IEEE8023-EFM-CU-MIB module, defined in IEEE Std 802.3.1-2011 > [802.3.1] and based on the EFM-CU-MIB, defined in RFC 5066. > > Better drop 'In 2011' - this information is not relevant and is probably not accurate, as 2011 is the year of the publication (obvious from the name), development took longer > > 4. Also in the Introduction: > > s/The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules, which can coexist./ The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist./ > > 5. In Section 4: > > OLD: > > Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD > be sent to the IEEE 803.3.1 task force mailing list: > [stds-802-3-mib@listserv.ieee.org]. > > NEW: > > Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD > be sent to the IEEE 802.3 Working Group. Currently the IEEE 802.3.1 > task force (chartered with MIB development) mailing list is > [stds-802-3-mib@listserv.ieee.org]. > > 6. Also in section 4: > > s/jurisdiction/control/ > > > Regards, > > Dan > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > > Of Melinda Shore > > Sent: Tuesday, August 06, 2013 12:42 AM > > To: opsawg@ietf.org > > Subject: [OPSAWG] Working group last call on "Ethernet in the First Mile > > Copper (EFMCu) Interfaces MIB" > > > > Reminder: https://datatracker.ietf.org/doc/draft-ietf-opsawg- > > rfc5066bis/ > > is in working group last call, which closes August 7. Please have a > > look at it and post any comments to the opsawg mailing list. > > > > Melinda > > > > > > -------- Original Message -------- > > Subject: Working group last call on "Ethernet in the First Mile Copper > > (EFMCu) Interfaces MIB" > > Date: Wed, 24 Jul 2013 11:42:13 -0800 > > From: Melinda Shore > > To: opsawg@ietf.org > > > > This is to announce the start of working group last call on: > > > > Ethernet in the First Mile Copper (EFMCu) Interfaces MIB > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ > > > > It is intended for publication as a standards track RFC. > > > > Please give it a careful read and provide any feedback to this mailing > > list by August 7, 2013. > > > > Thanks, > > > > opsawg chairs > > > > > > From ietfdbh@comcast.net Thu Aug 8 13:33:46 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A288811E820E for ; Thu, 8 Aug 2013 13:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrI1oSESP-x8 for ; Thu, 8 Aug 2013 13:33:40 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1931B11E81F0 for ; Thu, 8 Aug 2013 13:33:40 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta14.emeryville.ca.mail.comcast.net with comcast id AL9B1m0050cQ2SLAELZf0c; Thu, 08 Aug 2013 20:33:39 +0000 Received: from [192.168.1.181] ([176.96.153.9]) by omta10.emeryville.ca.mail.comcast.net with comcast id ALZJ1m00J0CRbBk8WLZNEL; Thu, 08 Aug 2013 20:33:37 +0000 User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 08 Aug 2013 22:33:17 +0200 From: David Harrington To: "t.petch" , "Romascanu, Dan (Dan)" , Melinda Shore , Message-ID: Thread-Topic: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" In-Reply-To: <02ce01ce941b$ba447700$4001a8c0@gateway.2wire.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375994019; bh=+UmBF84/bKLxTNB9oHezvPGzOIiwNnwN0oPfJQA6O4Y=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=RRhA77tkgx5N7474UXhEaVnF5amtbZJFGDNXDbX59J6WtV9ZaiO/bZq/XZBqAWP0T 0y+0b8Dpr0gFLKR3fFMicpj2tO3p/b2EEZkQZGW4oxkMKtodtlrFigHtKGvSnKe0Q1 1DZDUpvUxMxm9ZlzoWZXxR2nf7obxr0tSbqbAMoGOftcUrIV4P+yHWx464V+1/QaFo HFwHb+ZtIqAlcMjt7YdsGMzAQiYBz/HS4lHDpT6em9MsD/w1fIr1Nk5ZuNZCSxu/i4 ibAPNSa4m5mCUaGy/hrFugS8c5AArSnmpa8JRiseeVDd9l2OtIo4f9COrES+O0PWSI af9u1d9W8WVDw== Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:33:46 -0000 Hi, Are they really identically named objects in different modules? I think that may be illegal per rfc2578 section 3.6. On 8/8/13 11:40 AM, "t.petch" wrote: > >OLD >" The names of the objects in IEEE8023-EFM-CU-MIB are identical to > those in EFM-CU-MIB." >NEW >" The names of the objects in the first version of the >IEEE8023-EFM-CU-MIB are identical to > those in EFM-CU-MIB." >[Again, remove the implied update of the IETF MIB module} > -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 > From ietfc@btconnect.com Fri Aug 9 03:54:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91B221F9F31 for ; Fri, 9 Aug 2013 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[AWL=1.490, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiCDfPYbmT-B for ; Fri, 9 Aug 2013 03:53:57 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 177F221F997A for ; Fri, 9 Aug 2013 03:53:53 -0700 (PDT) Received: from mail215-co9-R.bigfish.com (10.236.132.248) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 10:53:52 +0000 Received: from mail215-co9 (localhost [127.0.0.1]) by mail215-co9-R.bigfish.com (Postfix) with ESMTP id A8FBF1A01CF; Fri, 9 Aug 2013 10:53:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I1418Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail215-co9 (localhost.localdomain [127.0.0.1]) by mail215-co9 (MessageSwitch) id 1376045630857809_25399; Fri, 9 Aug 2013 10:53:50 +0000 (UTC) Received: from CO9EHSMHS015.bigfish.com (unknown [10.236.132.234]) by mail215-co9.bigfish.com (Postfix) with ESMTP id CD52A100032; Fri, 9 Aug 2013 10:53:50 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by CO9EHSMHS015.bigfish.com (10.236.130.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 10:53:50 +0000 Received: from AMXPRD0310HT005.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.341.1; Fri, 9 Aug 2013 10:53:34 +0000 Message-ID: <011b01ce94ee$a374ef40$4001a8c0@gateway.2wire.net> From: t.petch To: David Harrington , "Romascanu, Dan (Dan)" , Melinda Shore , References: Date: Fri, 9 Aug 2013 11:53:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:54:04 -0000 ----- Original Message ----- From: "David Harrington" To: "t.petch" ; "Romascanu, Dan (Dan)" ; "Melinda Shore" ; Sent: Thursday, August 08, 2013 9:33 PM > Hi, > > Are they really identically named objects in different modules? > I think that may be illegal per rfc2578 section 3.6. Probably. I cannot get access to the IEEE drafts and so do not know what they have done. My NEW text was to remove the implicit updates to the IETF module - I took the wording about the IEEE module as given in the I-D. (Of course, if they had retained the OIDs and changed the descriptors, as an intermediate step, then that would be fine:-) There is a weasel words get out in that RFC2578 could be taken as a MUST only for an IETF MIB module, whereas this will not be such, but rather an IEEE MIB module, but I would not regard that as very satisfactory. We need an IEEE liaison/member to give us sight of what has been done; or else an e-mail to the listserv address given in the I-D. Tom Petch > On 8/8/13 11:40 AM, "t.petch" wrote: > > > >OLD > >" The names of the objects in IEEE8023-EFM-CU-MIB are identical to > > those in EFM-CU-MIB." > >NEW > >" The names of the objects in the first version of the > >IEEE8023-EFM-CU-MIB are identical to > > those in EFM-CU-MIB." > >[Again, remove the implied update of the IETF MIB module} > > > > -- > David Harrington > Ietfdbh@comcast.net > +1-603-828-1401 > > > > > > > From j.schoenwaelder@jacobs-university.de Fri Aug 9 05:36:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A746321F9F5C for ; Fri, 9 Aug 2013 05:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOyt-p-AaXJT for ; Fri, 9 Aug 2013 05:36:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 365F721F9F31 for ; Fri, 9 Aug 2013 05:36:06 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4176520BE8; Fri, 9 Aug 2013 14:36:03 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id YxJxx3E_6eJ3; Fri, 9 Aug 2013 14:36:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A208220C12; Fri, 9 Aug 2013 14:36:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2765E27C3FAB; Fri, 9 Aug 2013 14:35:58 +0200 (CEST) Date: Fri, 9 Aug 2013 14:35:58 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20130809123557.GB13512@elstar.local> Mail-Followup-To: "t.petch" , David Harrington , "Romascanu, Dan (Dan)" , Melinda Shore , opsawg@ietf.org References: <011b01ce94ee$a374ef40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011b01ce94ee$a374ef40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 12:36:21 -0000 On Fri, Aug 09, 2013 at 11:53:01AM +0100, t.petch wrote: > ----- Original Message ----- > From: "David Harrington" > To: "t.petch" ; "Romascanu, Dan (Dan)" > ; "Melinda Shore" ; > > Sent: Thursday, August 08, 2013 9:33 PM > > > Hi, > > > > Are they really identically named objects in different modules? > > I think that may be illegal per rfc2578 section 3.6. > > Probably. I cannot get access to the IEEE drafts and so do not know > what they have done. My NEW text was to remove the implicit updates to > the IETF module - I took the wording about the IEEE module as given in > the I-D. (Of course, if they had retained the OIDs and changed the > descriptors, as an intermediate step, then that would be fine:-) > > There is a weasel words get out in that RFC2578 could be taken as a MUST > only for an IETF MIB module, whereas this will not be such, but rather > an IEEE MIB module, but I would not regard that as very satisfactory. > Back in a day, SNMP tools often could not deal with descriptors that need to be scoped by a module name. This, of course, is broken. Not surprising, the rule in RFC 2578 did not encourage tool writers to fix their tools. Unless SNMP tools have improved significantly in the last few years, I would rather suggest to keep descriptors unique if there is a need to copy things. (In fact, copying definitions just for the sake of having them registered in a different branch likely fails on the cost/benefit analysis badly since management applications will have to look for two possible OIDs now for the next N years to deal with the transition.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From melinda.shore@gmail.com Mon Aug 12 10:41:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4021F992B for ; Mon, 12 Aug 2013 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Q1U4ftdCq1W for ; Mon, 12 Aug 2013 10:41:30 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id CA55321F9BFF for ; Mon, 12 Aug 2013 10:39:29 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md4so5913745pbc.2 for ; Mon, 12 Aug 2013 10:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=54wJNMe57hx3nWOeV7vznkso1hmb2n11QI68y0XuWKg=; b=yCgDShXXHCpMedt1CB7rYBI0dZcszd2z/dSWIGB+pZEc8Sx2JNsfMQHVod1q9MlL2r KsIKKmvaLmm33R3DK1jgiu8tsCLVHZqb1F7q7yUQV/oxOfGSwDB6uPUBEdViYb4G4cBU XBPeAgijRzyuIdeKrUbTyaZrMUWn2XM+p6bDMtNNN2t7IDGjCHZuYhtbw9kMMLfOpY79 m2f/+37e7UmOvgAFMkztkaBD/S80NHDW4dhKLz29i8pOlpD3kR7R0jxgJMv8BrLt9SAt 3orvwbTfdRWS+CXlwREOVUu+Egk9bypogWCd53I2xMJB7obg3jkfWrPcWIRKl0AN5gGa 6UPw== X-Received: by 10.66.218.74 with SMTP id pe10mr172782pac.177.1376329160869; Mon, 12 Aug 2013 10:39:20 -0700 (PDT) Received: from spandex.local (66-230-112-160-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.112.160]) by mx.google.com with ESMTPSA id 7sm41302515paf.22.2013.08.12.10.39.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 10:39:19 -0700 (PDT) Message-ID: <52091DC5.9080104@gmail.com> Date: Mon, 12 Aug 2013 09:39:17 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: [OPSAWG] Fwd: NOMS 2014 Call for Papers X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:41:56 -0000 -------- Original Message -------- Subject: NOMS 2014 Call for Papers Date: Mon, 12 Aug 2013 13:24:34 -0400 From: Thomas Nadeau To: discussion ietf@ietf.org http://noms2014.ieee-noms.org/content/call-experience-session-papers http://www.ieee-noms.org/ NOMS 2014 will be next year's IEEE flagship conference in the area of management of networked systems and services. The symposium will include an Experience Session program. Experience Sessions complement the Technical Sessions with contributions that emphasize practical experiences and lessons learnt in applying, implementing, and deploying management technology. They will focus on aspects such as real-world deployment scenarios, experiences with the management of new services and technology, industrial applications of management technology, implementation experiences, and organizational considerations. Experience sessions are particularly aimed at decision makers and experts from industry. New this year and for the first time at NOMS, the best Experience Paper will be recognized with an award. Topics of interest NOMS 2014's theme is "Management in a Software Defined World". NOMS 2014 will place particular emphasis on Software Defined Networking and related technologies; submissions in those areas are particularly encouraged. Specific topics include but are not limited to the ones listed below. Please refer also to the general Call for Papers. • Management case studies and best practices • Issues and experiences with practical deployments • Software Defined Networks and enabling technologies • Open source SDN frameworks, Open Daylight • Experiences with OpenFlow deployments • Orchestration and SDN controllers • Network Function Virtualization implementations • Data center automation • Management of cloud • Cloud service assurance • Big Data analytics in management • Management of virtualized environments • OSS/BSS development • Virtualization of operation centers and help desks • Organizational aspects of IT service management • IT governance • Service engineering and operational challenges • Management of emerging networks and services • Green management and managing energy efficiency • Smart buildings, industrial automation and management • Experiences with autonomic networking and self-management • Application of machine learning and data mining to management • Advances in standardization • Management information models • Event correlation, diagnostics, fault, performance management • Billing and accounting models and service level management • Business alignment of IT service management • Experiences with Call Home frameworks • Managed service provider issues • Service delivery and service assurance • Experiences with process engineering and frameworks (ITIL, eTOM) • Other topics in network and service operations and management From dromasca@avaya.com Tue Aug 13 07:02:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08A21E8144 for ; Tue, 13 Aug 2013 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJrX9nKy75I5 for ; Tue, 13 Aug 2013 07:02:27 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55211E814D for ; Tue, 13 Aug 2013 07:02:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAGADk7ClKHCzI1/2dsb2JhbABYA4JlITVQqk2UDoEgFnSCJAEBAQECARIoPwUHAgICAQgNAQIBBAEBAQoUCQcbBhEUCQgCBAENBQgRCYdcAwkGAZt+kxAIBYheBI1BgkYhEAcGC4MKdgOVegGDFoUehV+FJ4FhgTqCKg X-IronPort-AV: E=Sophos;i="4.89,869,1367985600"; d="scan'208";a="23425533" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Aug 2013 10:02:22 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Aug 2013 09:55:22 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Tue, 13 Aug 2013 16:02:20 +0200 From: "Romascanu, Dan (Dan)" To: Juergen Schoenwaelder , t.petch Thread-Topic: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" Thread-Index: AQHOkiSoFRbPspJMYEGEjdu1L6FohpmJsF3AgAFi8saAAJPngIABEgbm///68gCABnXiUA== Date: Tue, 13 Aug 2013 14:02:20 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128A9591@AZ-FFEXMB04.global.avaya.com> References: <011b01ce94ee$a374ef40$4001a8c0@gateway.2wire.net> <20130809123557.GB13512@elstar.local> In-Reply-To: <20130809123557.GB13512@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:02:40 -0000 Well, copying the IETF MIB modules with all the names 'as-is' excepting the= names of the MIB modules and the names of the sub-branches is what the IEE= E 802.3 seem to have done, including in the revised IEEE 802.3.1 which was = just approved. I asked Howard Frazier for a copy of the MIB modules in the = recently approved document for confirmation.=20 Section 3.1 of RFC 2578 says:=20 > The set of descriptors defined in all "standard" information modules shall be unique. Allegedly IEEE 802.3 MIB modules are not IETF "standards". From this perspe= ctive what they have done is not 'illegal'. They may have thought that they= are actually making life of some of the management applications easier in = transition, as they will continue to use the same names, just load a differ= ent MIB module.=20 Question is what we do at this point. The I-D we have just Last Called refl= ects the reality - good or bad.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Friday, August 09, 2013 3:36 PM > To: t.petch > Cc: David Harrington; Romascanu, Dan (Dan); Melinda Shore; > opsawg@ietf.org > Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First > Mile Copper (EFMCu) Interfaces MIB" >=20 > On Fri, Aug 09, 2013 at 11:53:01AM +0100, t.petch wrote: > > ----- Original Message ----- > > From: "David Harrington" > > To: "t.petch" ; "Romascanu, Dan (Dan)" > > ; "Melinda Shore" ; > > > > Sent: Thursday, August 08, 2013 9:33 PM > > > > > Hi, > > > > > > Are they really identically named objects in different modules? > > > I think that may be illegal per rfc2578 section 3.6. > > > > Probably. I cannot get access to the IEEE drafts and so do not know > > what they have done. My NEW text was to remove the implicit updates > > to the IETF module - I took the wording about the IEEE module as given > > in the I-D. (Of course, if they had retained the OIDs and changed the > > descriptors, as an intermediate step, then that would be fine:-) > > > > There is a weasel words get out in that RFC2578 could be taken as a > > MUST only for an IETF MIB module, whereas this will not be such, but > > rather an IEEE MIB module, but I would not regard that as very > satisfactory. > > >=20 > Back in a day, SNMP tools often could not deal with descriptors that > need to be scoped by a module name. This, of course, is broken. Not > surprising, the rule in RFC 2578 did not encourage tool writers to fix > their tools. >=20 > Unless SNMP tools have improved significantly in the last few years, I > would rather suggest to keep descriptors unique if there is a need to > copy things. (In fact, copying definitions just for the sake of having > them registered in a different branch likely fails on the cost/benefit > analysis badly since management applications will have to look for two > possible OIDs now for the next N years to deal with the transition.) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 13 07:27:42 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21F121E816C for ; Tue, 13 Aug 2013 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AheFQ1RRWKfc for ; Tue, 13 Aug 2013 07:27:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7F6511E8176 for ; Tue, 13 Aug 2013 07:27:13 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1DEB20BD9; Tue, 13 Aug 2013 16:27:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id txTF5NtSQ3y6; Tue, 13 Aug 2013 16:27:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 523AD20BCD; Tue, 13 Aug 2013 16:27:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7030527DC31D; Tue, 13 Aug 2013 16:27:06 +0200 (CEST) Date: Tue, 13 Aug 2013 16:27:05 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20130813142705.GA86950@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "t.petch" , David Harrington , Melinda Shore , "opsawg@ietf.org" References: <011b01ce94ee$a374ef40$4001a8c0@gateway.2wire.net> <20130809123557.GB13512@elstar.local> <9904FB1B0159DA42B0B887B7FA8119CA128A9591@AZ-FFEXMB04.global.avaya.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA128A9591@AZ-FFEXMB04.global.avaya.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Working group last call on "Ethernet in the First Mile Copper (EFMCu) Interfaces MIB" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2013 14:27:42 -0000 On Tue, Aug 13, 2013 at 02:02:20PM +0000, Romascanu, Dan (Dan) wrote: > Well, copying the IETF MIB modules with all the names 'as-is' excepting the names of the MIB modules and the names of the sub-branches is what the IEEE 802.3 seem to have done, including in the revised IEEE 802.3.1 which was just approved. I asked Howard Frazier for a copy of the MIB modules in the recently approved document for confirmation. > > Section 3.1 of RFC 2578 says: > > > The set of descriptors defined in all "standard" information modules > shall be unique. > > Allegedly IEEE 802.3 MIB modules are not IETF "standards". From this perspective what they have done is not 'illegal'. They may have thought that they are actually making life of some of the management applications easier in transition, as they will continue to use the same names, just load a different MIB module. > > Question is what we do at this point. The I-D we have just Last Called reflects the reality - good or bad. > Well, then this is what they did. Document it - perhaps add a warning that tools must to be able to deal with prefixed descriptors since descriptors are for sure not unique anymore if if both old (pre IEEE) and new MIB modules need to be supported. But then, people will also figure this out quickly once they try and perhaps tools have generally improved to deal with this situation better than in the past. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From melinda.shore@gmail.com Sun Aug 18 16:25:58 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270921F9BD5 for ; Sun, 18 Aug 2013 16:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCnGmNPvPzJi for ; Sun, 18 Aug 2013 16:25:58 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4A27D21F93E4 for ; Sun, 18 Aug 2013 16:25:58 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y10so4318294pdj.39 for ; Sun, 18 Aug 2013 16:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KId8kkQkL2yCMu0oe45ZDtRaIgT1De5na/UeE9ZdgRk=; b=VQjsMgxxuwuKAXRTYtcLncTCs0v6YmICfj109bZOrrFnw8/zM+bVdSDIuZQVlCyR82 QUV09w/g1ItPJJJr5KprJYIOO0kwZFIkvCbVXFD7AILVZ6hKtYKKvKWpe40jqELcYgMs Pn+XkVVvfwNgUJwBlkhaxWoASrX1O2sJN2RQU0SktDcTIOa+KQBnp9eg+qCX1LI6xAi6 45eukDypUNawqThjokZ1y5PfayeqDRVdFMjW+R9PMXKZEdrhs/X2d4IwzfXvPt7nGjd4 X+7D2EuAp2QABZoiWceaxg+/kovx1xktBP7Axw0lgHyKfbh2zlInZCN8AjCcAIfPbtQV g9uQ== X-Received: by 10.66.233.37 with SMTP id tt5mr10091174pac.95.1376868357906; Sun, 18 Aug 2013 16:25:57 -0700 (PDT) Received: from spandex.local (66-230-88-161-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.88.161]) by mx.google.com with ESMTPSA id qf7sm11759123pac.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 18 Aug 2013 16:25:56 -0700 (PDT) Message-ID: <52115802.1030500@gmail.com> Date: Sun, 18 Aug 2013 15:25:54 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <52006E4E.8040003@gmail.com> In-Reply-To: <52006E4E.8040003@gmail.com> X-Forwarded-Message-Id: <52006E4E.8040003@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Reminder: Working group last call on "CGN Deployment with BGP/MPLS IP VPNs" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 23:25:58 -0000 This is a reminder that working group last call on "CGN Deployment with BGP/MPLS IP VPNs" closes tomorrow (19 August). We've gotten very little comment (that is to say, none) on this last call. This is also a reminder for people who are interested in developing their careers within the IETF and eventually moving into leadership positions that one of the things you can do both to help the organization move our work along and to draw attention to your expertise is to review documents and post comments, certainly while a document is under development but also when a document goes into working group last call. Here's a chance to help out. Thanks, Melinda -------- This is to announce the start of working group last call on: CGN Deployment with BGP/MPLS IP VPNs https://datatracker.ietf.org/doc/draft-ietf-opsawg-lsn-deployment/ It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list by August 12^H^H19, 2013. Thanks, opsawg chairs From jclarke@cisco.com Sun Aug 18 16:28:47 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB711E8186 for ; Sun, 18 Aug 2013 16:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t43yIBx79VcF for ; Sun, 18 Aug 2013 16:28:42 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F41A411E80AD for ; Sun, 18 Aug 2013 16:28:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7INSdOC025274 for ; Mon, 19 Aug 2013 01:28:40 +0200 (CEST) Received: from rtp-jclarke-8912.cisco.com (rtp-jclarke-8912.cisco.com [10.117.46.163]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7INSdVx009280 for ; Sun, 18 Aug 2013 19:28:39 -0400 (EDT) Message-ID: <521158A7.2090407@cisco.com> Date: Sun, 18 Aug 2013 19:28:39 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: opsawg@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Comments on draft-asai-vmm-mib-04 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 23:28:47 -0000 Sorry for the big delay between IETF-87 and now. I wanted to officially record my comments about this proposed MIB module on the mailing list to backup what I said on the mic in the working group session. Please see JMC below. Section 1: 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. JMC: While I think the intention is to say that this MIB pulls from other, existing MIBs for common virtualization platforms, it may come across as being limited to only those platforms. Perhaps it is good to say that this MIB then attempts to generalize those modules to support other hypervisors as well? Section 3.3: Concerning vmTable JMC: I think there should be an object in this table such as vmMgmtAddr, which lists the management IP address of the VM. This would be akin to what one would see in vCenter for a VMware-controlled VM. As a manager, this would be very useful in being able to discover other potential SNMP agents in the network. JMC: The purpose of this MIB is not to provide configuration of the hypervisor. Quoting section 3.2: "The MIB module provides a few writable objects that can be used to make non-persistent changes, e.g., changing the memory allocation or the CPU allocation. It is not the goal of this MIB module to provide a configuration interface for virtual machines since other protocols and data modeling languages are more suitable for this task." To that end, I find objects like vmAutoStart, vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, vmAutoStart mentions the word "configuration" in its description. And the other objects, at least from a VMware standpoint are actually specified in the VM's configuration. One would have to, for example, shutdown the VM to increase the number of vCPUs allocated to the VM. Therefore, I feel all of these objects represent persistent changes to the hypervisor in support of the respective VM. I think these objects should go away and only the read-only objects showing current vCPU allocation, affinity, and memory stats should remain. As for auto-start, that can be read-only. The alternative is to say that some persistent changes will be allowed (such as auto-start), but general VM resource configuration will be out of scope. Section 3.3: vmNetworkEntry OBJECT-TYPE SYNTAX VmNetworkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry for one virtual storage device attached to the virtual machine." INDEX { vmIndex, vmNetworkIndex } ::= { vmNetworkTable 1 } JMC: Note how the description describes this as "storage" device... Section 3.3: Concerning vmNetworkTable. JMC: I think there should be a vmNetworkVlan object in this table that describes the VLAN ID associated to the underlying interface. This need not be used for every hypervisor, but I think it is very important in some (like VMware). JMC: What would one expect if I have a VM connected to multiple vSwitches in a VMware environment? What object will tell me to what vSwitch I am connected? Should there also be a name here for the virtual interface? I'm thinking of the case where something like a Cisco Nexus 1000v switch is used. In that case, knowing that I am connected to Ethernet1/1 might be useful. JMC: Like in the VM table, I wonder if it makes sense to have a network management address for the case where the associated virtual network device can be independently managed. Section 3.3: Concerning vmNotifications. JMC: I think there should be a general notification for VM changing state. The reason for this is that some of the state transitions described in section 3.2 Figure 2 can take a long time (e.g., running -> shuttingdown -> shutdown). In that case, an administrator may have to wait minutes before being alerted to the fact that her VM is offline. If there was a notification for vmStateChange, then the admin would be notified immediately if a VM entered a degraded state. I think that's all I noticed. Thanks. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From Ted.Lemon@nominum.com Mon Aug 19 07:43:19 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D851711E827E for ; Mon, 19 Aug 2013 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9krL7WipKVG for ; Mon, 19 Aug 2013 07:43:13 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C732311E828E for ; Mon, 19 Aug 2013 07:43:12 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUhIu/kDOLp4KRx4eo06jiV+oaXgsJ6nK@postini.com; Mon, 19 Aug 2013 07:43:12 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 4CCBA1B8282 for ; Mon, 19 Aug 2013 07:43:10 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0187319005D; Mon, 19 Aug 2013 07:43:09 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 07:43:09 -0700 From: Ted Lemon To: "trill-chairs@tools.ietf.org" , "" , "l2tpext-chairs@tools.ietf.org" , "" Thread-Topic: Conflict review on draft-pfaff-ovsdb-proto-02 Thread-Index: AQHOnOpss6wGNBcXP02sCgcU7pXu8A== Date: Mon, 19 Aug 2013 14:43:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <62B09D848A88B145A95D11ED6265A5F7@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 14:43:20 -0000 I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which is = proposed for publication in the independent stream. I think this document= does not conflict with the work that you are doing, but I would appreciate= it if you could take a quick look at the document and make sure that you a= gree with me. http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02 Thanks! From cpignata@cisco.com Mon Aug 19 10:16:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE42D11E8142 for ; Mon, 19 Aug 2013 10:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1ddIFlWHS5f for ; Mon, 19 Aug 2013 10:16:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9B08021F9633 for ; Mon, 19 Aug 2013 10:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1369; q=dns/txt; s=iport; t=1376932577; x=1378142177; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=b1HqaSpitPlRYzoYrgLkJeNqlHZsqdlPk9D0I3mTVqc=; b=ZfIjcQza4eMuAF7b0f3TwhCKgGwnV8TWwoLzhLC8R46HulJzHr2OSMFq U+70/Px2C40alERr9KFfS1pzoMVAh1h+JGx+/7/FVt0ZJCCfvnob9Cp+U yWjRoojM9fmeOyIRTt+Cc6SAJJaG/qBkj1WFwCKubStLruoLcW60ISgSp 4=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAIFRElKtJV2b/2dsb2JhbABagwc1UYJTvF+BIxZ0giQBAQEDAXkFCwIBCA4KCiQyJQIEDgUIBod8Bgy2LZAvMQeDG3cDkBaBLodNkCiDHIIq X-IronPort-AV: E=Sophos;i="4.89,914,1367971200"; d="asc'?scan'208";a="249056600" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Aug 2013 17:16:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7JHGGu3029341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 19 Aug 2013 17:16:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.83]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 19 Aug 2013 12:16:16 -0500 From: "Carlos Pignataro (cpignata)" To: Ignacio Goyret Thread-Topic: Conflict review on draft-pfaff-ovsdb-proto-02 Thread-Index: AQHOnOpss6wGNBcXP02sCgcU7pXu8JmcwHHbgABZKQA= Date: Mon, 19 Aug 2013 17:16:15 +0000 Message-ID: <95067C434CE250468B77282634C96ED3240CB729@xmb-aln-x02.cisco.com> References: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominum.com> <201308191656.r7JGuYWp015221@cliff.eng.ascend.com> In-Reply-To: <201308191656.r7JGuYWp015221@cliff.eng.ascend.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.52] Content-Type: multipart/signed; boundary="Apple-Mail=_4DEDBD92-5A85-48A4-BC9B-E54A02E78448"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "" , "" , "trill-chairs@tools.ietf.org" , Ted Lemon , "l2tpext-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:16:23 -0000 --Apple-Mail=_4DEDBD92-5A85-48A4-BC9B-E54A02E78448 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree -- I see no conflict with l2tpext work. -- Carlos. On Aug 19, 2013, at 12:54 PM, Ignacio Goyret = wrote: > I don't see any conflict with l2tpext wg work. > -Ignacio >=20 > At 07:43 8/19/2013, Ted Lemon wrote: >> I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, = which is proposed for publication in the independent stream. I think = this document does not conflict with the work that you are doing, but I = would appreciate it if you could take a quick look at the document and = make sure that you agree with me. >>=20 >> http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02 >>=20 >> Thanks! >=20 --Apple-Mail=_4DEDBD92-5A85-48A4-BC9B-E54A02E78448 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlISUt4ACgkQtfDPGTp3USyH4wCgzwGU9ZP1sFNYzDkYqO0ILb1G V5sAn0BaOGV/stGnrJjqWvMTg6moMYF8 =k7+3 -----END PGP SIGNATURE----- --Apple-Mail=_4DEDBD92-5A85-48A4-BC9B-E54A02E78448-- From mrm@vmware.com Mon Aug 19 10:55:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09F411E829B for ; Mon, 19 Aug 2013 10:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXwEyfa7nwFn for ; Mon, 19 Aug 2013 10:55:38 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8374F11E823D for ; Mon, 19 Aug 2013 10:55:38 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 1915F28097; Mon, 19 Aug 2013 10:55:38 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 188E81825D; Mon, 19 Aug 2013 10:55:38 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 08967E0110; Mon, 19 Aug 2013 10:55:38 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 10:55:37 -0700 (PDT) Date: Mon, 19 Aug 2013 10:55:37 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <70713209.32796209.1376934937834.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe-1 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: g6qn5cIZfUip9tv9M0vODJGdsi6UGw== Cc: opsawg@ietf.org Subject: [OPSAWG] VMM-MIB: Proposal: Joe-1 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:55:44 -0000 Hi Joe, Thanks for sharing this, my comments inline. Marking this item as Proposal: Joe-1 > JMC: While I think the intention is to say that this MIB pulls from > other, existing MIBs for common virtualization platforms, it may come > across as being limited to only those platforms. Perhaps it is good to > say that this MIB then attempts to generalize those modules to support > other hypervisors as well? So is this just the wording that concerns you? Juergen and others have raised generalization issue/asked others to contribute. Regards, Mike MacFaden From mrm@vmware.com Mon Aug 19 11:02:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B906111E82C3 for ; Mon, 19 Aug 2013 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSUSXId1TDeJ for ; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id AE60F11E82C5 for ; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id A76C728097; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id A759118326; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 96855E00D3; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 11:02:15 -0700 (PDT) Date: Mon, 19 Aug 2013 11:02:15 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <742382451.32805118.1376935335411.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VM-MIB: Proposal: Joe-2 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: BiY3mVC8J2v7zhFTjjqgQdQb+RLiaA== Cc: opsawg@ietf.org Subject: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:02:21 -0000 Marking this item as Proposal: Joe-2 > JMC: I think there should be an object in this table such as vmMgmtAddr, > which lists the management IP address of the VM. This would be akin to > what one would see in vCenter for a VMware-controlled VM. As a manager, > this would be very useful in being able to discover other potential SNMP > agents in the network. Do you want this managed object to report only if there is a configured mgmt agent running in the guest OS(GOS)? There can be more than one mgmt address per address family. So I did something similar in VMware ESXi 5.1 for the hypervisor and its relation to the hardware it is installed on. With blade servers, Cisco ISR, or Cisco UCS or the new HP Gen8 hardware for example it was clear to me there were going to be multiple SNMP agents and so to ease mgmt apps discovery I made it simple for hardware vendors to insert conceptual rows into entLogicalTable/RFC 4133 so that ESXi SNMP can point back to the supervisor card or other embedded hardware mgmt agent. An example from the wild...(not a marketing pitch) To discover the mgmt address hypervisor's snmp agent if a mgmt app has first discovered the hardare agent, poll RFC 4133 SNMPv2-MIB::sysDescr.0 = STRING: Integrated Lights-Out 4 1.10 Jul 17 2012 SNMPv2-MIB::sysObjectID.0 = OID: CPQHOST-MIB::compaq.9.4.10 .... ENTITY-MIB::entPhysicalIndex.1 = INTEGER: 1 ENTITY-MIB::entPhysicalDescr.1 = STRING: HP ProLiant BL460c Gen8 ENTITY-MIB::entPhysicalVendorType.1 = OID: SNMPv2-SMI::zeroDotZero ENTITY-MIB::entPhysicalContainedIn.1 = INTEGER: 0 ENTITY-MIB::entPhysicalClass.1 = INTEGER: backplane(4) ENTITY-MIB::entPhysicalParentRelPos.1 = INTEGER: -1 ENTITY-MIB::entPhysicalName.1 = STRING: smbios ENTITY-MIB::entPhysicalHardwareRev.1 = STRING: ENTITY-MIB::entPhysicalFirmwareRev.1 = STRING: I31 ENTITY-MIB::entPhysicalSoftwareRev.1 = STRING: ENTITY-MIB::entPhysicalSerialNum.1 = STRING: USE246M0JN ENTITY-MIB::entPhysicalMfgName.1 = STRING: HP ENTITY-MIB::entPhysicalModelName.1 = STRING: ProLiant BL460c Gen8 ENTITY-MIB::entPhysicalAlias.1 = STRING: ENTITY-MIB::entPhysicalAssetID.1 = STRING: ENTITY-MIB::entPhysicalIsFRU.1 = INTEGER: true(1) ENTITY-MIB::entPhysicalMfgDate.1 = STRING: 2012-8-20 ENTITY-MIB::entPhysicalUris.1 = STRING: "urn:uuid:30313436-3631-5355-4532-34364d304a4e" ENTITY-MIB::entLogicalIndex.1 = INTEGER: 1 ENTITY-MIB::entLogicalDescr.1 = STRING: ESXi 5.1.0 Releasebuild-1021289 Update 0 SNMP Agent over IPv4 ENTITY-MIB::entLogicalType.1 = OID: SNMPv2-SMI::mib-2 ENTITY-MIB::entLogicalCommunity.1 = STRING: "public" ENTITY-MIB::entLogicalTAddress.1 = STRING: "10.131.0.171" <<<- VMware ESXi instance ENTITY-MIB::entLogicalTDomain.1 = OID: TRANSPORT-ADDRESS-MIB::transportDomainUdpIpv4 ENTITY-MIB::entLogicalContextEngineID.1 = STRING: "00000063000000a10a8300ab" To discover the hardare agent given discovery of a hypervisor agent, SNMPv2-MIB::sysDescr.0 = STRING: VMware ESXi 5.1.0 build-799733 VMware, Inc. x86_64 SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.6876.4.1 ... ENTITY-MIB::entPhysicalDescr.1 = STRING: HP ProLiant BL460c Gen8 ENTITY-MIB::entPhysicalVendorType.1 = OID: SNMPv2-SMI::zeroDotZero ENTITY-MIB::entPhysicalContainedIn.1 = INTEGER: 0 ENTITY-MIB::entPhysicalClass.1 = INTEGER: module(9) ENTITY-MIB::entPhysicalParentRelPos.1 = INTEGER: -1 ENTITY-MIB::entPhysicalName.1 = STRING: smbios ENTITY-MIB::entPhysicalHardwareRev.1 = STRING: ENTITY-MIB::entPhysicalFirmwareRev.1 = STRING: 2.7 ENTITY-MIB::entPhysicalSoftwareRev.1 = STRING: ENTITY-MIB::entPhysicalSerialNum.1 = STRING: USE246M0JM ENTITY-MIB::entPhysicalMfgName.1 = STRING: HP ENTITY-MIB::entPhysicalModelName.1 = STRING: ProLiant BL460c Gen8 ENTITY-MIB::entPhysicalAlias.1 = STRING: ENTITY-MIB::entPhysicalAssetID.1 = STRING: ENTITY-MIB::entPhysicalIsFRU.1 = INTEGER: true(1) ENTITY-MIB::entPhysicalMfgDate.1 = STRING: 2012-8-20,0:0:0.0, ENTITY-MIB::entPhysicalUris.1 = STRING: "urn:uuid:50e8484b-6e6d-734c-539c-b4b52f6fa410" ENTITY-MIB::entLogicalDescr.1 = STRING: VMware vCenter Server ENTITY-MIB::entLogicalDescr.2 = STRING: HP Integrated Lights Out SNMP Management Agent ENTITY-MIB::entLogicalType.1 = OID: VMWARE-PRODUCTS-MIB::vmwVC ENTITY-MIB::entLogicalType.2 = OID: SNMPv2-SMI::enterprises.11.1 ENTITY-MIB::entLogicalTAddress.1 = STRING: "192.168.2.104" ENTITY-MIB::entLogicalTAddress.2 = STRING: "10.131.16.172" ENTITY-MIB::entLogicalTDomain.1 = OID: TRANSPORT-ADDRESS-MIB::transportDomainUdpIpv4 ENTITY-MIB::entLogicalTDomain.2 = OID: TRANSPORT-ADDRESS-MIB::transportDomainUdpIpv4 ENTITY-MIB::entLastChangeTime.0 = Timeticks: (42096100) 4 days, 20:56:01.00 So my question here is even if we want to report the mgmt IP address of the GOS, is this the right MIB module to do that in? Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA From jclarke@cisco.com Mon Aug 19 11:05:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8F11E82C5 for ; Mon, 19 Aug 2013 11:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyVmluFOYiWA for ; Mon, 19 Aug 2013 11:05:30 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1599F11E82C7 for ; Mon, 19 Aug 2013 11:05:28 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JI5QrL012885; Tue, 20 Aug 2013 03:05:27 +0900 (JST) Received: from sjc-vpn2-409.cisco.com (sjc-vpn2-409.cisco.com [10.21.113.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JI5KmM008963; Mon, 19 Aug 2013 11:05:23 -0700 (PDT) Message-ID: <52125E5D.6050608@cisco.com> Date: Mon, 19 Aug 2013 14:05:17 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <70713209.32796209.1376934937834.JavaMail.root@vmware.com> In-Reply-To: <70713209.32796209.1376934937834.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe-1 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:05:35 -0000 On 8/19/13 1:55 PM, Michael MacFaden wrote: > Hi Joe, > > Thanks for sharing this, my comments inline. > > Marking this item as Proposal: Joe-1 > >> JMC: While I think the intention is to say that this MIB pulls from >> other, existing MIBs for common virtualization platforms, it may come >> across as being limited to only those platforms. Perhaps it is good to >> say that this MIB then attempts to generalize those modules to support >> other hypervisors as well? > > So is this just the wording that concerns you? > Juergen and others have raised generalization issue/asked others to contribute. Yup. This was just a nit that I thought the wording as is mught give the impression that this MIB is limited in scope to hypervisors of the specified flavors. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Mon Aug 19 11:14:04 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C639911E8145 for ; Mon, 19 Aug 2013 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjXfGLfWqtb0 for ; Mon, 19 Aug 2013 11:13:59 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE2D11E8146 for ; Mon, 19 Aug 2013 11:13:59 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JIDvBD014247; Tue, 20 Aug 2013 03:13:58 +0900 (JST) Received: from sjc-vpn2-409.cisco.com (sjc-vpn2-409.cisco.com [10.21.113.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JIDteF022157; Mon, 19 Aug 2013 11:13:56 -0700 (PDT) Message-ID: <52126061.2000008@cisco.com> Date: Mon, 19 Aug 2013 14:13:53 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> In-Reply-To: <742382451.32805118.1376935335411.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:14:04 -0000 On 8/19/13 2:02 PM, Michael MacFaden wrote: > > Marking this item as Proposal: Joe-2 > >> JMC: I think there should be an object in this table such as vmMgmtAddr, >> which lists the management IP address of the VM. This would be akin to >> what one would see in vCenter for a VMware-controlled VM. As a manager, >> this would be very useful in being able to discover other potential SNMP >> agents in the network. > > > Do you want this managed object to report only if there is a configured > mgmt agent running in the guest OS(GOS)? There can be more than one mgmt > address per address family. That's fair, and I understand that. My point was that when one is looking at a VM, at least in vCenter, one can see an IP of the GOS. I thought it would be useful to pass that information down the MIB as well. And, yes, I get that this may not be known the HV, and thus may be 0. > > So I did something similar in VMware ESXi 5.1 for the hypervisor > and its relation to the hardware it is installed on. With blade servers, > Cisco ISR, or Cisco UCS or the new HP Gen8 hardware for example it > was clear to me there were going to be multiple SNMP agents and so to > ease mgmt apps discovery I made it simple for hardware vendors > to insert conceptual rows into entLogicalTable/RFC 4133 so > that ESXi SNMP can point back to the supervisor card or other embedded > hardware mgmt agent. But this is driven from the GOS, right? [SNMP Walk elided] > > So my question here is even if we want to report the mgmt IP address of the GOS, > is this the right MIB module to do that in? I think that showing that information, where available is helpful, especially since this is designed to be cross-HV, where the ENTITY support may be more limited, and vendor-specific. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From mrm@vmware.com Mon Aug 19 11:26:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14C721F9C72 for ; Mon, 19 Aug 2013 11:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC+400cVSzpF for ; Mon, 19 Aug 2013 11:26:09 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 51ABF21F9C46 for ; Mon, 19 Aug 2013 11:26:09 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 171AD280F1; Mon, 19 Aug 2013 11:26:07 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 16D5D18285; Mon, 19 Aug 2013 11:26:07 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 0711CE0113; Mon, 19 Aug 2013 11:26:07 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 11:26:06 -0700 (PDT) Date: Mon, 19 Aug 2013 11:26:06 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe -3 (Was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: x8N5VjNPkdfuxGdMTfLjpn3DFcfQqA== Cc: opsawg@ietf.org Subject: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:26:14 -0000 Marking this proposal as Joe-3 > JMC: The purpose of this MIB is not to provide configuration of the > hypervisor. =C2=A0Quoting section 3.2: >=20 > "The MIB module provides a few writable objects that can be used to > =C2=A0 =C2=A0make non-persistent changes, e.g., changing the memory alloc= ation or > =C2=A0 =C2=A0the CPU allocation. =C2=A0It is not the goal of this MIB mod= ule to provide > =C2=A0 =C2=A0a configuration interface for virtual machines since other p= rotocols > =C2=A0 =C2=A0and data modeling languages are more suitable for this task.= " Right. > To that end, I find objects like vmAutoStart, vmMinCpuNumber, > vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. =C2=A0For starters, > vmAutoStart mentions the word "configuration" in its description. =C2=A0A= nd > the other objects, at least from a VMware standpoint are actually > specified in the VM's configuration. =C2=A0One would have to, for example= , > shutdown the VM to increase the number of vCPUs allocated to the VM. Such behavior really depends on the hypervisor. Adding a CPU while VM is running has been a feature of VMware for some time now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=3D/com.vm= ware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_cha= nge_cpu_hotplug_settings.html > Therefore, I feel all of these objects represent persistent changes to > the hypervisor in support of the respective VM. >=20 > I think these objects should go away and only the read-only objects > showing current vCPU allocation, affinity, and memory stats should > remain. =C2=A0As for auto-start, that can be read-only. My position as well. Once you go read-create/write the complexity grows and description fall short of any real standard behavior in response to a mutational set is almost always lost. > The alternative is to say that some persistent changes will be allowed > (such as auto-start), but general VM resource configuration will be out > of scope. Mark this as Joe-3A. As I said above, I'm not interested in standardizing configuration of Virtual Machines via SNMP. Neither are the operators I know. Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA From j.schoenwaelder@jacobs-university.de Mon Aug 19 11:30:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B035811E814F for ; Mon, 19 Aug 2013 11:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FlWbCsT8ONz for ; Mon, 19 Aug 2013 11:30:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F611E814E for ; Mon, 19 Aug 2013 11:30:22 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9910C20C84; Mon, 19 Aug 2013 20:30:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Jva9SPPCTMkx; Mon, 19 Aug 2013 20:30:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32C8220C03; Mon, 19 Aug 2013 20:30:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4E70827F3CE6; Mon, 19 Aug 2013 20:30:15 +0200 (CEST) Date: Mon, 19 Aug 2013 20:30:14 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20130819183014.GA477@elstar.local> Mail-Followup-To: Michael MacFaden , Joe Marcus Clarke , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <742382451.32805118.1376935335411.JavaMail.root@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:30:27 -0000 On Mon, Aug 19, 2013 at 11:02:15AM -0700, Michael MacFaden wrote: > > Marking this item as Proposal: Joe-2 > > > JMC: I think there should be an object in this table such as vmMgmtAddr, > > which lists the management IP address of the VM. This would be akin to > > what one would see in vCenter for a VMware-controlled VM. As a manager, > > this would be very useful in being able to discover other potential SNMP > > agents in the network. > > Do you want this managed object to report only if there is a configured > mgmt agent running in the guest OS(GOS)? There can be more than one mgmt > address per address family. In our systems, the hypervisor has no clue which IP addresses are used by the guest OSes (and surely the hypervisor does not know which IP addresses would be "management" addresses). We use a virtual bridge to connect the VMs. Can we not use the same discovery techniques that can be used today to discover devices (e.g. connected to a physical bridge) to discover virtual machines? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 19 11:34:54 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC07111E82B8 for ; Mon, 19 Aug 2013 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-JYgmuBz2Tg for ; Mon, 19 Aug 2013 11:34:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F00AD11E813F for ; Mon, 19 Aug 2013 11:34:49 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5E46B20C85; Mon, 19 Aug 2013 20:34:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QPuylp5JlsxX; Mon, 19 Aug 2013 20:34:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F299C20C84; Mon, 19 Aug 2013 20:34:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D5E3127F3D7D; Mon, 19 Aug 2013 20:34:43 +0200 (CEST) Date: Mon, 19 Aug 2013 20:34:43 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20130819183443.GB477@elstar.local> Mail-Followup-To: Michael MacFaden , Joe Marcus Clarke , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:34:55 -0000 On Mon, Aug 19, 2013 at 11:26:06AM -0700, Michael MacFaden wrote: > > Marking this proposal as Joe-3 > > > JMC: The purpose of this MIB is not to provide configuration of the > > hypervisor.  Quoting section 3.2: > > > > "The MIB module provides a few writable objects that can be used to > >    make non-persistent changes, e.g., changing the memory allocation or > >    the CPU allocation.  It is not the goal of this MIB module to provide > >    a configuration interface for virtual machines since other protocols > >    and data modeling languages are more suitable for this task." > > Right. > > > To that end, I find objects like vmAutoStart, vmMinCpuNumber, > > vmMaxCpuNumber, vmMinMem, and vmMaxMem strange.  For starters, > > vmAutoStart mentions the word "configuration" in its description.  And > > the other objects, at least from a VMware standpoint are actually > > specified in the VM's configuration.  One would have to, for example, > > shutdown the VM to increase the number of vCPUs allocated to the VM. > > Such behavior really depends on the hypervisor. > > Adding a CPU while VM is running has been a feature of VMware for some time > now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html > > > Therefore, I feel all of these objects represent persistent changes to > > the hypervisor in support of the respective VM. > > > > I think these objects should go away and only the read-only objects > > showing current vCPU allocation, affinity, and memory stats should > > remain.  As for auto-start, that can be read-only. > > My position as well. Once you go read-create/write the complexity > grows and description fall short of any real standard behavior in > response to a mutational set is almost always lost. > > > The alternative is to say that some persistent changes will be allowed > > (such as auto-start), but general VM resource configuration will be out > > of scope. > > Mark this as Joe-3A. > > As I said above, I'm not interested in standardizing configuration > of Virtual Machines via SNMP. Neither are the operators I know. We seem to agree on the general scope. Now we have to determine which objects reasonably have a MAX-ACCESS or read-write. For me, it seems that vmAutoStart likely should indeed be read-only. However, as far as I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem at runtime without touching persistent config state. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jclarke@cisco.com Mon Aug 19 11:36:47 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35E011E82AF for ; Mon, 19 Aug 2013 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tCA9KOZT8-V for ; Mon, 19 Aug 2013 11:36:42 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 19B1C11E813F for ; Mon, 19 Aug 2013 11:36:41 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JIad3G017629; Tue, 20 Aug 2013 03:36:40 +0900 (JST) Received: from sjc-vpn2-409.cisco.com (sjc-vpn2-409.cisco.com [10.21.113.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JIaLvl026592; Mon, 19 Aug 2013 11:36:30 -0700 (PDT) Message-ID: <5212659E.7010200@cisco.com> Date: Mon, 19 Aug 2013 14:36:14 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> In-Reply-To: <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:36:47 -0000 On 8/19/13 2:26 PM, Michael MacFaden wrote: > > Marking this proposal as Joe-3 > >> JMC: The purpose of this MIB is not to provide configuration of the >> hypervisor. Quoting section 3.2: >> >> "The MIB module provides a few writable objects that can be used to >> make non-persistent changes, e.g., changing the memory allocation or >> the CPU allocation. It is not the goal of this MIB module to provide >> a configuration interface for virtual machines since other protocols >> and data modeling languages are more suitable for this task." > > Right. > >> To that end, I find objects like vmAutoStart, vmMinCpuNumber, >> vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, >> vmAutoStart mentions the word "configuration" in its description. And >> the other objects, at least from a VMware standpoint are actually >> specified in the VM's configuration. One would have to, for example, >> shutdown the VM to increase the number of vCPUs allocated to the VM. > > Such behavior really depends on the hypervisor. > > Adding a CPU while VM is running has been a feature of VMware for some time > now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html Ah, I haven't played with hotplug. Nonetheless, I would expect something like this to be persistent vs. available for the current like of the VM, correct? Something more transient would be the option to boot into the BIOS on next boot... > >> Therefore, I feel all of these objects represent persistent changes to >> the hypervisor in support of the respective VM. >> >> I think these objects should go away and only the read-only objects >> showing current vCPU allocation, affinity, and memory stats should >> remain. As for auto-start, that can be read-only. > > My position as well. Once you go read-create/write the complexity > grows and description fall short of any real standard behavior in > response to a mutational set is almost always lost. > >> The alternative is to say that some persistent changes will be allowed >> (such as auto-start), but general VM resource configuration will be out >> of scope. > > Mark this as Joe-3A. > > As I said above, I'm not interested in standardizing configuration > of Virtual Machines via SNMP. Neither are the operators I know. Yeah, I gather, and I agree. That's why options like CPU and memory make me a bit uneasy as I see them as more configuration. Joe > > > Mike MacFaden > Staff Engineer R&D Apps VMware, Inc Palo Alto CA > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From mrm@vmware.com Mon Aug 19 11:38:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921E211E8171 for ; Mon, 19 Aug 2013 11:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mI1FqmYf9noC for ; Mon, 19 Aug 2013 11:38:05 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31F11E814F for ; Mon, 19 Aug 2013 11:38:03 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 0938628122; Mon, 19 Aug 2013 11:38:03 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 074E91839C; Mon, 19 Aug 2013 11:38:03 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id E694FE00D3; Mon, 19 Aug 2013 11:38:02 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 11:38:02 -0700 (PDT) Date: Mon, 19 Aug 2013 11:38:02 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <531716211.32859971.1376937482642.JavaMail.root@vmware.com> In-Reply-To: <52126061.2000008@cisco.com> References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VM-MIB: Proposal: Joe-2 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: n1+FwMajqeQGIiMagm/zAXbHpqWwzA== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:38:16 -0000 > That's fair, and I understand that. My point was that when one is > looking at a VM, at least in vCenter, one can see an IP of the GOS. I > thought it would be useful to pass that information down the MIB as > well. And, yes, I get that this may not be known the HV, and thus may be 0. > What I'm trying to get from you is why we need this? So far you've stated the use is to discover other (SNMP) agents. And I buy that and demonstrated how its done using ENTITY-MIB implemented in two separate vendors agents given bi directional discovery capability. Are there any other use cases here? Say the address is IPv6 and the stat is not preferred what would we show? Trying to get more details why mgmt agents (as opposed to operators using VC) want this info. Such data can also be obtained by reading various network address tables if the VM is at all active. In the case of the product you mention, VC is reporting IP address ranges it see only if the GOS has the "Tools" agent installed. It also just reports on the network range seen on the vswitch to VM connection. > > So I did something similar in VMware ESXi 5.1 for the hypervisor > > and its relation to the hardware it is installed on. With blade servers, > > Cisco ISR, or Cisco UCS or the new HP Gen8 hardware for example it > > was clear to me there were going to be multiple SNMP agents and so to > > ease mgmt apps discovery I made it simple for hardware vendors > > to insert conceptual rows into entLogicalTable/RFC 4133 so > > that ESXi SNMP can point back to the supervisor card or other embedded > > hardware mgmt agent. > > But this is driven from the GOS, right? No GOS involved. If one turns on the ESXi snmp agent (no vms need be powered up) and polls RFC 4133, they can find other snmp mgmt agent. Hardware vendors install vibs (like .deb/.rpm) to populate the data. > > So my question here is even if we want to report the mgmt IP address of the > > GOS, > > is this the right MIB module to do that in? > > I think that showing that information, where available is helpful, > especially since this is designed to be cross-HV, where the ENTITY > support may be more limited, and vendor-specific. One of the nice features of MIB modules is that they are modular. That means you can write code once and it works in most deployments. After two decades my admiration for the design that went into these modules (2790 on up) has only grown. Time and time again, operators tell me they wan to learn something once and leverage over and over again. So I would make acounter-proposal, show you how the feature that relates a GOS agent to a hypervisor is no different that relating a hypervisor to the supervisor/hardware card. Regards, Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA From jclarke@cisco.com Mon Aug 19 11:39:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5E011E8171 for ; Mon, 19 Aug 2013 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+okazo8ESQa for ; Mon, 19 Aug 2013 11:39:16 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD2711E814F for ; Mon, 19 Aug 2013 11:39:16 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JIdDWx018085; Tue, 20 Aug 2013 03:39:14 +0900 (JST) Received: from sjc-vpn2-409.cisco.com (sjc-vpn2-409.cisco.com [10.21.113.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JIcjSB000094; Mon, 19 Aug 2013 11:38:59 -0700 (PDT) Message-ID: <52126630.9040004@cisco.com> Date: Mon, 19 Aug 2013 14:38:40 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <20130819183014.GA477@elstar.local> In-Reply-To: <20130819183014.GA477@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:39:33 -0000 On 8/19/13 2:30 PM, Juergen Schoenwaelder wrote: > On Mon, Aug 19, 2013 at 11:02:15AM -0700, Michael MacFaden wrote: >> >> Marking this item as Proposal: Joe-2 >> >>> JMC: I think there should be an object in this table such as vmMgmtAddr, >>> which lists the management IP address of the VM. This would be akin to >>> what one would see in vCenter for a VMware-controlled VM. As a manager, >>> this would be very useful in being able to discover other potential SNMP >>> agents in the network. >> >> Do you want this managed object to report only if there is a configured >> mgmt agent running in the guest OS(GOS)? There can be more than one mgmt >> address per address family. > > In our systems, the hypervisor has no clue which IP addresses are used > by the guest OSes (and surely the hypervisor does not know which IP > addresses would be "management" addresses). > > We use a virtual bridge to connect the VMs. Can we not use the same > discovery techniques that can be used today to discover devices > (e.g. connected to a physical bridge) to discover virtual machines? Sure. This just presents another, maybe simpler way to find VMs in particular in the network. I fully understand that this address may be 0, but I know at least for the VMs I maintain, it would be a useful value. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From mrm@vmware.com Mon Aug 19 11:45:29 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6343111E82AF for ; Mon, 19 Aug 2013 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLnrPGrTxFsX for ; Mon, 19 Aug 2013 11:45:20 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF38D11E82B8 for ; Mon, 19 Aug 2013 11:45:20 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 04DB928123; Mon, 19 Aug 2013 11:45:20 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 00D6440423; Mon, 19 Aug 2013 11:45:20 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id E1D28E0042; Mon, 19 Aug 2013 11:45:19 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 11:45:19 -0700 (PDT) Date: Mon, 19 Aug 2013 11:45:19 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <1739595790.32869674.1376937919771.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe-4 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: hm8g+MZbHOV/58nk+LI+blj3FcQH3A== Cc: opsawg@ietf.org Subject: [OPSAWG] VMM-MIB: Proposal: Joe-4 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:45:29 -0000 Marking this proposal as Joe-4 > Section 3.3: > > vmNetworkEntry OBJECT-TYPE > SYNTAX VmNetworkEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "An entry for one virtual storage device attached to the > virtual machine." > INDEX { vmIndex, vmNetworkIndex } > ::= { vmNetworkTable 1 } > > JMC: Note how the description describes this as "storage" device... Agreed. Mike MacFaden From j.schoenwaelder@jacobs-university.de Mon Aug 19 11:51:07 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626AA21F9B4C for ; Mon, 19 Aug 2013 11:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+6ihS61CHOM for ; Mon, 19 Aug 2013 11:51:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AAF4C21F9A94 for ; Mon, 19 Aug 2013 11:51:01 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D57020C84; Mon, 19 Aug 2013 20:51:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id koFGNS4kuqZD; Mon, 19 Aug 2013 20:51:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EB8720C77; Mon, 19 Aug 2013 20:50:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8165E27F3E1B; Mon, 19 Aug 2013 20:50:54 +0200 (CEST) Date: Mon, 19 Aug 2013 20:50:54 +0200 From: Juergen Schoenwaelder To: Joe Marcus Clarke Message-ID: <20130819185054.GA590@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <20130819183014.GA477@elstar.local> <52126630.9040004@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52126630.9040004@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:51:07 -0000 On Mon, Aug 19, 2013 at 02:38:40PM -0400, Joe Marcus Clarke wrote: > > Sure. This just presents another, maybe simpler way to find VMs in > particular in the network. I fully understand that this address may be > 0, but I know at least for the VMs I maintain, it would be a useful value. > I do not question the value (although an IP address still requires guess-work to talk to a management interface successfully). I am saying that it is not at all easy to implement such an object since the hypervisor may simply have no clue which IP addresses are used by the guest OSes (and which subset would be 'management' addresses). It might work in your case - but we need to maintain a somewhat broader view I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mrm@vmware.com Mon Aug 19 11:55:36 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9480A11E82C2 for ; Mon, 19 Aug 2013 11:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cWpI9DGuVEc for ; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 97F3A11E82BA for ; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 89B472808D; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 8922E180C1; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 7957FE00D1; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 11:55:21 -0700 (PDT) Date: Mon, 19 Aug 2013 11:55:21 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <1555382192.32884480.1376938521304.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe-5 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: ThtI9PjAgxsBJ5lunPk+orkFRbkhzQ== Cc: opsawg@ietf.org Subject: [OPSAWG] VMM-MIB: Proposal: Joe-5 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 18:55:37 -0000 Marking this proposal as Joe-5 > Section 3.3: > > Concerning vmNetworkTable. > > JMC: I think there should be a vmNetworkVlan object in this table that > describes the VLAN ID associated to the underlying interface. This need > not be used for every hypervisor, but I think it is very important in > some (like VMware). Are we talking about the configuration in the GOS or the virtual switch? > JMC: What would one expect if I have a VM connected to multiple > vSwitches in a VMware environment? What object will tell me to what > vSwitch I am connected? Should there also be a name here for the > virtual interface? I'm thinking of the case where something like a > Cisco Nexus 1000v switch is used. In that case, knowing that I am > connected to Ethernet1/1 might be useful. If the virtual switches in the hypervisor implement either the IEEE or the IETF Q bridge mib then you can easily make this determination. Why? the VM-MIB reports MAC address. From that we find the mac in the FDB table and locate the switch port and vlan. > JMC: Like in the VM table, I wonder if it makes sense to have a network > management address for the case where the associated virtual network > device can be independently managed. It does. My counter-proposal is that the ENTITY-MIB would be populated contain the mgmt address(s) for any virtual switch. My prior mib walk actually had entries for how one product does it already :-) Regards, mike From mrm@vmware.com Mon Aug 19 12:00:15 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDB11E82E3 for ; Mon, 19 Aug 2013 12:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DvwIEfRgZaZ for ; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8117A11E82E7 for ; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 75EBC280B9; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 72C2340428; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 5C0E6E0042; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 12:00:07 -0700 (PDT) Date: Mon, 19 Aug 2013 12:00:07 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <2093735133.32889895.1376938807134.JavaMail.root@vmware.com> In-Reply-To: <521158A7.2090407@cisco.com> References: <521158A7.2090407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe-7 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: E2SdG94YIQ+0V2Sk5O2s5qNKADRXjA== Cc: opsawg@ietf.org Subject: [OPSAWG] VMM-MIB: Proposal: Joe-7 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:00:16 -0000 Marking this proposal as Joe-7 > Section 3.3: > > Concerning vmNotifications. > > JMC: I think there should be a general notification for VM changing > state. The reason for this is that some of the state transitions > described in section 3.2 Figure 2 can take a long time (e.g., running -> > shuttingdown -> shutdown). In that case, an administrator may have to > wait minutes before being alerted to the fact that her VM is offline. > If there was a notification for vmStateChange, then the admin would be > notified immediately if a VM entered a degraded state. > Can you help me understand the relationship between agent and operator? Is the app polling and getting events (aka trap-directed polling) or is it just getting events or just polling? Regards, Mike MacFaden From jclarke@cisco.com Mon Aug 19 13:35:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2754C11E82D2 for ; Mon, 19 Aug 2013 13:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew-Vd141WIZz for ; Mon, 19 Aug 2013 13:35:09 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6B26B11E80EF for ; Mon, 19 Aug 2013 13:35:08 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKZ4oK004808; Tue, 20 Aug 2013 05:35:05 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKZ4OU029386; Mon, 19 Aug 2013 13:35:04 -0700 (PDT) Message-ID: <52128177.9020600@cisco.com> Date: Mon, 19 Aug 2013 16:35:03 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> In-Reply-To: <531716211.32859971.1376937482642.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:35:14 -0000 On 8/19/13 2:38 PM, Michael MacFaden wrote: >> That's fair, and I understand that. My point was that when one is >> looking at a VM, at least in vCenter, one can see an IP of the GOS. I >> thought it would be useful to pass that information down the MIB as >> well. And, yes, I get that this may not be known the HV, and thus may be 0. >> > > What I'm trying to get from you is why we need this? Sorry for the delay. I was on a plane previously, and now I'm back on solid ground. My use case is around VM discovery. If I have this table, and I can enumerate VMs, it would be useful, if available, to see what address I might use to connect to the VM. > So far you've stated the use is to discover other (SNMP) agents. > And I buy that and demonstrated how its done using ENTITY-MIB > implemented in two separate vendors agents given bi directional > discovery capability. > > Are there any other use cases here? > Say the address is IPv6 and the stat is not preferred what would we show? That would be up to the HV and the underlying interface with the VM. The HV is perfectly capable of using a 0 address to indicate that no VM address is available. But if populated, a manager can then, without necessarily doing other host discovery operations, attempt to further manage the VM. > > Trying to get more details why mgmt agents (as opposed to > operators using VC) want this info. > > Such data can also be obtained by reading various network address tables > if the VM is at all active. Yes, this is a typical approach, but in seeing this MIB, I was proposing a shortcut. > > In the case of the product you mention, VC is reporting IP address > ranges it see only if the GOS has the "Tools" agent installed. > It also just reports on the network range seen on the vswitch to VM > connection. Yes, I understand that. > > >>> So I did something similar in VMware ESXi 5.1 for the hypervisor >>> and its relation to the hardware it is installed on. With blade servers, >>> Cisco ISR, or Cisco UCS or the new HP Gen8 hardware for example it >>> was clear to me there were going to be multiple SNMP agents and so to >>> ease mgmt apps discovery I made it simple for hardware vendors >>> to insert conceptual rows into entLogicalTable/RFC 4133 so >>> that ESXi SNMP can point back to the supervisor card or other embedded >>> hardware mgmt agent. >> >> But this is driven from the GOS, right? > > No GOS involved. If one turns on the ESXi snmp agent (no vms need be powered up) > and polls RFC 4133, they can find other snmp mgmt agent. Hardware > vendors install vibs (like .deb/.rpm) to populate the data. Right, I misunderstood. I had thought the VM was inserting conceptual rows. That's what altitude will do to you. While this is very useful for the host, it isn't the same thing as showing the VM IP address. > >>> So my question here is even if we want to report the mgmt IP address of the >>> GOS, >>> is this the right MIB module to do that in? >> >> I think that showing that information, where available is helpful, >> especially since this is designed to be cross-HV, where the ENTITY >> support may be more limited, and vendor-specific. > > One of the nice features of MIB modules is that they are modular. > That means you can write code once and it works in most deployments. > After two decades my admiration for the design that went into these > modules (2790 on up) has only grown. > > Time and time again, operators tell me they wan to learn something once > and leverage over and over again. So I would make acounter-proposal, > show you how the feature that relates a GOS agent to a hypervisor > is no different that relating a hypervisor to the supervisor/hardware card. That is a fair point. If I understand you right this time, and the VM inserts entLogicalTable entries in the HV ENTITY-MIB, would it not make sense to add a pointer in the VMM-MIB to indicate their index in the entLogicalTable? 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: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Mon Aug 19 13:38:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44DC11E82D2 for ; Mon, 19 Aug 2013 13:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIgSm0edxrSs for ; Mon, 19 Aug 2013 13:38:31 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6D71421F8A38 for ; Mon, 19 Aug 2013 13:38:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKcThn005261; Tue, 20 Aug 2013 05:38:30 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKcSjo003461; Mon, 19 Aug 2013 13:38:28 -0700 (PDT) Message-ID: <52128244.8060107@cisco.com> Date: Mon, 19 Aug 2013 16:38:28 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> In-Reply-To: <20130819183443.GB477@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:38:36 -0000 On 8/19/13 2:34 PM, Juergen Schoenwaelder wrote: > On Mon, Aug 19, 2013 at 11:26:06AM -0700, Michael MacFaden wrote: >> >> Marking this proposal as Joe-3 >> >>> JMC: The purpose of this MIB is not to provide configuration of the >>> hypervisor. Quoting section 3.2: >>> >>> "The MIB module provides a few writable objects that can be used to >>> make non-persistent changes, e.g., changing the memory allocation or >>> the CPU allocation. It is not the goal of this MIB module to provide >>> a configuration interface for virtual machines since other protocols >>> and data modeling languages are more suitable for this task." >> >> Right. >> >>> To that end, I find objects like vmAutoStart, vmMinCpuNumber, >>> vmMaxCpuNumber, vmMinMem, and vmMaxMem strange. For starters, >>> vmAutoStart mentions the word "configuration" in its description. And >>> the other objects, at least from a VMware standpoint are actually >>> specified in the VM's configuration. One would have to, for example, >>> shutdown the VM to increase the number of vCPUs allocated to the VM. >> >> Such behavior really depends on the hypervisor. >> >> Adding a CPU while VM is running has been a feature of VMware for some time >> now: http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_change_cpu_hotplug_settings.html >> >>> Therefore, I feel all of these objects represent persistent changes to >>> the hypervisor in support of the respective VM. >>> >>> I think these objects should go away and only the read-only objects >>> showing current vCPU allocation, affinity, and memory stats should >>> remain. As for auto-start, that can be read-only. >> >> My position as well. Once you go read-create/write the complexity >> grows and description fall short of any real standard behavior in >> response to a mutational set is almost always lost. >> >>> The alternative is to say that some persistent changes will be allowed >>> (such as auto-start), but general VM resource configuration will be out >>> of scope. >> >> Mark this as Joe-3A. >> >> As I said above, I'm not interested in standardizing configuration >> of Virtual Machines via SNMP. Neither are the operators I know. > > We seem to agree on the general scope. Now we have to determine which > objects reasonably have a MAX-ACCESS or read-write. For me, it seems > that vmAutoStart likely should indeed be read-only. However, as far as > I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, > and vmMaxMem at runtime without touching persistent config state. If the WG's intent is to leave them as RW (and I can see that certain HV's allow this sans persistence), then there should be stronger guidance (I think) that indicates that these are operational-only objects and the new values should not be persisted. But that may be too messy. Is there a strong push from operators to toggle these values via SNMP? Joe > > /js > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Mon Aug 19 13:40:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF4F11E82D2 for ; Mon, 19 Aug 2013 13:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J0bsmiWVqnN for ; Mon, 19 Aug 2013 13:40:22 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id BAB9D11E82E8 for ; Mon, 19 Aug 2013 13:40:21 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKeIWk005526; Tue, 20 Aug 2013 05:40:19 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKeIFO005491; Mon, 19 Aug 2013 13:40:18 -0700 (PDT) Message-ID: <521282B2.2090807@cisco.com> Date: Mon, 19 Aug 2013 16:40:18 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <1555382192.32884480.1376938521304.JavaMail.root@vmware.com> In-Reply-To: <1555382192.32884480.1376938521304.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe-5 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:40:27 -0000 On 8/19/13 2:55 PM, Michael MacFaden wrote: > > Marking this proposal as Joe-5 > >> Section 3.3: >> >> Concerning vmNetworkTable. >> >> JMC: I think there should be a vmNetworkVlan object in this table that >> describes the VLAN ID associated to the underlying interface. This need >> not be used for every hypervisor, but I think it is very important in >> some (like VMware). > > Are we talking about the configuration in the GOS or the virtual switch? I was referring to the virtual switch. > > >> JMC: What would one expect if I have a VM connected to multiple >> vSwitches in a VMware environment? What object will tell me to what >> vSwitch I am connected? Should there also be a name here for the >> virtual interface? I'm thinking of the case where something like a >> Cisco Nexus 1000v switch is used. In that case, knowing that I am >> connected to Ethernet1/1 might be useful. > > If the virtual switches in the hypervisor implement either the IEEE > or the IETF Q bridge mib then you can easily make this determination. > Why? the VM-MIB reports MAC address. From that we find the mac in the > FDB table and locate the switch port and vlan. You're right. Again, I was aiming for more of a shortcut with data that would generally be useful. > >> JMC: Like in the VM table, I wonder if it makes sense to have a network >> management address for the case where the associated virtual network >> device can be independently managed. > > It does. > > My counter-proposal is that the ENTITY-MIB would be populated > contain the mgmt address(s) for any virtual switch. My prior > mib walk actually had entries for how one product does it already :-) Again, that's fair. My corollary question would then be should there be a entLogicalTable pointer in this table? Joe > > Regards, > mike > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Mon Aug 19 13:46:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F921F9AD8 for ; Mon, 19 Aug 2013 13:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksw6Aq6tfvf6 for ; Mon, 19 Aug 2013 13:46:25 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 967FA21F99BB for ; Mon, 19 Aug 2013 13:46:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKkNbZ006326; Tue, 20 Aug 2013 05:46:24 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKkMlW012873; Mon, 19 Aug 2013 13:46:22 -0700 (PDT) Message-ID: <5212841E.8060006@cisco.com> Date: Mon, 19 Aug 2013 16:46:22 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <2093735133.32889895.1376938807134.JavaMail.root@vmware.com> In-Reply-To: <2093735133.32889895.1376938807134.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe-7 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:46:37 -0000 On 8/19/13 3:00 PM, Michael MacFaden wrote: > > Marking this proposal as Joe-7 > >> Section 3.3: >> >> Concerning vmNotifications. >> >> JMC: I think there should be a general notification for VM changing >> state. The reason for this is that some of the state transitions >> described in section 3.2 Figure 2 can take a long time (e.g., running -> >> shuttingdown -> shutdown). In that case, an administrator may have to >> wait minutes before being alerted to the fact that her VM is offline. >> If there was a notification for vmStateChange, then the admin would be >> notified immediately if a VM entered a degraded state. >> > > Can you help me understand the relationship between agent and operator? > Is the app polling and getting events (aka trap-directed polling) or is > it just getting events or just polling? Potentially both (I know Cisco at least uses both types of managers). My use case, based on reading the MIB, is that I'd like an object that tells me when I make a negative state transition so I can be notified immediately when a VM moves to, for example, shuttingdown from running (i.e., similar to bgpBackwardTransition from the BGP4-MIB). 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: jclarke@cisco.com ---------------------------------------------------------------------------- From mrm@vmware.com Mon Aug 19 13:52:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8521F89D8 for ; Mon, 19 Aug 2013 13:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqruVaP7Gkb4 for ; Mon, 19 Aug 2013 13:52:22 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2F70711E82F7 for ; Mon, 19 Aug 2013 13:52:16 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 780E8280B1; Mon, 19 Aug 2013 13:52:15 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 758844011F; Mon, 19 Aug 2013 13:52:15 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 649A1E003B; Mon, 19 Aug 2013 13:52:15 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 13:52:15 -0700 (PDT) Date: Mon, 19 Aug 2013 13:52:15 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <767970431.33038278.1376945535247.JavaMail.root@vmware.com> In-Reply-To: <52128177.9020600@cisco.com> References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VM-MIB: Proposal: Joe-2 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: mCA8jBf5xD8C/5yJAcZjK92d5vLGwQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:52:27 -0000 > If I understand you right this time, and the VM > inserts entLogicalTable entries in the HV ENTITY-MIB, would it not make > sense to add a pointer in the VMM-MIB to indicate their index in the > entLogicalTable? Yes, exactly. Create a row in entLogicalTable if there is data to provide regarding pointers to agents in GOS and have a way to get at it to/from the VMM-MIB. Regards, Mike MacFaden From jclarke@cisco.com Mon Aug 19 13:54:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90B011E8300 for ; Mon, 19 Aug 2013 13:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eTsWks-WLNP for ; Mon, 19 Aug 2013 13:54:29 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 828EF11E82FC for ; Mon, 19 Aug 2013 13:54:25 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7JKsNGb007487; Tue, 20 Aug 2013 05:54:23 +0900 (JST) Received: from prosciutto.local ([10.154.66.189]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7JKsMcK021876; Mon, 19 Aug 2013 13:54:22 -0700 (PDT) Message-ID: <521285FE.2020507@cisco.com> Date: Mon, 19 Aug 2013 16:54:22 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> In-Reply-To: <767970431.33038278.1376945535247.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:54:38 -0000 On 8/19/13 4:52 PM, Michael MacFaden wrote: >> If I understand you right this time, and the VM >> inserts entLogicalTable entries in the HV ENTITY-MIB, would it not make >> sense to add a pointer in the VMM-MIB to indicate their index in the >> entLogicalTable? > > Yes, exactly. Create a row in entLogicalTable if there is data to provide > regarding pointers to agents in GOS and have a way to get at it to/from > the VMM-MIB. Okay, so in that case I would change Joe-2 to ask for an object in this table to point to such a conceptual row (or 0). 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: jclarke@cisco.com ---------------------------------------------------------------------------- From mrm@vmware.com Mon Aug 19 14:10:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39F211E8128 for ; Mon, 19 Aug 2013 14:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 826u+2teYfwK for ; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2EF11E814B for ; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 3175628130; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 2EAC81852F; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 1CFD7E00D4; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 19 Aug 2013 14:09:50 -0700 (PDT) Date: Mon, 19 Aug 2013 14:09:49 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <321473730.33058765.1376946589902.JavaMail.root@vmware.com> In-Reply-To: <521282B2.2090807@cisco.com> References: <521158A7.2090407@cisco.com> <1555382192.32884480.1376938521304.JavaMail.root@vmware.com> <521282B2.2090807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe-5 (was Re: [OPSAWG] Comments on draft-asai-vmm-mib-04) Thread-Index: BqLAUpIrOQlu5WSAx0OPgmQi5vtJ/Q== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe-5 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 21:10:02 -0000 ----- Original Message ----- > On 8/19/13 2:55 PM, Michael MacFaden wrote: > > > > Marking this proposal as Joe-5 > > > >> Section 3.3: > >> > >> Concerning vmNetworkTable. > >> > >> JMC: I think there should be a vmNetworkVlan object in this table that > >> describes the VLAN ID associated to the underlying interface. This need > >> not be used for every hypervisor, but I think it is very important in > >> some (like VMware). > > > > Are we talking about the configuration in the GOS or the virtual switch? > > I was referring to the virtual switch. Ah, I was thinking it was the vid was installed into the GOS ethernet driver. LoL. >Again, I was aiming for more of a shortcut with data that > would generally be useful. Right, definitely a shortcut for mib-browser users for sure. Yet its more work for me to build the test to validate it when it changes! > My corollary question would then be should there be a entLogicalTable > pointer in this table? Not the entity mib in this case but a RowPointer to the vswitch's port could work.[1] The complexity here is that to get a VID, not of the VM, but of the uplink it connects to, that really depends on how the VM's virtual port is wired. Some hypervisors might drop down to a real hardware switch, som are virtual/software switch, some are just host Ethernet adapters. RFC 2790/HOST-RESOURCES-MIB also comes to mind but its networking is limited to pointing to an ifIndex. In any case you raise a good item for the list to push all sorts of possibilities. Regards, Mike MacFaden [1] btw, the model I've been working with, which I think goes against current standards thinking has vswitches that span hypervisors tied together with entries in entLogicalTable. These entries provide the uuid of the vswitch and the local ieee component id so mgmt apps can collect the entire state of a given vswitch across hypervisors by looking up the uuid then getting the component id from which to poll ieee IEEE8021-BRIDGE-MIB, IEEE8012-Q-BRIDGE-MIB, IEEE8023-LAG-MIB From j.schoenwaelder@jacobs-university.de Mon Aug 19 23:38:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9111E81C9 for ; Mon, 19 Aug 2013 23:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.222 X-Spam-Level: X-Spam-Status: No, score=-103.222 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJQrnEuKwPhN for ; Mon, 19 Aug 2013 23:38:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4BE211E81DD for ; Mon, 19 Aug 2013 23:38:02 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E46520BF8; Tue, 20 Aug 2013 08:38:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VILYdOcF--8b; Tue, 20 Aug 2013 08:38:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD07720BF5; Tue, 20 Aug 2013 08:37:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BEAC127F4681; Tue, 20 Aug 2013 08:37:54 +0200 (CEST) Date: Tue, 20 Aug 2013 08:37:54 +0200 From: Juergen Schoenwaelder To: Joe Marcus Clarke Message-ID: <20130820063754.GC1861@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52128244.8060107@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:38:08 -0000 On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: > > > > We seem to agree on the general scope. Now we have to determine which > > objects reasonably have a MAX-ACCESS or read-write. For me, it seems > > that vmAutoStart likely should indeed be read-only. However, as far as > > I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, > > and vmMaxMem at runtime without touching persistent config state. > > If the WG's intent is to leave them as RW (and I can see that certain > HV's allow this sans persistence), then there should be stronger > guidance (I think) that indicates that these are operational-only > objects and the new values should not be persisted. But that may be too > messy. There is already text like this: Changes to this object may not persist across restarts of the hypervisor. What is your proposal to make this clearer / stronger? > Is there a strong push from operators to toggle these values via SNMP? Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it 'defines whether it makes "protocol sense" to read, write and/or create an instance of the object, or to include its value in a notification'. The compliance statement vmReadOnlyCompliances says that write access is not required to be implemented. I believe this is how we commonly do things in a MIB module - we allow read-write implementations but we do not require read-write implementations. Hence, I prefer to make no changes (except perhaps vmAutoStart but I need to check whether there are hypervisors that actually allow to change autostart behaviour of the running instance without touching persistent config - this might actually be possible). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From melinda.shore@gmail.com Tue Aug 20 15:23:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2A611E8324 for ; Tue, 20 Aug 2013 15:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOH+ESWRXUbW for ; Tue, 20 Aug 2013 15:23:33 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05F11E82EB for ; Tue, 20 Aug 2013 15:21:37 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id q10so984919pdj.21 for ; Tue, 20 Aug 2013 15:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=vmHRqPScYJeYg7sVuouJcQf1DJFkAcODPI+Qq4sod5Y=; b=MAseKKA9NmNmEv+8N+8JB6fyN/f6CAryYrR+Ik2VFK4D08Esh2rwkMn4/iyN0CeTQ/ hrYJ0R/aCXQyrl37uOtlAEQOiGpEf1HUMznKWZMu0JpwiGXkmOnzEBix0CuBNbIqF8XG CCCvFsx5rm1BGt66TUHyTKtdjfuIW8x+UyxhFYABQSG5WbOAzcYinls7t/oLt9pGPUYW gHM8OsfAyxfOhXveSlqn3UxSqb93T2TTSCKj8YsP6dlSEEckFt2tH5avMzzjasnzwpam 9lf4QkWvc9gcRDVDUVEOP1twBW4gneewrKFCZgAcSCM3pk2xS49hhXlDJ9h268VMlmV+ jE+w== X-Received: by 10.66.216.234 with SMTP id ot10mr2849983pac.122.1377037264599; Tue, 20 Aug 2013 15:21:04 -0700 (PDT) Received: from spandex.local (66-230-88-161-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.88.161]) by mx.google.com with ESMTPSA id xe9sm5989171pab.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 15:21:03 -0700 (PDT) Message-ID: <5213EBCC.8030006@gmail.com> Date: Tue, 20 Aug 2013 14:21:00 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" , opsawg-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] Closing draft-ietf-opsawg-lsn-deployment last call X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 22:23:35 -0000 We received zero - that is to say none, bupkes, goose egg - comments during working group last call on this document. Because there was active discussion and review over the months leading up to wg last call I'm inclined to send along a request for publication with an explanation of the lack of feedback as part of the write-up. However, you may still submit comments if you've got any. Melinda From dromasca@avaya.com Wed Aug 21 01:02:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C839611E81DC for ; Wed, 21 Aug 2013 01:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.469 X-Spam-Level: X-Spam-Status: No, score=-103.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev3Lnh1yRZJM for ; Wed, 21 Aug 2013 01:02:39 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 690AC11E81DA for ; Wed, 21 Aug 2013 01:02:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABZzFFKHCzI1/2dsb2JhbABagmQhNVG/WoElFnSCJAEBAQEDAQEBDyg0CwwEAgEIDQQEAQELFAkHJwsUCQgCBAENBQgah24BC5hGlRMTBJAkMQcGgxV5A54ziwiDHIIq X-IronPort-AV: E=Sophos;i="4.89,926,1367985600"; d="scan'208";a="24425454" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Aug 2013 04:02:38 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 21 Aug 2013 03:55:22 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Wed, 21 Aug 2013 04:02:37 -0400 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "opsawg@ietf.org" , "opsawg-ads@tools.ietf.org" Thread-Topic: [OPSAWG] Closing draft-ietf-opsawg-lsn-deployment last call Thread-Index: AQHOnfRZEAlsEv+f6E+Nvxh00Y96jZmfTF1A Date: Wed, 21 Aug 2013 08:02:36 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B2EAB@AZ-FFEXMB04.global.avaya.com> References: <5213EBCC.8030006@gmail.com> In-Reply-To: <5213EBCC.8030006@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Closing draft-ietf-opsawg-lsn-deployment last call X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 08:02:44 -0000 FWIW - I read the I-D. I found nothing that would prevent publication. It l= ooks like useful operational experience and worth being published in an Inf= ormational RFC. I have no experience with CGN deployment, so I cannot say m= ore.=20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Wednesday, August 21, 2013 1:21 AM > To: opsawg@ietf.org; opsawg-ads@tools.ietf.org > Cc: opsawg-chairs@tools.ietf.org > Subject: [OPSAWG] Closing draft-ietf-opsawg-lsn-deployment last call >=20 > We received zero - that is to say none, bupkes, goose egg - comments > during working group last call on this document. Because there was > active discussion and review over the months leading up to wg last call > I'm inclined to send along a request for publication with an explanation > of the lack of feedback as part of the write-up. >=20 > However, you may still submit comments if you've got any. >=20 > Melinda > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From jclarke@cisco.com Wed Aug 21 11:27:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2E11F0ED6 for ; Wed, 21 Aug 2013 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmRD-48K3yNu for ; Wed, 21 Aug 2013 11:27:14 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5411F0ECF for ; Wed, 21 Aug 2013 11:27:09 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7LIR4Ml017607; Thu, 22 Aug 2013 03:27:05 +0900 (JST) Received: from prosciutto.local ([10.154.66.29]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7LIR4WF004722; Wed, 21 Aug 2013 11:27:04 -0700 (PDT) Message-ID: <5215067C.3040000@cisco.com> Date: Wed, 21 Aug 2013 14:27:08 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> In-Reply-To: <20130820063754.GC1861@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 18:27:21 -0000 On 8/20/13 2:37 AM, Juergen Schoenwaelder wrote: > On Mon, Aug 19, 2013 at 04:38:28PM -0400, Joe Marcus Clarke wrote: >>> >>> We seem to agree on the general scope. Now we have to determine which >>> objects reasonably have a MAX-ACCESS or read-write. For me, it seems >>> that vmAutoStart likely should indeed be read-only. However, as far as >>> I know, Xen allows to change vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, >>> and vmMaxMem at runtime without touching persistent config state. >> >> If the WG's intent is to leave them as RW (and I can see that certain >> HV's allow this sans persistence), then there should be stronger >> guidance (I think) that indicates that these are operational-only >> objects and the new values should not be persisted. But that may be too >> messy. Sorry for the delay. I've been in meetings this week. > > There is already text like this: > > Changes to this object may not persist across restarts of the > hypervisor. > > What is your proposal to make this clearer / stronger? This leaves it open to one persisting it. You could use normative language and say, MUST NOT persist... > >> Is there a strong push from operators to toggle these values via SNMP? > > Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it > 'defines whether it makes "protocol sense" to read, write and/or > create an instance of the object, or to include its value in a > notification'. The compliance statement vmReadOnlyCompliances says > that write access is not required to be implemented. I believe this is > how we commonly do things in a MIB module - we allow read-write > implementations but we do not require read-write implementations. > Hence, I prefer to make no changes (except perhaps vmAutoStart but I > need to check whether there are hypervisors that actually allow to > change autostart behaviour of the running instance without touching > persistent config - this might actually be possible). That's fair. I was not aware of the ability to adjust VM CPU and memory on the fly without touching the config. That said, I struggle to understand the use case of doing this via SNMP versus a more reliable API. I would also ask that some language be added to the compliance section like you have in Section 3.2 about only implementing read-write if the changes can be made dynamically and independent of the config. Joe > > /js > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From sob@harvard.edu Wed Aug 21 17:21:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138FE21F9AB8 for ; Wed, 21 Aug 2013 17:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0HrMg8G-w1T for ; Wed, 21 Aug 2013 17:21:30 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id 60DAA21F9ACA for ; Wed, 21 Aug 2013 17:21:30 -0700 (PDT) Received: from exchange.university.harvard.edu (entwedge0000001.university.harvard.edu [10.35.2.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 91DB6E991D for ; Wed, 21 Aug 2013 20:21:29 -0400 (EDT) Received: from ENTWHUBT0000005.university.harvard.edu (10.32.208.51) by ENTWEDGE0000001.university.harvard.edu (10.35.2.152) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 21 Aug 2013 20:21:19 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.134]) by ENTWHUBT0000005.university.harvard.edu ([10.32.208.51]) with mapi id 14.03.0146.000; Wed, 21 Aug 2013 20:21:29 -0400 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: draft minutes of the opsawg session posted Thread-Index: AQHOns2LJnOijBCDeUiE9+C1R7vXyQ== Date: Thu, 22 Aug 2013 00:21:28 +0000 Message-ID: <2B482695-597C-43E4-BA33-ACE8C88750E1@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [136.248.127.162] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] draft minutes of the opsawg session posted X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 00:21:35 -0000 please review & comment (if needed) http://www.ietf.org/proceedings/87/minutes/minutes-87-opsawg tnx Scott From dromasca@avaya.com Thu Aug 22 02:41:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438F221F9C6E for ; Thu, 22 Aug 2013 02:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.336 X-Spam-Level: X-Spam-Status: No, score=-103.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0bg-yOmN60i for ; Thu, 22 Aug 2013 02:41:27 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52C21F9A34 for ; Thu, 22 Aug 2013 02:41:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEJAFHcFVKHCzI1/2dsb2JhbABaDoJWITVRq1OUNIEdFnSCJAEBAQEDAQEBDyg0FwQCAQgNBAQBAQsUCQcnCxQJCAIEARIIARmHbgELmW6UfheQNTgGgxV7A542iwqCYD+CKw X-IronPort-AV: E=Sophos;i="4.89,933,1367985600"; d="scan'208";a="20859307" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Aug 2013 05:41:25 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Aug 2013 05:34:02 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Thu, 22 Aug 2013 05:41:19 -0400 From: "Romascanu, Dan (Dan)" To: "Bradner, Scott" , "opsawg@ietf.org" Thread-Topic: draft minutes of the opsawg session posted Thread-Index: AQHOns2LJnOijBCDeUiE9+C1R7vXyZmg9ppQ Date: Thu, 22 Aug 2013 09:41:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B5738@AZ-FFEXMB04.global.avaya.com> References: <2B482695-597C-43E4-BA33-ACE8C88750E1@harvard.edu> In-Reply-To: <2B482695-597C-43E4-BA33-ACE8C88750E1@harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] draft minutes of the opsawg session posted X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 09:41:33 -0000 Hi, s/Don Romascanu/Dan Romascanu/ s/ Benoit asks about 802.1 dates./ Benoit asks about 802.11 dates./ Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Bradner, Scott > Sent: Thursday, August 22, 2013 3:21 AM > To: opsawg@ietf.org > Subject: [OPSAWG] draft minutes of the opsawg session posted >=20 > please review & comment (if needed) >=20 > http://www.ietf.org/proceedings/87/minutes/minutes-87-opsawg >=20 > tnx >=20 > Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Thu Aug 22 08:14:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6534911E81E9 for ; Thu, 22 Aug 2013 08:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.226 X-Spam-Level: X-Spam-Status: No, score=-103.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCEE5kB30ZFh for ; Thu, 22 Aug 2013 08:14:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4345211E81E8 for ; Thu, 22 Aug 2013 08:14:30 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6019E20CC7; Thu, 22 Aug 2013 17:14:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Js-daOCl3g9y; Thu, 22 Aug 2013 17:14:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDFA320CA0; Thu, 22 Aug 2013 17:14:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B02F827FBEDE; Thu, 22 Aug 2013 17:14:22 +0200 (CEST) Date: Thu, 22 Aug 2013 17:14:22 +0200 From: Juergen Schoenwaelder To: Joe Marcus Clarke Message-ID: <20130822151422.GA5812@elstar.local> Mail-Followup-To: Joe Marcus Clarke , Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5215067C.3040000@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 15:14:37 -0000 On Wed, Aug 21, 2013 at 02:27:08PM -0400, Joe Marcus Clarke wrote: > That's fair. I was not aware of the ability to adjust VM CPU and memory > on the fly without touching the config. That said, I struggle to > understand the use case of doing this via SNMP versus a more reliable API. In the MIB world, we have ways to express things in such a way that people who want to implement a writable object can do so without causing costs to those who prefer to not do so. This is why we have MAX-ACCESS (what makes 'protocol sense' - means in principle this is a writable object) and MIN-ACCESS (the minimal level of access - means the minimum access one has to implement in order to comply to a conformance definition). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From i.goyret@alcatel-lucent.com Mon Aug 19 09:56:48 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D098C11E829B for ; Mon, 19 Aug 2013 09:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAShd-M0HgNn for ; Mon, 19 Aug 2013 09:56:43 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6E64F11E812E for ; Mon, 19 Aug 2013 09:56:43 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r7JGue0J017220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Aug 2013 11:56:40 -0500 (CDT) Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r7JGucCh031895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Aug 2013 11:56:39 -0500 Received: from igoyret-c1.alcatel-lucent.com (igoyret.lra.lucent.com [135.244.13.64]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id r7JGuYWp015221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 09:56:36 -0700 Message-Id: <201308191656.r7JGuYWp015221@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Aug 2013 09:54:56 -0700 To: Ted Lemon From: Ignacio Goyret In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominu m.com> References: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 X-Mailman-Approved-At: Thu, 22 Aug 2013 09:38:51 -0700 Cc: "" , "" , "trill-chairs@tools.ietf.org" , "l2tpext-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:56:48 -0000 I don't see any conflict with l2tpext wg work. -Ignacio At 07:43 8/19/2013, Ted Lemon wrote: >I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which is proposed for publication in the independent stream. I think this document does not conflict with the work that you are doing, but I would appreciate it if you could take a quick look at the document and make sure that you agree with me. > >http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02 > >Thanks! From mrm@vmware.com Thu Aug 22 09:56:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2239B21F9FDA for ; Thu, 22 Aug 2013 09:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-nqvWpJdsmx for ; Thu, 22 Aug 2013 09:56:18 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6B011E8104 for ; Thu, 22 Aug 2013 09:56:14 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 557A928E79; Thu, 22 Aug 2013 09:56:14 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 4C3781848A; Thu, 22 Aug 2013 09:56:14 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 3A1BCE00FC; Thu, 22 Aug 2013 09:56:14 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Thu, 22 Aug 2013 09:56:14 -0700 (PDT) Date: Thu, 22 Aug 2013 09:56:13 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder Message-ID: <808591269.35845201.1377190573938.JavaMail.root@vmware.com> In-Reply-To: <20130822151422.GA5812@elstar.local> References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB Thread-Index: /ICPCwajyRtpct3h2rJvIn9IWkW+nw== Cc: opsawg@ietf.org Subject: [OPSAWG] Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 16:56:22 -0000 Juergen, co-authors and spectators, Given our initial draft did not have writeable objects the original name of this mib module name was appropriate: =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0'Virtua= l Machine Monitoring MIB' Since the addition of configuration support, which I personally do not think is necessary to standardize, it has gone from monitor=20 to 'manage': http://datatracker.ietf.org/doc/draft-asai-vmm-mib/ =C2=A0=C2=A0 1. =C2=A0Introduction =C2=A0=C2=A0 This document defines a portion of the Management Information = Base =C2=A0=C2=A0 (MIB) for use with network management protocols in the Interne= t =C2=A0=C2=A0 community. =C2=A0In particular, this specifies objects for man= aging =C2=A0<=3D=3D=3D =C2=A0=C2=A0 virtual machines controlled by a hypervisor (a.k.a. virtual ma= chine =C2=A0=C2=A0 managers). I have the following proposal in order of my preference for your considerat= ion: 1) Drop config objects from VMM-MIB =C2=A0=C2=A0My argument is that we are not standardizing industry practice. =C2=A0=C2=A0A counter argument would be to point to one fielded MIB module = implementation=20 =C2=A0=C2=A0presently used in production a environment that can configure V= Ms today or have =C2=A0=C2=A0datacenter/network operators speak up about wanting this standa= rdized. 2) Move any/all config objects to a second MIB module either in this draft = or make another In any case if read-write variables will be standarized, then let's update = the =C2=A0=C2=A0 title and textual matter where appropriate to make clear the i= ncreased scope. Regards, Mike MacFaden From j.schoenwaelder@jacobs-university.de Thu Aug 22 10:22:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5B11E8112 for ; Thu, 22 Aug 2013 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJs3mWzOvSIx for ; Thu, 22 Aug 2013 10:22:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BA06C21F9E70 for ; Thu, 22 Aug 2013 10:22:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0282120CCE; Thu, 22 Aug 2013 19:22:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vFXcP4lAAaCc; Thu, 22 Aug 2013 19:22:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D72420CCD; Thu, 22 Aug 2013 19:22:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DF65D27FC1BF; Thu, 22 Aug 2013 19:21:55 +0200 (CEST) Date: Thu, 22 Aug 2013 19:21:55 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20130822172153.GA7508@elstar.local> Mail-Followup-To: Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> <808591269.35845201.1377190573938.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <808591269.35845201.1377190573938.JavaMail.root@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:22:14 -0000 On Thu, Aug 22, 2013 at 09:56:13AM -0700, Michael MacFaden wrote: > > Juergen, co-authors and spectators, > > Given our initial draft did not have writeable objects the > original name of this mib module name was appropriate: > >                   'Virtual Machine Monitoring MIB' > > Since the addition of configuration support, which I personally > do not think is necessary to standardize, it has gone from monitor > to 'manage': > > http://datatracker.ietf.org/doc/draft-asai-vmm-mib/ > >    1.  Introduction > >    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 >    managers). This is standard MIB boilerplate language. People probably read too much into all this. > I have the following proposal in order of my preference for your consideration: > > 1) Drop config objects from VMM-MIB >   My argument is that we are not standardizing industry practice. >   A counter argument would be to point to one fielded MIB module implementation >   presently used in production a environment that can configure VMs today or have >   datacenter/network operators speak up about wanting this standardized. There are no config objects. > 2) Move any/all config objects to a second MIB module either in this draft or make another > > In any case if read-write variables will be standarized, then let's update the >    title and textual matter where appropriate to make clear the increased scope. Since there are no config objects, 2) is a mood point. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mrm@vmware.com Thu Aug 22 10:34:43 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC23B11E810D for ; Thu, 22 Aug 2013 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hntdLpIsY6e8 for ; Thu, 22 Aug 2013 10:34:38 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id B4CE911E8106 for ; Thu, 22 Aug 2013 10:34:38 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 114AF28ED3; Thu, 22 Aug 2013 10:34:38 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 0D48E1854D; Thu, 22 Aug 2013 10:34:38 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id F0987E000E; Thu, 22 Aug 2013 10:34:37 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Thu, 22 Aug 2013 10:34:37 -0700 (PDT) Date: Thu, 22 Aug 2013 10:34:37 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder Message-ID: <347273129.35894516.1377192877771.JavaMail.root@vmware.com> In-Reply-To: <20130822172153.GA7508@elstar.local> References: <521158A7.2090407@cisco.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> <808591269.35845201.1377190573938.JavaMail.root@vmware.com> <20130822172153.GA7508@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB Thread-Index: qlMWqABn1ow3YjvNIVGQfEUztUAX9Q== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:34:43 -0000 > > 1) Drop config objects from VMM-MIB > > =C2=A0=C2=A0My argument is that we are not standardizing industry pract= ice. > > =C2=A0=C2=A0A counter argument would be to point to one fielded MIB mod= ule > > =C2=A0=C2=A0implementation > > =C2=A0=C2=A0presently used in production a environment that can configu= re VMs today > > =C2=A0=C2=A0or have > > =C2=A0=C2=A0datacenter/network operators speak up about wanting this st= andardized. >=20 > There are no config objects. Right, there are no VM config objects, there are two config objects: -- Notification definitions: vmPerVMNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if notification generator will send notifications per VM." ::=3D { vmObjects 9 } vmBulkNotificationsEnabled OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates if notification generator will send notifications per set of VMs." ::=3D { vmObjects 10 } Need more coffee this morning :-), I meant future edits to the mib module in the resolution of Proposal: Joe-3, I'm not interested in expanding the scope of the mib module to make MAX-ACC= ESS anything more than read-write so again my proposals would be on direction we'd take. Mike From d3e3e3@gmail.com Thu Aug 22 10:16:53 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5937D11E80ED for ; Thu, 22 Aug 2013 10:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xda+GKVS1Fv0 for ; Thu, 22 Aug 2013 10:16:52 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7389121F9EEE for ; Thu, 22 Aug 2013 10:16:52 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so4077854obb.23 for ; Thu, 22 Aug 2013 10:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=aW6MzyTCaHoRcbzrIkwO7XAUYuFwEthv0vSMHfE8/pI=; b=V4egZNcX2BRft3dsrhQPtL1bpObCVJuj3MJC09pM/dh0CIPHTIavMKGCy0/RjPdV1u LDHjDlzjPwzDM5fILAuyWskT1o+98rEUy0UUaIeKHxZnFDfZrK5pj5Goo73C1A0SvH3t ghhnfH/KdGYnO7E1Uy0sUA36hXZoAwNZ7tgq4v6P3/WMXqfTOcjJRuC+x/iRbIHK3iXx JKBtwH91Tmt5b3GT0SOnDxBnDESudZiLBcxn+cVpqwpqxIMhe2B6tCET7iKIPp1GQN25 VRdmH5VO3r/WZqIkEmeNYKMD/pf5oOYaOy+LvyFjUzTb+IJ1B8tDWPlKoHIOVMe0Y1kV 8VIA== X-Received: by 10.182.66.229 with SMTP id i5mr3121808obt.88.1377191811496; Thu, 22 Aug 2013 10:16:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.131.7 with HTTP; Thu, 22 Aug 2013 10:16:31 -0700 (PDT) In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominum.com> References: <8D23D4052ABE7A4490E77B1A012B63077525B953@mbx-01.win.nominum.com> From: Donald Eastlake Date: Thu, 22 Aug 2013 13:16:31 -0400 Message-ID: To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 22 Aug 2013 11:05:24 -0700 Cc: "" , "" , "trill-chairs@tools.ietf.org" , "l2tpext-chairs@tools.ietf.org" Subject: Re: [OPSAWG] Conflict review on draft-pfaff-ovsdb-proto-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 17:16:53 -0000 This draft seems to be about a pretty generic tabular database remote interface. I didn't read it super closely but it seems to so general as to have almost no binding with what open switch is about, although I'm sure with the right tables having the right rows and columns, you can indeed control a switch with it. I don't really see how this could conflict with any work expect possible some other generic tabular database remote interface specification. In any case, I do not see any conflict with TRILL. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Mon, Aug 19, 2013 at 10:43 AM, Ted Lemon wrote: > I've taken on the conflict review for draft-pfaff-ovsdb-proto-02, which i= s proposed for publication in the independent stream. I think this docume= nt does not conflict with the work that you are doing, but I would apprecia= te it if you could take a quick look at the document and make sure that you= agree with me. > > http://tools.ietf.org/html/draft-pfaff-ovsdb-proto-02 > > Thanks! > From Tina.Tsou.Zouting@huawei.com Thu Aug 22 15:17:09 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1711111E8132 for ; Thu, 22 Aug 2013 15:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWrOnx18pA1o for ; Thu, 22 Aug 2013 15:17:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF1311E8122 for ; Thu, 22 Aug 2013 15:17:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWI61966; Thu, 22 Aug 2013 22:16:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 22 Aug 2013 23:15:51 +0100 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 22 Aug 2013 23:16:46 +0100 Received: from SJCEML501-MBX.china.huawei.com ([169.254.1.183]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Thu, 22 Aug 2013 15:16:40 -0700 From: Tina TSOU To: Juergen Schoenwaelder Thread-Topic: [OPSAWG] Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB Thread-Index: AQHOn1inoF5Q1uC9lUq04JY+87V0ypmh7tmA///dAtI= Date: Thu, 22 Aug 2013 22:16:39 +0000 Message-ID: <4178560F-5485-40FD-AB88-ABF752DCB6CA@huawei.com> References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> <808591269.35845201.1377190573938.JavaMail.root@vmware.com>, <20130822172153.GA7508@elstar.local> In-Reply-To: <20130822172153.GA7508@elstar.local> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Proposal: mrm-1 Remove or move configuration objects in Virtual Machine Monitoring MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 22:17:09 -0000 Dear all, I agree with Juergen's points below. Thank you, Tina On Aug 22, 2013, at 10:22 AM, "Juergen Schoenwaelder" wrote: > On Thu, Aug 22, 2013 at 09:56:13AM -0700, Michael MacFaden wrote: >>=20 >> Juergen, co-authors and spectators, >>=20 >> Given our initial draft did not have writeable objects the >> original name of this mib module name was appropriate: >>=20 >> 'Virtual Machine Monitoring MIB' >>=20 >> Since the addition of configuration support, which I personally >> do not think is necessary to standardize, it has gone from monitor=20 >> to 'manage': >>=20 >> http://datatracker.ietf.org/doc/draft-asai-vmm-mib/ >>=20 >> 1. Introduction >>=20 >> 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 <=3D= =3D=3D >> virtual machines controlled by a hypervisor (a.k.a. virtual machine >> managers). >=20 > This is standard MIB boilerplate language. People probably read too > much into all this. >=20 >> I have the following proposal in order of my preference for your conside= ration: >>=20 >> 1) Drop config objects from VMM-MIB >> My argument is that we are not standardizing industry practice. >> A counter argument would be to point to one fielded MIB module impleme= ntation=20 >> presently used in production a environment that can configure VMs toda= y or have >> datacenter/network operators speak up about wanting this standardized. >=20 > There are no config objects. >=20 >> 2) Move any/all config objects to a second MIB module either in this dra= ft or make another >>=20 >> In any case if read-write variables will be standarized, then let's upda= te the >> title and textual matter where appropriate to make clear the increase= d scope. >=20 > Since there are no config objects, 2) is a mood point. ;-) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From jclarke@cisco.com Fri Aug 23 11:57:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5186E11E8107 for ; Fri, 23 Aug 2013 11:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbUFJR2wysCc for ; Fri, 23 Aug 2013 11:56:57 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 887B511E8100 for ; Fri, 23 Aug 2013 11:56:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7NIusup005501; Sat, 24 Aug 2013 03:56:55 +0900 (JST) Received: from prosciutto.local ([10.154.66.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7NIuo9C003947; Fri, 23 Aug 2013 11:56:50 -0700 (PDT) Message-ID: <5217B071.6040502@cisco.com> Date: Fri, 23 Aug 2013 14:56:49 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden , opsawg@ietf.org References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> In-Reply-To: <20130822151422.GA5812@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 18:57:03 -0000 On 8/22/13 11:14 AM, Juergen Schoenwaelder wrote: > On Wed, Aug 21, 2013 at 02:27:08PM -0400, Joe Marcus Clarke wrote: > >> That's fair. I was not aware of the ability to adjust VM CPU and memory >> on the fly without touching the config. That said, I struggle to >> understand the use case of doing this via SNMP versus a more reliable API. > > In the MIB world, we have ways to express things in such a way that > people who want to implement a writable object can do so without > causing costs to those who prefer to not do so. This is why we have > MAX-ACCESS (what makes 'protocol sense' - means in principle this is a > writable object) and MIN-ACCESS (the minimal level of access - means > the minimum access one has to implement in order to comply to a > conformance definition). I understand MAX-ACCESS and MIN-ACCESS. At this point I'm not arguing the access type as you've pointed out this can be non-persistently writable, and thus not a configuration object. In this comment I was merely inquiring, mainly out of curiosity, about the use case of an operator changing these values via SNMP vs. some other API mechanism. Meaning, today I see most MIB objects being read-only and used for monitoring or data collection. Writable objects are typically being pushed to APIs such as NETCONF. In _this_ case, I just assumed operators would be more comfortable changing aspects of a VM using a connection-oriented API vs. an SNMP SET. My other comment (not quoted here) is that I was asking if some more explicit text could be added to the compliance section of the MIB that says these objects should be implemented read-write if they can be done in a non-persistent way (essentially incorporating text from Section 3.2 into the MIB module itself). 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: jclarke@cisco.com ---------------------------------------------------------------------------- From randy_presuhn@mindspring.com Fri Aug 23 12:41:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C611E8168 for ; Fri, 23 Aug 2013 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2yupGKxZfHx for ; Fri, 23 Aug 2013 12:41:04 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id DEF8411E8112 for ; Fri, 23 Aug 2013 12:41:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bb1xbG6KQhzCfvDP4oN3eVvQ+gQUGG7uSFqXOcOJMz6E3ocgn8umiFEFcEY2/0Pl; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VCxEC-0004Lj-80 for opsawg@ietf.org; Fri, 23 Aug 2013 15:41:00 -0400 Received: from 99.30.225.132 by webmail.earthlink.net with HTTP; Fri, 23 Aug 2013 15:41:00 -0400 Message-ID: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Fri, 23 Aug 2013 12:41:00 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f084558ebe98e311b78ec3297b4f62991e3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:41:14 -0000 Hi - >From: Joe Marcus Clarke >Sent: Aug 23, 2013 11:56 AM >To: Michael MacFaden , opsawg@ietf.org >Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... >My other comment (not quoted here) is that I was asking if some more >explicit text could be added to the compliance section of the MIB that >says these objects should be implemented read-write if they can be done >in a non-persistent way (essentially incorporating text from Section 3.2 >into the MIB module itself). Just to be absolutely clear... Are you requesting that the normative text state that the values assigned to these object-types SHOULD NOT or MUST NOT persist across reboots? I really don't like the idea of standards prohibiting potentially useful functionality. Randy From jclarke@cisco.com Fri Aug 23 12:53:45 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B916011E810E for ; Fri, 23 Aug 2013 12:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak26RYLBPb2D for ; Fri, 23 Aug 2013 12:53:40 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05011E8106 for ; Fri, 23 Aug 2013 12:53:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7NJraJF012799; Sat, 24 Aug 2013 04:53:37 +0900 (JST) Received: from prosciutto.local ([10.154.66.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7NJrafR026715; Fri, 23 Aug 2013 12:53:36 -0700 (PDT) Message-ID: <5217BDBF.5000601@cisco.com> Date: Fri, 23 Aug 2013 15:53:35 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Presuhn References: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> In-Reply-To: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 19:53:45 -0000 On 8/23/13 3:41 PM, Randy Presuhn wrote: > Hi - > >> From: Joe Marcus Clarke >> Sent: Aug 23, 2013 11:56 AM >> To: Michael MacFaden , opsawg@ietf.org >> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) > ... >> My other comment (not quoted here) is that I was asking if some more >> explicit text could be added to the compliance section of the MIB that >> says these objects should be implemented read-write if they can be done >> in a non-persistent way (essentially incorporating text from Section 3.2 >> into the MIB module itself). > > Just to be absolutely clear... > Are you requesting that the normative text state that > the values assigned to these object-types SHOULD NOT > or MUST NOT persist across reboots? > > I really don't like the idea of standards prohibiting > potentially useful functionality. I was asking for the latter since this MIB is not about configuration. I think it would be a POLA violation if one vendor did a persistent implementation and some did a volatile implementation. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From melinda.shore@gmail.com Fri Aug 23 13:48:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841B621F9CAF for ; Fri, 23 Aug 2013 13:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVaDCi3+wEiB for ; Fri, 23 Aug 2013 13:48:39 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id BDEF121F91CE for ; Fri, 23 Aug 2013 13:48:38 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so1112210pbb.27 for ; Fri, 23 Aug 2013 13:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=jr0RXkh+/V7p5eMJ9jVyS3+cHCrJ3iViLgkaWzGC/TI=; b=Ll2GHF2yKul0FpU6yVIVoC/8ORCzv1j3l14zZSxxqUI3ui+9x6hhCPSjgGkTK9ZPrJ l8Jye3NjF376tVuy+4AbPEdlD+3dS5vBdvWqJG7V8vpncxcWgH5sKQ1+/1T2DiSUStrd uoz3Lni8ILHUNKw4Fyy/IrX8C6gXI6+tI1eZsddIU5ldbI8yOJUs8BUlTuAWEFu/QnAl fdaJPw/O7It3SBvzltLSy5aGnXCB0iOiJHOhq+xd9bMDdvsOV49wnVOI+Xh+On8LtCxB C8pZgylx+RfzeYujTVSnd4kIqMSvyWj5whO3Z55XOfpZd6PGP1pTF2aVXg4AiJZQVXrR bqSg== X-Received: by 10.66.25.205 with SMTP id e13mr777287pag.180.1377290918278; Fri, 23 Aug 2013 13:48:38 -0700 (PDT) Received: from spandex.local (209-193-57-23-rb1.fai.dsl.dynamic.acsalaska.net. [209.193.57.23]) by mx.google.com with ESMTPSA id w6sm1682056pbt.32.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 Aug 2013 13:48:37 -0700 (PDT) Message-ID: <5217CAA3.9050701@gmail.com> Date: Fri, 23 Aug 2013 12:48:35 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/mixed; boundary="------------090102090606080003020002" Subject: [OPSAWG] Fwd: [nvo3] Poll for WG adoption of draft-ashwood-nvo3-operational-requirement-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 20:48:39 -0000 This is a multi-part message in MIME format. --------------090102090606080003020002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Possibly of interest to opsawg participants. Melinda -------- Original Message -------- Subject: [nvo3] Poll for WG adoption of draft-ashwood-nvo3-operational-requirement-03 Date: Fri, 23 Aug 2013 15:19:15 +0000 From: Bocci, Matthew (Matthew) To: nvo3@ietf.org This email begins a two week poll to help the chairs determine if there is consensus to adopt draft-ashwood-nvo3-operational-requirement-03.txt as an NVO3 working group draft. The draft can be found here: http://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement-03.txt Please read the draft and indicate to the list if you support adoption, or if you do not support adoption (giving reasons). Please note that this is only a call for adoption. There needs to be consensus that this draft is a good basis for the work, but it does not need to be perfect at this stage. The poll for adoption will close in two weeks time, on Friday 6th September. Best regards, Matthew and Benson --------------090102090606080003020002 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 --------------090102090606080003020002-- From mrm@vmware.com Fri Aug 23 14:01:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4642911E8109 for ; Fri, 23 Aug 2013 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msmJjBoEwa-f for ; Fri, 23 Aug 2013 14:01:28 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4D11111E8108 for ; Fri, 23 Aug 2013 14:01:27 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 6AB5A29BBC; Fri, 23 Aug 2013 14:01:24 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 6554D402F3; Fri, 23 Aug 2013 14:01:24 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 520A6E0108; Fri, 23 Aug 2013 14:01:24 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Fri, 23 Aug 2013 14:01:24 -0700 (PDT) Date: Fri, 23 Aug 2013 14:01:24 -0700 (PDT) From: Michael MacFaden To: Joe Marcus Clarke Message-ID: <362143059.37152692.1377291684070.JavaMail.root@vmware.com> In-Reply-To: <5217B071.6040502@cisco.com> References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> <5217B071.6040502@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) Thread-Index: MZiDz6vqSjAo2vqR+UaZvbvOU18mHw== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 21:01:33 -0000 Hi Joe, Think there is agreement on the list that changes to the objects reported in VMM-MIB are not coming in through SNMP. If VMM-MIB has managed objects whose value are configured via other means *and* the hypervisor in question separates out (in cisco parlance) running-config (in memory) vs config (persisted) then what value will the agent report? Thanks, Mike ----- Original Message ----- > I understand MAX-ACCESS and MIN-ACCESS. At this point I'm not arguing > the access type as you've pointed out this can be non-persistently > writable, and thus not a configuration object. > > In this comment I was merely inquiring, mainly out of curiosity, about > the use case of an operator changing these values via SNMP vs. some > other API mechanism. Meaning, today I see most MIB objects being > read-only and used for monitoring or data collection. Writable objects > are typically being pushed to APIs such as NETCONF. In _this_ case, I > just assumed operators would be more comfortable changing aspects of a > VM using a connection-oriented API vs. an SNMP SET. > > My other comment (not quoted here) is that I was asking if some more > explicit text could be added to the compliance section of the MIB that > says these objects should be implemented read-write if they can be done > in a non-persistent way (essentially incorporating text from Section 3.2 > into the MIB module itself). > > 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: jclarke@cisco.com > > ---------------------------------------------------------------------------- > From jclarke@cisco.com Fri Aug 23 14:31:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3D711E810A for ; Fri, 23 Aug 2013 14:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8yBlGub41eh for ; Fri, 23 Aug 2013 14:31:54 -0700 (PDT) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2B0D11E818B for ; Fri, 23 Aug 2013 14:31:53 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from fire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7NLVoix025466; Sat, 24 Aug 2013 06:31:52 +0900 (JST) Received: from prosciutto.local ([10.154.66.153]) by fire.cisco.com (8.14.5+Sun/8.13.8) with ESMTP id r7NLVmEY022958; Fri, 23 Aug 2013 14:31:48 -0700 (PDT) Message-ID: <5217D4C3.5060604@cisco.com> Date: Fri, 23 Aug 2013 17:31:47 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Michael MacFaden References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> <5215067C.3040000@cisco.com> <20130822151422.GA5812@elstar.local> <5217B071.6040502@cisco.com> <362143059.37152692.1377291684070.JavaMail.root@vmware.com> In-Reply-To: <362143059.37152692.1377291684070.JavaMail.root@vmware.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 21:31:59 -0000 On 8/23/13 5:01 PM, Michael MacFaden wrote: > > Hi Joe, > > Think there is agreement on the list that changes to the objects reported in VMM-MIB are not > coming in through SNMP. > > > If VMM-MIB has managed objects whose value are configured > via other means *and* the hypervisor in question separates > out (in cisco parlance) running-config (in memory) > vs config (persisted) then what value will the agent report? Operational status would be the way I would read it given the current MIB definition. Now, if the VM is shutdown, that operational state would match the config state (for something like memory/CPU). Joe > > > Thanks, > Mike > > > ----- Original Message ----- >> I understand MAX-ACCESS and MIN-ACCESS. At this point I'm not arguing >> the access type as you've pointed out this can be non-persistently >> writable, and thus not a configuration object. >> >> In this comment I was merely inquiring, mainly out of curiosity, about >> the use case of an operator changing these values via SNMP vs. some >> other API mechanism. Meaning, today I see most MIB objects being >> read-only and used for monitoring or data collection. Writable objects >> are typically being pushed to APIs such as NETCONF. In _this_ case, I >> just assumed operators would be more comfortable changing aspects of a >> VM using a connection-oriented API vs. an SNMP SET. >> >> My other comment (not quoted here) is that I was asking if some more >> explicit text could be added to the compliance section of the MIB that >> says these objects should be implemented read-write if they can be done >> in a non-persistent way (essentially incorporating text from Section 3.2 >> into the MIB module itself). >> >> 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: jclarke@cisco.com >> >> ---------------------------------------------------------------------------- >> > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From internet-drafts@ietf.org Fri Aug 23 21:10:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02B521F9E21; Fri, 23 Aug 2013 21:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ1P-wcWSJTb; Fri, 23 Aug 2013 21:10:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 215AB21F9E01; Fri, 23 Aug 2013 21:10:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130824041058.27610.67259.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2013 21:10:58 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-05.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 04:10:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Mechanisms for Optimal LAG/ECMP Component Link Utilizati= on in Networks Author(s) : Ram Krishnan Lucy Yong Anoop Ghanwani Ning So Sanjay Khanna Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-05.txt Pages : 23 Date : 2013-08-23 Abstract: Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-large-flow-load-balanc= ing-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From panda@hongo.wide.ad.jp Sat Aug 24 02:27:11 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CC121F9E91 for ; Sat, 24 Aug 2013 02:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4vraL+5xdVm for ; Sat, 24 Aug 2013 02:27:05 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id A148A21F9E83 for ; Sat, 24 Aug 2013 02:27:05 -0700 (PDT) Received: from [157.82.4.219] (unknown [157.82.4.219]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id C71A2108E8C1; Sat, 24 Aug 2013 18:20:45 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <20130820063754.GC1861@elstar.local> Date: Sat, 24 Aug 2013 18:27:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 09:27:11 -0000 Thank you for your comments and I'm sorry for responding late. On Aug 20, 2013, at 3:37 PM, Juergen Schoenwaelder = wrote: >> Is there a strong push from operators to toggle these values via = SNMP? >=20 > Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it > 'defines whether it makes "protocol sense" to read, write and/or > create an instance of the object, or to include its value in a > notification'. The compliance statement vmReadOnlyCompliances says > that write access is not required to be implemented. I believe this is > how we commonly do things in a MIB module - we allow read-write > implementations but we do not require read-write implementations. > Hence, I prefer to make no changes (except perhaps vmAutoStart but I > need to check whether there are hypervisors that actually allow to > change autostart behaviour of the running instance without touching > persistent config - this might actually be possible). Now I've confirmed that vmAutoStart touches persistent config in = libvirt. I agree that vmAutoStart probably touches persistent config in the most of implementations because it takes the effect at the next boot sequence of the hypervisor. If an implementation has one-shot config only for = the next boot, it should be another object. Thus, I'll change the MAX-ACCESS of vmAutoStart to read-only. Thank you. Hirochika --=20 Hirochika Asai , The University of Tokyo From keiichi.shima.1016@gmail.com Sat Aug 24 04:52:53 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5821F89A6 for ; Sat, 24 Aug 2013 04:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb8OO-fClIfq for ; Sat, 24 Aug 2013 04:52:53 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 852A921F8956 for ; Sat, 24 Aug 2013 04:52:51 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc17so1660437pbc.4 for ; Sat, 24 Aug 2013 04:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=jjAOKrvB2yHO7qWd2sD/hNBjVHn2LX+QRw4rhuYxMsg=; b=NnNEg+BJOl/KqzhdVdS7LdqcwoWvAE4DdDKd/fYYmN6SjAb2N46IXGEWTfkTmue65A mmiBGbD3PDINANP5YRtQEB/1ZaIac+W4YtycSn5WkXJDP8FcOx/hkdPeoDCsPl2Rb3QK mv0+JbbqOJv8yO/2+ahkxLF46rZSQ3X4wrXcgeK4+VbRrEJEe5JtIVS/zdLz/R6Vc3b0 RC6zV6UTn/lRL2e+fMP8lrqtyRZxLlw8qEWwDYPcANUlHMST3YFBC6e8QS0YuFqnIyAw pLp4hxPRyHU4tI1BwR/k7vjqGB1+hitF1QsgJS4I54p/HLdrN/58iRdVN5DCn6qK+QZl 2adw== X-Received: by 10.68.130.71 with SMTP id oc7mr4915446pbb.10.1377345171253; Sat, 24 Aug 2013 04:52:51 -0700 (PDT) Received: from [192.168.10.100] (p110-74-62-228.sub.ne.jp. [110.74.62.228]) by mx.google.com with ESMTPSA id sz3sm5771210pbc.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 04:52:50 -0700 (PDT) Sender: Keiichi SHIMA From: Keiichi SHIMA Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Aug 2013 20:52:47 +0900 Message-Id: To: "opsawg@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 11:52:54 -0000 Hi, Let me ask one question about vmAdminState values. In the latest VMM-MIB draft = (http://www.ietf.org/id/draft-asai-vmm-mib-04.txt), the values for = vmAdminState are defined as below. INTEGER { unknown(1), other(2), preparing(3), running(4), blocked(5), suspending(6), suspended(7), resuming(8), paused(9), migrating(10), shuttingdown(11), shutdown(12), crashed(13) } Also, how the state transits is shown in Figure 2. However, in the above description, the 'blocked' state is quite unclear = to me. What precisely does the 'blocked' state mean? When does a virtual = machine transit to the 'blocked' state? I think we need more text about = the state, if we want to keep the state. Regards, --- Keiichi SHIMA (=1B$BEg=1B(B =1B$B7D0l=1B(B) WIDE project Research Laboratory, IIJ Innovation Institute, Inc From jclarke@cisco.com Sat Aug 24 12:03:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6069311E8177 for ; Sat, 24 Aug 2013 12:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX-A7gae2mjF for ; Sat, 24 Aug 2013 12:03:32 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id ECEBF11E8167 for ; Sat, 24 Aug 2013 12:03:31 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7OJ3OYl002870; Sat, 24 Aug 2013 21:03:24 +0200 (CEST) Received: from rtp-vpn2-223.cisco.com (rtp-vpn2-223.cisco.com [10.82.240.223]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7OJ38t1011488; Sat, 24 Aug 2013 15:03:09 -0400 (EDT) Message-ID: <5219036E.40901@cisco.com> Date: Sat, 24 Aug 2013 15:03:10 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hirochika Asai References: <521158A7.2090407@cisco.com> <1831198276.32845557.1376936766818.JavaMail.root@vmware.com> <20130819183443.GB477@elstar.local> <52128244.8060107@cisco.com> <20130820063754.GC1861@elstar.local> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 19:03:37 -0000 On 8/24/13 5:27 AM, Hirochika Asai wrote: > > Thank you for your comments and I'm sorry for responding late. > > On Aug 20, 2013, at 3:37 PM, Juergen Schoenwaelder wrote: >>> Is there a strong push from operators to toggle these values via SNMP? >> >> Remeber that this is a MAX-ACCESS. RFC 2578 section 7.3 says that it >> 'defines whether it makes "protocol sense" to read, write and/or >> create an instance of the object, or to include its value in a >> notification'. The compliance statement vmReadOnlyCompliances says >> that write access is not required to be implemented. I believe this is >> how we commonly do things in a MIB module - we allow read-write >> implementations but we do not require read-write implementations. >> Hence, I prefer to make no changes (except perhaps vmAutoStart but I >> need to check whether there are hypervisors that actually allow to >> change autostart behaviour of the running instance without touching >> persistent config - this might actually be possible). > > > Now I've confirmed that vmAutoStart touches persistent config in libvirt. > I agree that vmAutoStart probably touches persistent config in the most > of implementations because it takes the effect at the next boot sequence > of the hypervisor. If an implementation has one-shot config only for the > next boot, it should be another object. > Thus, I'll change the MAX-ACCESS of vmAutoStart to read-only. Thanks. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From melinda.shore@gmail.com Sat Aug 24 13:07:10 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3F11E8174 for ; Sat, 24 Aug 2013 13:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtgD7oef6KEn for ; Sat, 24 Aug 2013 13:07:09 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3307F11E80E4 for ; Sat, 24 Aug 2013 13:07:08 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id lb1so1921002pab.40 for ; Sat, 24 Aug 2013 13:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=UfBMjSAg/xzbFujDve5C1qpmw/BMuUFzYfHsC+DCbVE=; b=Fq+HJ28T8SC9MxqvvTf9UkAQwCQ12l2J14O3sUwAQmIlRMMgqkuBPGz0Tfdk7BUP1f cr5l2Pg2bosEJqVL5cuUO1+uYMa5Up4gYWiZ9fMorQ+cG50LCeq/78HjQZo2r8EfuE16 60fskD/AJDpip6uzUWf9xuGtLwHJAIvQ0VDRJbC14Huwz97D59IBct2IjqtO6Msf0YMY Zg5oCSV1gYJntDeUz4SJ3Xro3gyAXx5CnSnvO5HMJVqh4K/F9KlOEXaILJs8cdD96xnS 1DmI4QzM3hCzmW+/aPxNBEiAzfWdsDarjYjHJIKNwx9F8H9cX1eZov+wbj2G/y/dTjrW BhLw== X-Received: by 10.68.219.104 with SMTP id pn8mr6542874pbc.81.1377374827926; Sat, 24 Aug 2013 13:07:07 -0700 (PDT) Received: from spandex.local (66-230-82-92-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.92]) by mx.google.com with ESMTPSA id dg3sm7847436pbc.24.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 13:07:07 -0700 (PDT) Message-ID: <52191268.5070500@gmail.com> Date: Sat, 24 Aug 2013 12:07:04 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg-chairs@tools.ietf.org" Subject: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 20:07:10 -0000 This is to announce the start of working group last call on: Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list by September 9, 2013 Thanks, opsawg chairs From dromasca@avaya.com Sun Aug 25 01:12:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE7A11E823C for ; Sun, 25 Aug 2013 01:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.312 X-Spam-Level: X-Spam-Status: No, score=-103.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxPUkf6o4DF7 for ; Sun, 25 Aug 2013 01:11:54 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id BAA4011E8233 for ; Sun, 25 Aug 2013 01:11:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgKAKu7GVKHCzI1/2dsb2JhbABZgmYhNVGrYgeULIEaFnSCJAEBAQEDEgsdOAIRBAIBCA0EAwEBAQsUCQcyFAkIAgQBEggTB4dfAQuaJpwRF48vgRg4BoMWfQOZG4UkixCBY4E7gXE5 X-IronPort-AV: E=Sophos;i="4.89,950,1367985600"; d="scan'208";a="21219670" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Aug 2013 04:11:52 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Aug 2013 04:04:10 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Sun, 25 Aug 2013 10:11:32 +0200 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Fwd: [nvo3] Poll for WG adoption of draft-ashwood-nvo3-operational-requirement-03 Thread-Index: AQHOoEIngrAGuv7kZE2ZsyK36DKh9pmllB1w Date: Sun, 25 Aug 2013 08:11:31 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA128B7090@AZ-FFEXMB04.global.avaya.com> References: <5217CAA3.9050701@gmail.com> In-Reply-To: <5217CAA3.9050701@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Fwd: [nvo3] Poll for WG adoption of draft-ashwood-nvo3-operational-requirement-03 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 08:12:01 -0000 Hi,=20 I sent a comment to the NVO3 list, as I believe that this document is not a= good and complete basis for what their charter asks for.=20 The charter of the NVO3 WG speaks about writing an Informational document t= hat describes Operational Requirements. The I-D draft-ashwood-nvo3-operatio= nal-requirement-03.txt is not such a document, excepting its title. It take= s as a model RFC 6136 which is an OAM requirements document. There is a cle= ar difference between Operational Requirements and OAM Requirements. When w= e talk about Operational Requirements I for a new protocol or for protocol = extensions I would expect to find information and derived requirements abou= t operational environments, installation and set-up, migration path from cu= rrent deployed networks, relation, coexistence and interaction with already= deployed protocol, and impact on network operations. Yes, as a result of t= he operational requirements there may be a need to deploy OAM, and OAM requ= irements may be part of the solution and be described in the same document = or in different documents, but Operations means more than just OAM.=20 I also offered RFC 5706 as a set of guidelines on operational information a= nd requirements for new protocols or extending existing protocols.=20 =20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Friday, August 23, 2013 11:49 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Fwd: [nvo3] Poll for WG adoption of draft-ashwood- > nvo3-operational-requirement-03 >=20 > Possibly of interest to opsawg participants. >=20 > Melinda >=20 >=20 > -------- Original Message -------- > Subject: [nvo3] Poll for WG adoption of > draft-ashwood-nvo3-operational-requirement-03 > Date: Fri, 23 Aug 2013 15:19:15 +0000 > From: Bocci, Matthew (Matthew) > To: nvo3@ietf.org >=20 >=20 >=20 > This email begins a two week poll to help the chairs determine if there > is consensus to adopt draft-ashwood-nvo3-operational-requirement-03.txt > as an NVO3 working group draft. >=20 > The draft can be found here: > http://tools.ietf.org/id/draft-ashwood-nvo3-operational-requirement- > 03.txt >=20 > Please read the draft and indicate to the list if you support adoption, > or if you do not support adoption (giving reasons). >=20 > Please note that this is only a call for adoption. There needs to be > consensus that this draft is a good basis for the work, but it does not > need to be perfect at this stage. >=20 > The poll for adoption will close in two weeks time, on Friday 6th > September. >=20 > Best regards, >=20 > Matthew and Benson >=20 From j.schoenwaelder@jacobs-university.de Mon Aug 26 04:00:08 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D11211E8188 for ; Mon, 26 Aug 2013 04:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.231 X-Spam-Level: X-Spam-Status: No, score=-103.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TgkWKDX4a0X for ; Mon, 26 Aug 2013 04:00:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E943A11E8185 for ; Mon, 26 Aug 2013 04:00:03 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6282720D59; Mon, 26 Aug 2013 13:00:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BLlASv13UzXW; Mon, 26 Aug 2013 13:00:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3CFE20D58; Mon, 26 Aug 2013 13:00:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 248AB27FFC31; Mon, 26 Aug 2013 12:59:55 +0200 (CEST) Date: Mon, 26 Aug 2013 12:59:55 +0200 From: Juergen Schoenwaelder To: Keiichi SHIMA Message-ID: <20130826105955.GA17723@elstar.local> Mail-Followup-To: Keiichi SHIMA , "opsawg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 11:00:08 -0000 On Sat, Aug 24, 2013 at 08:52:47PM +0900, Keiichi SHIMA wrote: > Hi, > > Let me ask one question about vmAdminState values. > > In the latest VMM-MIB draft (http://www.ietf.org/id/draft-asai-vmm-mib-04.txt), the values for vmAdminState are defined as below. You are actually asking a question about VirtualMachineOperState... > > INTEGER { > unknown(1), > other(2), > preparing(3), > running(4), > blocked(5), > suspending(6), > suspended(7), > resuming(8), > paused(9), > migrating(10), > shuttingdown(11), > shutdown(12), > crashed(13) > } > > Also, how the state transits is shown in Figure 2. > > However, in the above description, the 'blocked' state is quite unclear to me. The current description is this: blocked(5) The virtual machine is currently blocked. > What precisely does the 'blocked' state mean? When does a virtual > machine transit to the 'blocked' state? I think we need more text > about the state, if we want to keep the state. The blocked state covers situations where a virtual machine is blocked because it waits for certain service requests to complete. For example, if you use Xen, then a DomU delegates most of the low-level input/output to Dom0 and while waiting for Dom0 to finish processing a request, the DomU issuing the request is 'blocked'. Would this clarification help: blocked(5) The virtual machine is currently blocked waiting for example for some action of the hypervisor to finish. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ghanwani@gmail.com Tue Aug 27 12:16:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315E611E8134 for ; Tue, 27 Aug 2013 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EdLyFT-W16Q for ; Tue, 27 Aug 2013 12:16:48 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF9811E81BC for ; Tue, 27 Aug 2013 12:16:48 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e11so1436675wgh.33 for ; Tue, 27 Aug 2013 12:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2hnTfG1Hb1wH3vmT2Tq6fLQTs7rds8SPPUVqeMgFK+g=; b=kkAuqbnvpMZ6NR4TRuExSEWNFPMxg0TmwiW7Ck5rMtfmZ5G1gGSBpu8AJ6FKajc1Cd qpw4DTmgE6fDB1JLxnlfkJv9JdkUZxxXa3TxKRzvd+Tfwo0/Ikdb0HTj2J77R+dnmVpx 9hnqDteWfRL8k5qw2gwLzUj9Hak7Q2w/C1CFsSZ0c0XAbmfy1u8Vvhx5ffcUY7VDoDHq 73rvLpm085+kG1mT2fD9KGYYXU9jQ5R8j6jPx/Kx/bi8vD8Thl00fQwvGNGc7QtGOLZf JWv9Q5Vn4pJWwDMdsdRXI0gqgkTvAfGARAf4dbZ0nBFjW5bt5zUT3ereH1EVIyRzXlcd W1TA== MIME-Version: 1.0 X-Received: by 10.180.77.80 with SMTP id q16mr12814391wiw.17.1377631007338; Tue, 27 Aug 2013 12:16:47 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.216.70.73 with HTTP; Tue, 27 Aug 2013 12:16:47 -0700 (PDT) In-Reply-To: <52191268.5070500@gmail.com> References: <52191268.5070500@gmail.com> Date: Tue, 27 Aug 2013 12:16:47 -0700 X-Google-Sender-Auth: pAOtJymcCIPEHqvq3Mn4mvmmIMM Message-ID: From: Anoop Ghanwani To: Melinda Shore Content-Type: multipart/alternative; boundary=f46d0438906dd2f55504e4f2b62d Cc: "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 19:16:49 -0000 --f46d0438906dd2f55504e4f2b62d Content-Type: text/plain; charset=ISO-8859-1 I support this document (as a co-author). There seem to be some minor typos that slipped through the cracks during the last edit. - Alignment in Fig 2. - Extraneous period in 4.4.3. Anoop On Sat, Aug 24, 2013 at 1:07 PM, Melinda Shore wrote: > This is to announce the start of working group last call on: > > Mechanisms for Optimal LAG/ECMP Component Link Utilization in > Networks > > > http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing/ > > It is intended for publication as an informational RFC. > > Please give it a careful read and provide any feedback to this > mailing list by September 9, 2013 > > Thanks, > > opsawg chairs > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --f46d0438906dd2f55504e4f2b62d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I support this document (as a co-author).

There seem to be some minor typos that slipped through the cracks during= the last edit.
- Alignment in Fig 2.
- Extraneous peri= od in 4.4.3.

Anoop


On Sat, Aug 24, 2013 at 1:07 PM, Melinda Shore <m= elinda.shore@gmail.com> wrote:
This is to announce the start of working gro= up last call on:

=A0 =A0 Mechanisms for Optimal LAG/ECMP Component Link Utilization in
=A0 =A0 =A0 =A0 Networks

http://datatracker.ietf.org/doc/draft-ietf-= opsawg-large-flow-load-balancing/

It is intended for publication as an informational RFC.

Please give it a careful read and provide any feedback to this
mailing list by September 9, 2013

Thanks,

opsawg chairs
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--f46d0438906dd2f55504e4f2b62d-- From ramk@Brocade.com Tue Aug 27 13:24:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA35E21F9A78 for ; Tue, 27 Aug 2013 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccrG7Yht1-mO for ; Tue, 27 Aug 2013 13:24:11 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3421F9831 for ; Tue, 27 Aug 2013 13:24:08 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r7RKD5Yv000980; Tue, 27 Aug 2013 13:24:04 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1eh2xug074-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Aug 2013 13:24:04 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 27 Aug 2013 13:24:04 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 27 Aug 2013 13:24:03 -0700 From: ramki Krishnan To: Melinda Shore , "opsawg@ietf.org" Date: Tue, 27 Aug 2013 13:24:33 -0700 Thread-Topic: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" Thread-Index: Ac6hBYdGjNUH7TXxRYujplQ94KPM7QCXcEYA Message-ID: References: <52191268.5070500@gmail.com> In-Reply-To: <52191268.5070500@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-27_08:2013-08-27, 2013-08-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308270106 Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:24:16 -0000 I support this as a co-author. Thanks, Ramki -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Saturday, August 24, 2013 1:07 PM To: opsawg@ietf.org Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Compone= nt Link Utilization in Networks" This is to announce the start of working group last call on: Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing= / It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list= by September 9, 2013 Thanks, opsawg chairs _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From lucy.yong@huawei.com Tue Aug 27 22:13:48 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6152211E8140 for ; Tue, 27 Aug 2013 22:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyWTIdHlEfrd for ; Tue, 27 Aug 2013 22:13:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5904011E8128 for ; Tue, 27 Aug 2013 22:13:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWQ77835; Wed, 28 Aug 2013 05:13:36 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 06:12:47 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 06:13:33 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.52]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Tue, 27 Aug 2013 22:13:30 -0700 From: Lucy yong To: ramki Krishnan , Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" Thread-Index: AQHOoQWLetMrHBBFKEmWF4sEWV8kNZmp+i+AgAAeXuA= Date: Wed, 28 Aug 2013 05:13:29 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452A34C5@dfweml509-mbx.china.huawei.com> References: <52191268.5070500@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 05:13:48 -0000 Support as a co-author. Lucy -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= ramki Krishnan Sent: Tuesday, August 27, 2013 1:25 PM To: Melinda Shore; opsawg@ietf.org Cc: opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Com= ponent Link Utilization in Networks" I support this as a co-author. Thanks, Ramki -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Saturday, August 24, 2013 1:07 PM To: opsawg@ietf.org Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Compone= nt Link Utilization in Networks" This is to announce the start of working group last call on: Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing= / It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list= by September 9, 2013 Thanks, opsawg chairs _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From ningso@yahoo.com Wed Aug 28 07:16:39 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4949221E804E for ; Wed, 28 Aug 2013 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q92tegKNFlNX for ; Wed, 28 Aug 2013 07:16:33 -0700 (PDT) Received: from nm4-vm1.bullet.mail.ne1.yahoo.com (nm4-vm1.bullet.mail.ne1.yahoo.com [98.138.91.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E60B21E8050 for ; Wed, 28 Aug 2013 07:16:33 -0700 (PDT) Received: from [98.138.101.132] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 28 Aug 2013 14:16:32 -0000 Received: from [98.138.89.234] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 28 Aug 2013 14:16:32 -0000 Received: from [127.0.0.1] by omp1049.mail.ne1.yahoo.com with NNFMP; 28 Aug 2013 14:16:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 673176.63650.bm@omp1049.mail.ne1.yahoo.com Received: (qmail 82513 invoked by uid 60001); 28 Aug 2013 14:16:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1377699392; bh=F/xw8sFJpyX6DIiuL/ZfduupoEY+iF/vZXsHH8aG/Sw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=AQ5o0g8h2XY2n9bq7WcPGKu28q+d2Lv6A/ptm/RJQy+1krmfGgz8jmXFwwOTxNLQ0CRmqv4ivOuLRzCytVf8vIdJ4wsyE/L4M2/tiVeMZzoZgj1tDcR8//UMmr8NL6yqvG1uvywhcb5kZE/mqPQjbDz8QRpxhKOsrxBkkTcKfn4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BoEzM2LT6+4Qr/tGKijcbZ5JaQTplKJvAQT1YdjsiIC9rirxaBMXSxTREXycIApKZTAouKHuPJOLt6Mgr9eax2twrcC88GtGZm9ugSdjHBUUftWHHzbydOGuYtPsR8NHzfX4h6/PjiysY2F5JvkWHl8kFXNZIK+0KZv7mGv604c=; X-YMail-OSG: xyE7IyoVM1nZvyEdVR19a3akmWiYzcp_Vv8lBfCNUJIjiKH GTBd1VTw_yVWqQH8q_Jb4rTjrcGsMTYtAmtY3jyE92u1g8iyjsahz9pI9DYd nW.Cy1JoQktPMcSTtRVLG0nfAzIwcuD_R4Rn7jdpdJ4YuF1xRPc7mHQRgadi awNkHAWe7M2WcX67Ww7e0LLOF5zK5DBrXZKQ_muXtdUfNClNaUHQ4DwQMheu uFBeMTq3F3mpH2ZF6h1EuNMEF3ueC7Tfgp_ELBqhkITFCyN4Jo7WHkvdJ2mJ npBMxWtdl1Sw1ofHd2pYp794u5Go68yR95iVBk3HCx9.h1vBjgIByM_590xJ s8XnG99Qvr2ocxajS_Jv0AghhAATF2JezkeJiLOIucVQl.KU0eGHuBvDSiwQ uVvH4nnExUZtG6HNDbmQwrk.kUBeR97ni_w7h_5kjQt.jgJebAgeBpTc3F5D qHzw6gS0wbu8hXunxTa9jGA6P.2Z_wuJ9FvKzrHXtkj0d_1hgdhwAPOHOR58 oztLWAajtMVGEJ2mwClIOqFWafhf76N2jd0TzCnUNAj6t3lwKDwh6scHmQhK 3gQQY97vImXrl0ojuZl9hTQfuhOnzOPhiR.of Received: from [173.57.100.67] by web120305.mail.ne1.yahoo.com via HTTP; Wed, 28 Aug 2013 07:16:32 PDT X-Rocket-MIMEInfo: 002.001, U3VwcG9ydCBhcyBjby1hdXRob3IuCgpOaW5nIFNvCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogb3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvcHNhd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1lbGluZGEgU2hvcmUKU2VudDogU2F0dXJkYXksIEF1Z3VzdCAyNCwgMjAxMyAxOjA3IFBNClRvOiBvcHNhd2dAaWV0Zi5vcmcKQ2M6IG9wc2F3Zy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcKU3ViamVjdDogW09QU0FXR10gV0cgbGFzdCBjYWxsIGZvciAiTWVjaGFuaXNtcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.156.576 References: Message-ID: <1377699392.82231.YahooMailNeo@web120305.mail.ne1.yahoo.com> Date: Wed, 28 Aug 2013 07:16:32 -0700 (PDT) From: Ning So To: "opsawg@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1278015569-1633775444-1377699392=:82231" Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 14:16:39 -0000 ---1278015569-1633775444-1377699392=:82231 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Support as co-author.=0A=0ANing So=0A=0A=0A-----Original Message-----=0AFro= m: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Me= linda Shore=0ASent: Saturday, August 24, 2013 1:07 PM=0ATo: opsawg@ietf.org= =0ACc: opsawg-chairs@tools.ietf.org=0ASubject: [OPSAWG] WG last call for "M= echanisms for Optimal LAG/ECMP Component Link Utilization in Networks"=0A= =0AThis is to announce the start of working group last call on:=0A=0A=A0 = =A0 Mechanisms for Optimal LAG/ECMP Component Link Utilization in=0A=A0 =A0= =A0 =A0 Networks=0A=0Ahttp://datatracker.ietf.org/doc/draft-ietf-opsawg-la= rge-flow-load-balancing/=0A=0AIt is intended for publication as an informat= ional RFC.=0A=0APlease give it a careful read and provide any feedback to t= his mailing list by September 9, 2013=0A=0AThanks,=0A=0Aopsawg chairs=0A___= ____________________________________________=0AOPSAWG mailing list=0AOPSAWG= @ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/opsawg=0A________________= _______________________________=0AOPSAWG mailing list=0AOPSAWG@ietf.org=0Ah= ttps://www.ietf.org/mailman/listinfo/opsawg=0A=0A=0A-----------------------= -------=0A=0A_______________________________________________=0AOPSAWG maili= ng list=0AOPSAWG@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/opsawg=0A= =0A=0AEnd of OPSAWG Digest, Vol 75, Issue 77=0A****************************= ********** ---1278015569-1633775444-1377699392=:82231 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Support as co-author.=

Ning So
-----Original Message-----
From: opsawg-bounces@ietf.org= [mailto:opsawg-bounces@ietf.org] On Behalf Of Melinda Shore=
Sent: Saturday, August 24, 2013 1:07 PM
To: opsawg@ietf.org
Cc: opsawg-chairs@tools.ietf.org
Subject: [OPSAWG] WG= last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks"
This is to announce the start of working group last call on:

&= nbsp;   Mechanisms for Optimal LAG/ECMP Component Link Utilization in<= br>        Networks

http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balan= cing/

It is intended for publication as an informational RFC.
Please give it a careful read and provide any feedback to this mailing= list by September 9, 2013

Thanks,

opsawg chairs
_________= ______________________________________
OPSAWG mailing list
OPSAWG@ietf.org=
https://www.ietf.org/mailman/listinfo/opsawg
____= ___________________________________________
OPSAWG mailing list
OPSAWG@iet= f.org
https://www.ietf.org/mailman/listinfo/opsawg


--= ----------------------------

_______________________________________= ________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/m= ailman/listinfo/opsawg


End of OPSAWG Digest, Vol 75, Issue 7= 7
**************************************


=
---1278015569-1633775444-1377699392=:82231-- From sob@harvard.edu Wed Aug 28 08:54:55 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A050021F9E88 for ; Wed, 28 Aug 2013 08:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.74 X-Spam-Level: X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afdYtREimrQC for ; Wed, 28 Aug 2013 08:54:49 -0700 (PDT) Received: from ackroyd.harvard.edu (ackroyd.harvard.edu [128.103.208.29]) by ietfa.amsl.com (Postfix) with ESMTP id C033721F9E5C for ; Wed, 28 Aug 2013 08:54:49 -0700 (PDT) Received: from exchange.university.harvard.edu (entwedge0000003.university.harvard.edu [10.35.202.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ackroyd.harvard.edu (Postfix) with ESMTP id 1439AEA3AE for ; Wed, 28 Aug 2013 11:54:49 -0400 (EDT) Received: from ENTWHUBT0000002.university.harvard.edu (192.168.36.23) by entwedge0000003.university.harvard.edu (10.35.202.50) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 28 Aug 2013 11:54:39 -0400 Received: from ENTWEXMB0000008.university.harvard.edu ([169.254.1.134]) by entwhubt0000002.university.harvard.edu ([192.168.36.46]) with mapi id 14.03.0146.000; Wed, 28 Aug 2013 11:54:48 -0400 From: "Bradner, Scott" To: "opsawg@ietf.org" Thread-Topic: updated draft minutes of opsawg session Thread-Index: AQHOpAbsPg5qy7gYX0yZrgwS0DEzNQ== Date: Wed, 28 Aug 2013 15:54:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.103.229.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <0DB9D8E2F2080E4599A306107D9A4751@Exchange.university.harvard.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] updated draft minutes of opsawg session X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 15:54:55 -0000 I updated the draft opsawg minutes with some good noted taken by Tom Taylor thanks Tom Scott Scott O Bradner Senior Technology Consultant Harvard University Information Technology Innovation & Architecture (P) +1 (617) 495 3864 1033 Mass Ave, room 462 Cambridge, MA 02138 From panda@hongo.wide.ad.jp Thu Aug 29 01:28:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BE221F9DFB for ; Thu, 29 Aug 2013 01:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH2oev2b1fnK for ; Thu, 29 Aug 2013 01:28:13 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id CE49921F9DB4 for ; Thu, 29 Aug 2013 01:28:03 -0700 (PDT) Received: from [IPv6:2001:200:180:305:d15f:b863:2482:1bd7] (unknown [IPv6:2001:200:180:305:d15f:b863:2482:1bd7]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 08D53108DE5F; Thu, 29 Aug 2013 17:18:28 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <5217BDBF.5000601@cisco.com> Date: Thu, 29 Aug 2013 17:27:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <753543F6-4804-4BBC-A3D2-456EF9DF8DC9@hongo.wide.ad.jp> References: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <5217BDBF.5000601@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 08:28:36 -0000 As for the read-write objects, i.e., vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem, I changed the following phrase for the next version of the draft. (deleted) Changes to this object may not persist across restarts of the = hypervisor (added) Changes to this object must not persist across restarts of the = hypervisor Thank you. Hirochika On Aug 24, 2013, at 4:53 AM, Joe Marcus Clarke = wrote: >> Just to be absolutely clear... >> Are you requesting that the normative text state that >> the values assigned to these object-types SHOULD NOT >> or MUST NOT persist across reboots? >>=20 >> I really don't like the idea of standards prohibiting >> potentially useful functionality. >=20 > I was asking for the latter since this MIB is not about configuration. > I think it would be a POLA violation if one vendor did a persistent > implementation and some did a volatile implementation. --=20 Hirochika Asai , The University of Tokyo From keiichi.shima.1016@gmail.com Thu Aug 29 03:27:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E8F21F9D2B for ; Thu, 29 Aug 2013 03:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGCXPlY8cCo for ; Thu, 29 Aug 2013 03:27:37 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 52F0721F9D2A for ; Thu, 29 Aug 2013 03:27:37 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so266067pbb.10 for ; Thu, 29 Aug 2013 03:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=riIL19MiF0v3srHSJMHbXjgibN7xW/B2NtXQHLogOrQ=; b=Al12SOtWVKgLLaVbyqJyd4v1/mrtBGwoH0c8fvQjWiOvByzF31SaKOKGVvX0C/fxaS 7aa6mp+qqHdI2+XTKYjhUUDljUozzl8HbCIjm2G4ZaF34D/xGDVRYjKaCc3mJ+r2m9Vv JFkAyw57guGhSTwmUc5+AQb2LFLDAEhI+dhDDEn6VTNaqUBybRvVwVPCBBJgqczBCXgw vVMt+Jt6Lto8mHxGoFSf37ksAb0KmuHhxxtOzu4ad75fhHq0Yvgbl7Hw8ANxe0NCoFEd rTEPpzJi9H7R1kdcPxM+CFwJw46o4AcA8HVVqARF3q4CaynQI3wSCdQDUMlv52yZt2th NDPA== X-Received: by 10.68.197.36 with SMTP id ir4mr2782405pbc.96.1377772057054; Thu, 29 Aug 2013 03:27:37 -0700 (PDT) Received: from [10.110.116.136] (122x216x29x254.ap122.ftth.ucom.ne.jp. [122.216.29.254]) by mx.google.com with ESMTPSA id zq10sm40034575pab.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 03:27:36 -0700 (PDT) Sender: Keiichi SHIMA Content-Type: multipart/signed; boundary="Apple-Mail=_DE57DCE8-08CB-4FFE-B701-4F60C4BA7540"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: SHIMA Keiichi In-Reply-To: <20130826105955.GA17723@elstar.local> Date: Thu, 29 Aug 2013 19:27:40 +0900 Message-Id: References: <20130826105955.GA17723@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:27:38 -0000 --Apple-Mail=_DE57DCE8-08CB-4FFE-B701-4F60C4BA7540 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, >> In the latest VMM-MIB draft = (http://www.ietf.org/id/draft-asai-vmm-mib-04.txt), the values for = vmAdminState are defined as below. >=20 > You are actually asking a question about VirtualMachineOperState=E2=80=A6= Ah, yes, you are right. My fault. >> What precisely does the 'blocked' state mean? When does a virtual >> machine transit to the 'blocked' state? I think we need more text >> about the state, if we want to keep the state. >=20 > The blocked state covers situations where a virtual machine is blocked > because it waits for certain service requests to complete. For > example, if you use Xen, then a DomU delegates most of the low-level > input/output to Dom0 and while waiting for Dom0 to finish processing a > request, the DomU issuing the request is 'blocked'. OK, thank you, now the meaning of the blocked state is much clearer to = me than before. Then, my following question is that, do we need the state? I wonder how = the state is used in a real operation. It seems that the blocked state is a kind of temporal/short-lived state = caused by the scheduling process of virtual machine entities running in = a hypervisor. It is sure that we will have a blocked state, but it = won't last long. Are we trying to catch that short-lived state using = this VMM-MIB? Do we have any usage scenario of the blocked state? Regards, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/08/26, at 19:59, Juergen Schoenwaelder = wrote: > On Sat, Aug 24, 2013 at 08:52:47PM +0900, Keiichi SHIMA wrote: >> Hi, >>=20 >> Let me ask one question about vmAdminState values. >>=20 >> In the latest VMM-MIB draft = (http://www.ietf.org/id/draft-asai-vmm-mib-04.txt), the values for = vmAdminState are defined as below. >=20 > You are actually asking a question about VirtualMachineOperState... >=20 >>=20 >> INTEGER { >> unknown(1), >> other(2), >> preparing(3), >> running(4), >> blocked(5), >> suspending(6), >> suspended(7), >> resuming(8), >> paused(9), >> migrating(10), >> shuttingdown(11), >> shutdown(12), >> crashed(13) >> } >>=20 >> Also, how the state transits is shown in Figure 2. >>=20 >> However, in the above description, the 'blocked' state is quite = unclear to me. >=20 > The current description is this: >=20 > blocked(5) The virtual machine is currently blocked. = =20 >=20 >> What precisely does the 'blocked' state mean? When does a virtual >> machine transit to the 'blocked' state? I think we need more text >> about the state, if we want to keep the state. >=20 > The blocked state covers situations where a virtual machine is blocked > because it waits for certain service requests to complete. For > example, if you use Xen, then a DomU delegates most of the low-level > input/output to Dom0 and while waiting for Dom0 to finish processing a > request, the DomU issuing the request is 'blocked'. >=20 > Would this clarification help: >=20 > blocked(5) The virtual machine is currently blocked > waiting for example for some action of=20 > the hypervisor to finish. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_DE57DCE8-08CB-4FFE-B701-4F60C4BA7540 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKRDCCBNcw ggK/oAMCAQICCwDVKQnjpxHSzZzEMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVBAYTAkpQMRUwEwYD VQQKDAxXSURFIFByb2plY3QxHzAdBgNVBAMMFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDMwHhcNMTMw NjI1MTQzNjM3WhcNMTUwNjMwMjM1OTU5WjBkMQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQ cm9qZWN0MR0wGwYDVQQDDBQwMzI4IEtlaWljaGkgU2hpbWEgNDEfMB0GCSqGSIb3DQEJARYQc2hp bWFAd2lkZS5hZC5qcDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM//e0ghqwWrhi0o dqz+plMayBUy8JK22Ov3qwKHJpti152W1ww6+US3TZqK0NMHQgsHnCyMZYbYdnunzWT2/TPfmKPx JX4WF/ZTP7RphWFaUfgmz9Iykoo+K93qVBngFda6j6fUP3Kk8jkU0vL5RH/EnBLZG8aKy0Orgcc0 1n8VdePqSpldueDw1F9A3aA/IdKY74jo+/aRnvCfEo5mxhZUV5ULgsWvsja9HhGXZdxotj5/2Da4 HB9Paj2skamGiA0KJKphE/VKCF8ksOPeYXxR5J7rr8Ti3azfEMR5EM2UAFO9VOXJqRoGYdaKIeo1 8e+2rRVkamPDWT7EhiO89u8CAwEAAaOBqDCBpTALBgNVHQ8EBAMCBLAwGwYDVR0RBBQwEoEQc2hp bWFAd2lkZS5hZC5qcDAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vbW9jYS53aWRlLmFkLmpwL2Ny bC5jcmwwHwYDVR0jBBgwFoAUlpT82BlfTL9FMdyssrhbVQdMiw8wJwYDVR0lBCAwHgYIKwYBBQUH AwQGCCsGAQUFBwMDBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAgEAKNpKYrelWSNM3Xg2n5mE kAqYptfQYVQYbWlHEndLnGjIP2FsXby4pKNVa11LczoW5y28HE5rQ8HUQGcgXDeOTTup27eq62UR IbywlGIWH+PjYly4Vivt74+ICjh8dXyZ55R2OvkrViSl6mSzP6j0SNr1e9Z/Y594isTl6UkfnD3m IDPvfCAheaNBUF2DPJ6dsABjaFfGA4FY3R4Aczrtvlh5IzpGvsDzj1RyL+VlUCSkPw2pB3aiR6Qu 072C482j0B3FvD4huoxnvaAV0Qh5qqRCosbe0dkLMLfs8G3LgaMADWzlvsgiHKHb2C0FMBWWVWvL i+y1acfqNSxcVQlgvIBlndPPa4eNrGIEeplw7MQ62YCQTtb+4dc6aE2uJf2rprE3gw+wduvURL0G E2p3bx9RA2Biq+Bq1c+kT2dsfGmFSAWMVPoUxm405QJMl++/PbW377CQKnkBe1gAhwyrC/dnwFEY g8tTf/xmtzbV637LcHD4f+B3TR+wcnbVoOOEXBOZVMdLk6/qxpX4TD/i+2v3qLEtVm3pD8Fwunuy KRRV3mM3iApBM2j1EhAUGjv7FHtreijbRUlHPE+5mjzDLaPHM5nvnR0TDmbly/RCkuU0j/UE3QeV RXeocpf8QfsfxJzi4zJwnLLu8vcB75plyj+a+KZYCKQPWzdyECDItBQwggVlMIIDTaADAgECAgsA 3pfLDt1eq5DA7TANBgkqhkiG9w0BAQsFADA+MQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQ cm9qZWN0MRgwFgYDVQQDDA9XSURFIFJPT1QgQ0EgMDMwHhcNMTMwNjAzMTIwMDI0WhcNMjMwNjMw MTQwNTEyWjBFMQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQcm9qZWN0MR8wHQYDVQQDDBZt ZW1iZXJzIG9yaWVudGVkIENBIDAzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnX+t N/1KWgtexAc658h4NY5IvJbShg3gIpoITVP8IAFhcFSed6t7RQaKomEFP0NZxL4+rntl6F80MB/2 freB2pGkCxA81tC1gRw8ZkgWMS9+qPZYOAW5hBOMjrykrSI7+NyGno7bL2Sso/b+FRmHASqWJ05L qOs64EX3g40sNjFNx2AHQXoas1HdWNvj8QpZipCPv1ZFdvUlu9eZ2CQj7rd9bvUBGrdCuV2rBb1v n5LbtjHgYsw/Ic5f8PLlJ0BOPdYYRjtgHW1UNzERxGnambcH+dRE4L0+ThCPNQiJu7nxBvkMG9t5 K+1b/rF8BuvYJrM3BpYtc50y3YmAFTrqlkE85iPsGe1BP8/s6EphkSBeKBq1aYSds4rhiM+tr5dS CKoowiNR41OWC7kEbew5bmiM0MDqqhJx4QKs0LsgngjwdwR1gyCWrR4DwaQn13H+fbEj9C4g3jy5 wIS6wI/pgjfBtYZNlR6LbRwqmq98e5TLmbeooDcTpBQVlfozDVGib0u2BT3toc1GZeXO1aL41xye CnMaKdlxWLcymp1Pue7FJEQwW5J5vKkD08m5DE0IX0i9R2aHgm5tN4AJBWSo2dc9w6HhD/PjugaM BhTIDdgkxibAjVxI8grPwDLdLWDwwhl7+ZPRTQ17Qe+nqjF/w3kOhiWYAKBTBMGcvt/ZpYECAwEA AaNdMFswHQYDVR0OBBYEFJaU/NgZX0y/RTHcrLK4W1UHTIsPMB8GA1UdIwQYMBaAFDhrU7/rSxuL APgA6CJlDQCm847qMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IC AQCDysFnIkZoio7HmwBZ0MaIv6REQtCweXy4P0LVka1HwqoqepCgOBZJY2MMXE6ZUxbuT+HEsskk iMjloh4xCRyL9ds3zZ6gMhDvx3pEgGhe7iusJI/bfCe10ZIGTcrWaZwohN9ubbHXyC47QqDTh6Oj EMosEjnWTUzm6H9NsoKQNYKQCCpP4bNJO1urUueHR74FuH5i6taI/RAm1qdoRoeH7qwL2Lvg/kPL yJE3hUiNpw3VQSC29Tx9KUgvltodiwX6tu5oroM+MgywMWwgNlmKEYmqa9DWeXIBzA47m3l9Bruo qXXdsUTzzF7K/bkflJWNIhCzaJfkFnJqGacuJiBFnjeqy0aOZ5gWvG3rBpJgGro8Pdgz/9NHTXe4 9zhFmR1eeDDNNmWL2U060NjwxCBZKe1UQs+7qiCKsybHwv7e43UB2LZodD356WLtAb3jwslVHah2 ZGzX2LihURz4s7UO8XiqFO0GAtcFbTj0if30ex7EHVe7Y+xg/MCmu2Dy1P071fNrkZhEaZcrU1PV ubfZQJG5mAEW3K4HDMwZl7SH624K/s8QpWZgBoz1FYvh3W0dj1y/i+dAi3hmwRlCx07+jUA4FhWH CI/8KxZLg/z4jj5F8BVI7FLOr1rgFOPdU2JjPDIaKIj0Ggrun7KtNRyEect37auh6rCZTfL3SAwv UDGCAqgwggKkAgEBMFQwRTELMAkGA1UEBhMCSlAxFTATBgNVBAoMDFdJREUgUHJvamVjdDEfMB0G A1UEAwwWbWVtYmVycyBvcmllbnRlZCBDQSAwMwILANUpCeOnEdLNnMQwCQYFKw4DAhoFAKCCASkw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODI5MTAyNzQxWjAj BgkqhkiG9w0BCQQxFgQUs7CjoT0ik/CJpkVy4cv+AXTtEzYwYwYJKwYBBAGCNxAEMVYwVDBFMQsw CQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQcm9qZWN0MR8wHQYDVQQDDBZtZW1iZXJzIG9yaWVu dGVkIENBIDAzAgsA1SkJ46cR0s2cxDBlBgsqhkiG9w0BCRACCzFWoFQwRTELMAkGA1UEBhMCSlAx FTATBgNVBAoMDFdJREUgUHJvamVjdDEfMB0GA1UEAwwWbWVtYmVycyBvcmllbnRlZCBDQSAwMwIL ANUpCeOnEdLNnMQwDQYJKoZIhvcNAQEBBQAEggEAdMfeUbIDvjtA6vw4kYRR9NEuDEB9oKEnJIGQ 8CYOPFkh5zn/efmxONc8c57Y7W3SfWU/QUxEGlpOAuUIzAebxz2bTKnEnEnpm/+Ub5CAzH1/95kq MuzTkwuLwA0soSc1eDaZmFlapZs6c/ctwCoeZ1k6VeKy4cOUY68UUBMiKg0JMO2j8hHNoWfxt67B sOdxPhpAXRZv4LShvXbt2yowwsGIilsP4mj0aIzlzBX18THB7EU1/i93bPkOd72AV/0x72NS7IUT FNAnh9ugoWTBPWcqXuepGyPGzizg7Q4VHDeDFvlVtu+I9Pq7S5hBdxFeSI/FedmlhPKVs3vSQK2s 0QAAAAAAAA== --Apple-Mail=_DE57DCE8-08CB-4FFE-B701-4F60C4BA7540-- From j.schoenwaelder@jacobs-university.de Thu Aug 29 04:00:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E5421F841A for ; Thu, 29 Aug 2013 04:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOVXr4QzPj2D for ; Thu, 29 Aug 2013 03:59:58 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F73A21F9967 for ; Thu, 29 Aug 2013 03:59:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 620A920C5F; Thu, 29 Aug 2013 12:59:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qaaXijdQCYpZ; Thu, 29 Aug 2013 12:59:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7154D20C56; Thu, 29 Aug 2013 12:59:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A152428143CE; Thu, 29 Aug 2013 12:59:50 +0200 (CEST) Date: Thu, 29 Aug 2013 12:59:50 +0200 From: Juergen Schoenwaelder To: SHIMA Keiichi Message-ID: <20130829105950.GB56383@elstar.local> Mail-Followup-To: SHIMA Keiichi , opsawg@ietf.org References: <20130826105955.GA17723@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 11:00:03 -0000 On Thu, Aug 29, 2013 at 07:27:40PM +0900, SHIMA Keiichi wrote: [...] > Do we have any usage scenario of the blocked state? I thing this is backwards. I like my SNMP agent to access the current state and report it. It does not matter whether I believe the state is short lived or not. I like to see the actual state - not a translation of it. The worst experience when I debug problems is when software tries to hide reality. And, btw, being blocked is really not uncommon in a Xen setup. $ sudo xm list Name ID Mem VCPUs State Time(s) Domain-0 0 4160 8 r----- 267537.1 foo 3 512 1 -b---- 39148.0 bar 17 2048 1 -b---- 71467.1 baz 20 2048 1 -b---- 80750.0 bing 6 1024 1 -b---- 66408.8 bong 8 256 1 -b---- 57365.8 bang 21 1024 1 -b---- 36534.1 yum 10 256 1 -b---- 41611.5 yam 15 1024 1 -b---- 49363.2 yim 16 2048 1 -b---- 44081.6 (Taken from a live machine with names obfuscated.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Thu Aug 29 07:03:04 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83D421E805A for ; Thu, 29 Aug 2013 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVSwQRhLUwTT for ; Thu, 29 Aug 2013 07:03:00 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0474211E80FA for ; Thu, 29 Aug 2013 07:02:59 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta08.westchester.pa.mail.comcast.net with comcast id Jcn11m0050EZKEL58e2zvW; Thu, 29 Aug 2013 14:02:59 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta01.westchester.pa.mail.comcast.net with comcast id Je2y1m01i2yZEBF3Me2zDK; Thu, 29 Aug 2013 14:02:59 +0000 From: "ietfdbh" To: "'Hirochika Asai'" , "'Joe Marcus Clarke'" References: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <5217BDBF.5000601@cisco.com> <753543F6-4804-4BBC-A3D2-456EF9DF8DC9@hongo.wide.ad.jp> In-Reply-To: <753543F6-4804-4BBC-A3D2-456EF9DF8DC9@hongo.wide.ad.jp> Date: Thu, 29 Aug 2013 10:02:57 -0400 Message-ID: <00c701cea4c0$773fd070$65bf7150$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEvnxkvGHF8wN8u8xsY/lUUKb+7DwFJ1MnPAfIOWZ+a0GFLkA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377784979; bh=Ip01/y2ssIYcTy6RC4AkZT119YbiAohOmUlQ8grpu/w=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=BAIhVCfxh5qJqFQkWEK+RZYbaEza/8w7yvoOV09h5diekw9g9eleKfwZhxeo3/hOu n+fmN91ObRTPHJcmp8KvAtRJBd71wp009BwAzQeg28siqtizFoFmy/CzmNP57fOmp2 9H+NIxc7x2ODMp15iJIkQlB3e0PxJjAdAYdU36S8rPO/LRo2bo6U0HUXC8kx86TxhP vRUKlAHU/Ik/594cjyLRVVT5dZJNLjgfpEhDVPTv0PJg5lXxARFP3DVDBmwzB5DMmP meHI8SL4rVCAHYHIugm2rKYYMctlg23mgkZ53Bvaj+T9dUeBfbMrge957P4gY8PHbT UQRjo0kFs6LJQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 14:03:05 -0000 > >> I really don't like the idea of standards prohibiting potentially > >> useful functionality. I would like a better understanding/description of the problems that would be caused by having persistent values for these objects in some implementations and volatile values in other implementations, to justify the MUST NOT usage. I would like a better understanding of the benefits that might lead some implementers to have persistent values in their implementations; what possible useful functionality could we be prohibiting by making this a MUST NOT? David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Hirochika Asai > Sent: Thursday, August 29, 2013 4:28 AM > To: Joe Marcus Clarke > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on > draft-asai-vmm-mib-04) > > > As for the read-write objects, i.e., vmMinCpuNumber, vmMaxCpuNumber, > vmMinMem, and vmMaxMem, I changed the following phrase for the next > version of the draft. > > (deleted) Changes to this object may not persist across restarts of the > hypervisor > (added) Changes to this object must not persist across restarts of the > hypervisor > > Thank you. > Hirochika > > > On Aug 24, 2013, at 4:53 AM, Joe Marcus Clarke wrote: > > >> Just to be absolutely clear... > >> Are you requesting that the normative text state that the values > >> assigned to these object-types SHOULD NOT or MUST NOT persist across > >> reboots? > >> > >> I really don't like the idea of standards prohibiting potentially > >> useful functionality. > > > > I was asking for the latter since this MIB is not about configuration. > > I think it would be a POLA violation if one vendor did a persistent > > implementation and some did a volatile implementation. > > -- > Hirochika Asai , The University of Tokyo > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From jclarke@cisco.com Thu Aug 29 08:07:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7652811E8121 for ; Thu, 29 Aug 2013 08:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4eU1v0Gh2d6 for ; Thu, 29 Aug 2013 08:06:59 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 81B9621F9C76 for ; Thu, 29 Aug 2013 08:06:11 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TF65Gj000618; Thu, 29 Aug 2013 17:06:05 +0200 (CEST) Received: from dhcp-10-150-54-22.cisco.com (dhcp-10-150-54-22.cisco.com [10.150.54.22]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TF64N9003966; Thu, 29 Aug 2013 11:06:04 -0400 (EDT) Message-ID: <521F635C.8080502@cisco.com> Date: Thu, 29 Aug 2013 11:06:04 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Keiichi SHIMA , "opsawg@ietf.org" References: <20130826105955.GA17723@elstar.local> In-Reply-To: <20130826105955.GA17723@elstar.local> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:07:15 -0000 On 8/26/13 6:59 AM, Juergen Schoenwaelder wrote: > Would this clarification help: > > blocked(5) The virtual machine is currently blocked > waiting for example for some action of > the hypervisor to finish. This reminds me of another problem I had initially noticed, but forgot to raise. That is, the use of the state name to define the state. I think what you have written here is good, but is there another way to say "blocked" that would define it more clearly? I have the same comment for just about all states. Their definition contains the state name. If those descriptions were more descriptive, it might short-circuit emails like this 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: jclarke@cisco.com ---------------------------------------------------------------------------- From jclarke@cisco.com Thu Aug 29 08:12:43 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C196221E8082 for ; Thu, 29 Aug 2013 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPZIeK2rJztc for ; Thu, 29 Aug 2013 08:11:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84C11E8123 for ; Thu, 29 Aug 2013 08:09:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TF9Djv000982; Thu, 29 Aug 2013 17:09:13 +0200 (CEST) Received: from dhcp-10-150-54-22.cisco.com (dhcp-10-150-54-22.cisco.com [10.150.54.22]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TF9CxK006500; Thu, 29 Aug 2013 11:09:12 -0400 (EDT) Message-ID: <521F6418.3030904@cisco.com> Date: Thu, 29 Aug 2013 11:09:12 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: ietfdbh References: <19163971.1377286860237.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> <5217BDBF.5000601@cisco.com> <753543F6-4804-4BBC-A3D2-456EF9DF8DC9@hongo.wide.ad.jp> <00c701cea4c0$773fd070$65bf7150$@comcast.net> In-Reply-To: <00c701cea4c0$773fd070$65bf7150$@comcast.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 15:12:44 -0000 On 8/29/13 10:02 AM, ietfdbh wrote: >>>> I really don't like the idea of standards prohibiting potentially >>>> useful functionality. > > I would like a better understanding/description of the problems that would > be caused by having persistent values for these objects in some > implementations and volatile values in other implementations, to justify the > MUST NOT usage. > > I would like a better understanding of the benefits that might lead some > implementers to have persistent values in their implementations; what > possible useful functionality could we be prohibiting by making this a MUST > NOT? To me, the intent of this MIB is to not be a way of setting persistent configuration. This is to prevent POLA violations where I may be used to VMware's implementation (for example), and then get astonished when I find that Xen persists the state of the same object that VMware held volatile. If the MIB language was more definitive, then an operator would know that if one of these objects was implemented read-write the setting would only apply to the current running state, and there would be no room for ambiguity. Joe > > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >> Behalf Of Hirochika Asai >> Sent: Thursday, August 29, 2013 4:28 AM >> To: Joe Marcus Clarke >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on >> draft-asai-vmm-mib-04) >> >> >> As for the read-write objects, i.e., vmMinCpuNumber, vmMaxCpuNumber, >> vmMinMem, and vmMaxMem, I changed the following phrase for the next >> version of the draft. >> >> (deleted) Changes to this object may not persist across restarts of the >> hypervisor >> (added) Changes to this object must not persist across restarts of the >> hypervisor >> >> Thank you. >> Hirochika >> >> >> On Aug 24, 2013, at 4:53 AM, Joe Marcus Clarke wrote: >> >>>> Just to be absolutely clear... >>>> Are you requesting that the normative text state that the values >>>> assigned to these object-types SHOULD NOT or MUST NOT persist across >>>> reboots? >>>> >>>> I really don't like the idea of standards prohibiting potentially >>>> useful functionality. >>> >>> I was asking for the latter since this MIB is not about configuration. >>> I think it would be a POLA violation if one vendor did a persistent >>> implementation and some did a volatile implementation. >> >> -- >> Hirochika Asai , The University of Tokyo >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > -- 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: jclarke@cisco.com ---------------------------------------------------------------------------- From randy_presuhn@mindspring.com Thu Aug 29 10:53:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1621E80C4 for ; Thu, 29 Aug 2013 10:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.297 X-Spam-Level: X-Spam-Status: No, score=-101.297 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj9exCLBL-B4 for ; Thu, 29 Aug 2013 10:53:15 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 33BED21E80B7 for ; Thu, 29 Aug 2013 10:53:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iJU3LHG9Yj6SMAdymZy/pj11TpRr37n1GDCHp1kmmCnbWoKTuWx2qFBsGum/ojAO; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VF6PA-00086n-LQ for opsawg@ietf.org; Thu, 29 Aug 2013 13:53:12 -0400 Received: from 99.23.161.81 by webmail.earthlink.net with HTTP; Thu, 29 Aug 2013 13:53:12 -0400 Message-ID: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Thu, 29 Aug 2013 10:53:12 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08331dbe65217df77c8cc0441273b2c3e3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.27 Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 17:53:21 -0000 Hi - >From: ietfdbh >Sent: Aug 29, 2013 7:02 AM ... >Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) > >> >> I really don't like the idea of standards prohibiting potentially >> >> useful functionality. ... >I would like a better understanding of the benefits that might lead some >implementers to have persistent values in their implementations; what >possible useful functionality could we be prohibiting by making this a MUST >NOT? As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber, vmMinMem, and vmMaxMem, have a potentially significant impact on the capability of both the VM and the performance of the hosting system, something that might well be of interest in, for example, an SLA. As such, it would seem useful to not be required to "forget" the settings. I think accepting the line of reasoning that "since this MIB is not about configuration" that configuration should therefor be *prohibited* would set a very bad precedent. If folks are truly concerned about violating the principle of least astonishment, then the correct answer, in my opinion, would be to add a StorageType. Indeed, if these objects end up being required to *not* persist, then I could well imagine a vendor creating another MIB module to model the data that *can* persist. The semantic relationship between those objects and these would almost certainly end up being "astonishing" to operators. Randy From ietfdbh@comcast.net Thu Aug 29 11:24:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2AB11E814B for ; Thu, 29 Aug 2013 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2aWGz0FlbfA for ; Thu, 29 Aug 2013 11:24:19 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 9C38311E8138 for ; Thu, 29 Aug 2013 11:24:15 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id JbjW1m0050cZkys5BiQDpJ; Thu, 29 Aug 2013 18:24:13 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta10.westchester.pa.mail.comcast.net with comcast id JiQC1m01h2yZEBF3WiQDlT; Thu, 29 Aug 2013 18:24:13 +0000 From: "ietfdbh" To: "'Randy Presuhn'" , References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> In-Reply-To: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> Date: Thu, 29 Aug 2013 14:24:11 -0400 Message-ID: <00e801cea4e4$f59c6810$e0d53830$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMvz9ud6pEH62tTtwru1lf9cZHckJbqKdew Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1377800653; bh=kdsX1qhl0r2G+26KHNYx4HehVgBbvolWgDdVxZa2jG0=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=hoNOUUMewCC+n1thgrIXjlcDgMamFvnP1NOE21PL6WcFJ3CMVGoVwOoXKZyw9tgNc mLCHMeiUHkUoH1T3di6/VIaiDbGJlHMR2elabhs5CjTPwjRZuxRv7vWsZbi2TtXA3q 2m5GGnX3ehae+pygooMMrtj3p4uiwJh7W7p3l1oB9xpMEAVyOAecx9IVyLs20InlnD Sjv1/FJwo02b82Qb5Agy5uYaIvwiI0Uci/4RkJPA15ED+gsELvCLEiBJomrylgTWqW cuUR7ylXpUaycP7MKoBL1DHeHI/6gDr6QS+BEougazB+MKQw1UHXtk0gIanaSA6CfJ gAHcwp65mEFcw== Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 18:24:24 -0000 > I think accepting the line of reasoning that "since this MIB is not about > configuration" that configuration should therefore be *prohibited* would set > a very bad precedent. +1 David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Randy Presuhn > Sent: Thursday, August 29, 2013 1:53 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on > draft-asai-vmm-mib-04) > > Hi - > > >From: ietfdbh > >Sent: Aug 29, 2013 7:02 AM > ... > >Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments > on draft-asai-vmm-mib-04) > > > >> >> I really don't like the idea of standards prohibiting potentially > >> >> useful functionality. > ... > >I would like a better understanding of the benefits that might lead > >some implementers to have persistent values in their implementations; > >what possible useful functionality could we be prohibiting by making > >this a MUST NOT? > > As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber, > vmMinMem, and vmMaxMem, have a potentially significant impact on the > capability of both the VM and the performance of the hosting system, > something that might well be of interest in, for example, an SLA. As such, it > would seem useful to not be required to "forget" the settings. > > I think accepting the line of reasoning that "since this MIB is not about > configuration" that configuration should therefor be *prohibited* would set > a very bad precedent. > If folks are truly concerned about violating the principle of least > astonishment, then the correct answer, in my opinion, would be to add a > StorageType. > > Indeed, if these objects end up being required to *not* persist, then I could > well imagine a vendor creating another MIB module to model the data that > *can* persist. The semantic relationship between those objects and these > would almost certainly end up being "astonishing" to operators. > > Randy > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From linda.dunbar@huawei.com Thu Aug 29 11:52:05 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D0A11E815E for ; Thu, 29 Aug 2013 11:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1+gtdUFtWuQ for ; Thu, 29 Aug 2013 11:52:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B811E8139 for ; Thu, 29 Aug 2013 11:51:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUW32700; Thu, 29 Aug 2013 18:51:54 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 29 Aug 2013 19:51:38 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 29 Aug 2013 19:51:53 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.52]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 29 Aug 2013 11:51:46 -0700 From: Linda Dunbar To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" Thread-Index: AQHOoQWLetMrHBBFKEmWF4sEWV8kNZmsjfXQgAABWBA= Date: Thu, 29 Aug 2013 18:51:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645B86608@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.146.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "opsawg-chairs@tools.ietf.org" Subject: Re: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 18:52:05 -0000 Support! Linda Dunbar -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Melinda Shore Sent: Saturday, August 24, 2013 3:07 PM To: opsawg@ietf.org Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] WG last call for "Mechanisms for Optimal LAG/ECMP Compone= nt Link Utilization in Networks" This is to announce the start of working group last call on: Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks http://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing= / It is intended for publication as an informational RFC. Please give it a careful read and provide any feedback to this mailing list= by September 9, 2013 Thanks, opsawg chairs _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From jclarke@cisco.com Thu Aug 29 12:29:44 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB811E816E for ; Thu, 29 Aug 2013 12:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLK+ZkbWf79A for ; Thu, 29 Aug 2013 12:29:39 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F365A11E8167 for ; Thu, 29 Aug 2013 12:29:38 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TJTav7029066; Thu, 29 Aug 2013 21:29:37 +0200 (CEST) Received: from dhcp-10-150-54-22.cisco.com (dhcp-10-150-54-22.cisco.com [10.150.54.22]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TJTa7Z016046; Thu, 29 Aug 2013 15:29:36 -0400 (EDT) Message-ID: <521FA120.7090401@cisco.com> Date: Thu, 29 Aug 2013 15:29:36 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Presuhn References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> In-Reply-To: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 19:29:44 -0000 On 8/29/13 1:53 PM, Randy Presuhn wrote: > Hi - > >> From: ietfdbh >> Sent: Aug 29, 2013 7:02 AM > ... >> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) >> >>>>> I really don't like the idea of standards prohibiting potentially >>>>> useful functionality. > ... >> I would like a better understanding of the benefits that might lead some >> implementers to have persistent values in their implementations; what >> possible useful functionality could we be prohibiting by making this a MUST >> NOT? > > As I understand it, the objects vmMinCpuNumber, vmMaxCpuNumber, > vmMinMem, and vmMaxMem, have a potentially significant impact > on the capability of both the VM and the performance of the > hosting system, something that might well be of interest in, > for example, an SLA. As such, it would seem useful to not > be required to "forget" the settings. > > I think accepting the line of reasoning that "since this > MIB is not about configuration" that configuration should > therefor be *prohibited* would set a very bad precedent. > If folks are truly concerned about violating the principle of > least astonishment, then the correct answer, in my opinion, > would be to add a StorageType. > > Indeed, if these objects end up being required to *not* > persist, then I could well imagine a vendor creating another > MIB module to model the data that *can* persist. The semantic > relationship between those objects and these would almost > certainly end up being "astonishing" to operators. My comments stem from what the draft says in that this MIB is not trying to address config management or persistence to what a vendor may implement. I'm also seeing more users shy away from SNMP for configuration management due to lack of change management hooks (I realize there is an RFC for SNMP and AAA, but I haven't seen wide adoption). Would it not be better to implement something like NETCONF for the configuration side of things if I really wanted to offer configuration? then this MIB could really be left for monitoring. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From randy_presuhn@mindspring.com Thu Aug 29 12:45:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51D111E817A for ; Thu, 29 Aug 2013 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIoXUzc7dgTO for ; Thu, 29 Aug 2013 12:44:56 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id A761C11E8173 for ; Thu, 29 Aug 2013 12:44:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RKMU1wvc9fB1+CpH4tk/D0DEatZ4h+0m3aXzgn9bRBoQIcTBOyOBkR5sCAw4CKtA; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.161.81] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VF89F-0000Lu-JD for opsawg@ietf.org; Thu, 29 Aug 2013 15:44:53 -0400 Message-ID: <001201cea4f0$56576f00$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <521FA120.7090401@cisco.com> Date: Thu, 29 Aug 2013 12:45:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08dadfc806099c43041ec4865b74b680e3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.161.81 Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 19:45:04 -0000 Hi - > From: "Joe Marcus Clarke" > To: "Randy Presuhn" > Cc: > Sent: Thursday, August 29, 2013 12:29 PM > Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... > Would it not be better to implement something like NETCONF for the > configuration side of things if I really wanted to offer configuration? > then this MIB could really be left for monitoring. Punting the configuration problem to Netconf doesn't reduce the modeling (or operational) complexity presented by read-write objects like these. If you argue instead that they should be read-only, that's another matter (though still fraught with complexity, given the ways Netconf can work) but doing so also, for me at least, raises the "why bother" question regarding this MIB module. If these objects would merely reflect the current configuration data, then they'd add no value, and there'd be no point in having them at all. Randy From mrm@vmware.com Thu Aug 29 14:16:07 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6B021E804C for ; Thu, 29 Aug 2013 14:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjvWpb4CCVg0 for ; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA1911E8134 for ; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 7658128344; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 73707402FF; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 62DD7E0105; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Thu, 29 Aug 2013 14:16:02 -0700 (PDT) Date: Thu, 29 Aug 2013 14:16:01 -0700 (PDT) From: Michael MacFaden To: Randy Presuhn Message-ID: <1415848601.3532946.1377810961981.JavaMail.root@vmware.com> In-Reply-To: <001201cea4f0$56576f00$6b01a8c0@oemcomputer> References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <521FA120.7090401@cisco.com> <001201cea4f0$56576f00$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) Thread-Index: KPZHrI9BEU8A2Fnk0+uRFSVB+lj1tQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 21:16:07 -0000 > Punting the configuration problem to Netconf doesn't reduce the > modeling (or operational) complexity presented by read-write objects > like these. If you argue instead that they should be read-only, that's > another matter (though still fraught with complexity, given the ways > Netconf can work) but doing so also, for me at least, raises the "why > bother" question regarding this MIB module. If these objects would > merely reflect the current configuration data, then they'd add no value, > and there'd be no point in having them at all. For any given managed object in this mib module it should be shown how this is useful for monitoring purposes otherwise should not be added. If it duplicates configuration data so be it -- so long as its value has been shown. Regards, Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA From jclarke@cisco.com Thu Aug 29 16:11:32 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9DB21E805D for ; Thu, 29 Aug 2013 16:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWfPdxo9DIse for ; Thu, 29 Aug 2013 16:11:27 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9FD21E8055 for ; Thu, 29 Aug 2013 16:11:27 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TNBO3O021917; Fri, 30 Aug 2013 01:11:25 +0200 (CEST) Received: from dhcp-10-150-54-22.cisco.com (dhcp-10-150-54-22.cisco.com [10.150.54.22]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7TNBMOo026473; Thu, 29 Aug 2013 19:11:22 -0400 (EDT) Message-ID: <521FD51A.9050500@cisco.com> Date: Thu, 29 Aug 2013 19:11:22 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Presuhn References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <521FA120.7090401@cisco.com> <001201cea4f0$56576f00$6b01a8c0@oemcomputer> In-Reply-To: <001201cea4f0$56576f00$6b01a8c0@oemcomputer> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 23:11:33 -0000 On 8/29/13 3:45 PM, Randy Presuhn wrote: > Hi - > >> From: "Joe Marcus Clarke" >> To: "Randy Presuhn" >> Cc: >> Sent: Thursday, August 29, 2013 12:29 PM >> Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) > ... >> Would it not be better to implement something like NETCONF for the >> configuration side of things if I really wanted to offer configuration? >> then this MIB could really be left for monitoring. > > Punting the configuration problem to Netconf doesn't reduce the > modeling (or operational) complexity presented by read-write objects > like these. If you argue instead that they should be read-only, that's > another matter (though still fraught with complexity, given the ways > Netconf can work) but doing so also, for me at least, raises the "why > bother" question regarding this MIB module. If these objects would > merely reflect the current configuration data, then they'd add no value, > and there'd be no point in having them at all. I would be happy with read-only objects that showed the operational values. But there was a use case for changing the operational parameters via SNMP SET. In either case, I think the values and operations should reflect the operational state. 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: jclarke@cisco.com ---------------------------------------------------------------------------- From randy_presuhn@mindspring.com Thu Aug 29 16:59:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A038311E8110 for ; Thu, 29 Aug 2013 16:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzwaPnCnbgHu for ; Thu, 29 Aug 2013 16:59:21 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id A8B7511E80D2 for ; Thu, 29 Aug 2013 16:59:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e83Rnwj119o6B8oKPdIJ3uquz2VaY+EmjLrg+pCShdhYATyXvFshJZ4g2iapWuER; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.161.81] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VFC7S-0006ds-IB for opsawg@ietf.org; Thu, 29 Aug 2013 19:59:18 -0400 Message-ID: <001b01cea513$e15181e0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <26070259.1377798792684.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <521FA120.7090401@cisco.com> <001201cea4f0$56576f00$6b01a8c0@oemcomputer> <521FD51A.9050500@cisco.com> Date: Thu, 29 Aug 2013 17:00:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ba196d48fc2e3f08ea1d675a706d19a9fde4c063deff0504350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.161.81 Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 23:59:27 -0000 Hi - > From: "Joe Marcus Clarke" > To: "Randy Presuhn" > Cc: > Sent: Thursday, August 29, 2013 4:11 PM > Subject: Re: [OPSAWG] VMM-MIB: Proposal: Joe -3 (Was Re: Comments on draft-asai-vmm-mib-04) ... > I would be happy with read-only objects that showed the operational > values. But there was a use case for changing the operational > parameters via SNMP SET. In my book, that's a configuration change. It might be made with the intention of reverting to some previous configuration at some time in the future, but a configuration change nonetheless. It sounds like the claim here is that there are knobs whose initial settings are presumed to persist as part of system configuration, but for which any "tweaks" are forgotten. Those are two different knobs, should be clearly identified as such, and their relationship formally spelled out. Depending on the complexity of their relationship, it sounds like you may be asking for THREE objects (not all in MIB modules, of course): - the persistent configuration parameter, Netconf or whatever - the writable "tweak" knob, whose values might potentially be constrained by persistent configuration - the read-only operational value, which would be some function of the configuration, the tweak knob, and heaven-knows-what else. Randy From panda@hongo.wide.ad.jp Thu Aug 29 18:17:32 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A12311E8129 for ; Thu, 29 Aug 2013 18:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iametkmiJGQD for ; Thu, 29 Aug 2013 18:17:28 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5051311E8140 for ; Thu, 29 Aug 2013 18:17:28 -0700 (PDT) Received: from [IPv6:2001:200:180:8001:2d89:d0e8:a170:d0f1] (unknown [IPv6:2001:200:180:8001:2d89:d0e8:a170:d0f1]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 8F316108DE5F; Fri, 30 Aug 2013 10:08:10 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <521285FE.2020507@cisco.com> Date: Fri, 30 Aug 2013 10:17:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> <521285FE.2020507@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 01:17:32 -0000 Hi Joe, Thank you for your comments. I have a question on the management address. Do you mean a management interface that is attached to virtual machine as a network interface and that cannot be distinguished as a management interface from the hypervisor w/o VMware tools etc? Or, do you mean a management interface provided by the hypervisor for a virtual machine (let's call it a virtual IPMI here)? If you mean the former, I think it is reasonable to include it in entLogicalTable of ENTITY-MIB but not in the VMM-MIB . However, if you mean the latter, I think it should be included in the VMM-MIB. There is a patch of the virtual IPMI for qemu though it haven't been merged the trunk as follows: https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02516.html https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02525.html Does anybody know such other implementations of the virtual IPMI? If there are, we may need to take into account them. Thank you, Hirochika On Aug 20, 2013, at 5:54 AM, Joe Marcus Clarke = wrote: > On 8/19/13 4:52 PM, Michael MacFaden wrote: >>> If I understand you right this time, and the VM >>> inserts entLogicalTable entries in the HV ENTITY-MIB, would it not = make >>> sense to add a pointer in the VMM-MIB to indicate their index in the >>> entLogicalTable? >>=20 >> Yes, exactly. Create a row in entLogicalTable if there is data to = provide >> regarding pointers to agents in GOS and have a way to get at it = to/from=20 >> the VMM-MIB. >=20 > Okay, so in that case I would change Joe-2 to ask for an object in = this > table to point to such a conceptual row (or 0). >=20 > Joe >=20 >=20 > --=20 > 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: jclarke@cisco.com >=20 > = --------------------------------------------------------------------------= -- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Hirochika Asai , The University of Tokyo From panda@hongo.wide.ad.jp Thu Aug 29 18:35:03 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39A811E8192 for ; Thu, 29 Aug 2013 18:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7CSMEyty0Q1 for ; Thu, 29 Aug 2013 18:35:00 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id C3CEF11E815B for ; Thu, 29 Aug 2013 18:34:59 -0700 (PDT) Received: from [IPv6:2001:200:180:8001:2d89:d0e8:a170:d0f1] (unknown [IPv6:2001:200:180:8001:2d89:d0e8:a170:d0f1]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 5E1EA108DE5F; Fri, 30 Aug 2013 10:25:42 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: Date: Fri, 30 Aug 2013 10:35:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3C80E218-DCAD-4FAA-9F4C-BC8A3BED67D4@hongo.wide.ad.jp> References: <521158A7.2090407@cisco.com> <742382451.32805118.1376935335411.JavaMail.root@vmware.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> <521285FE.2020507@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 01:35:03 -0000 Oops, I'm sorry that there was the answer earier in this thread. Joe mentioned the former, i.e., management IP addr of a VM. So please ignore my question to Joe. But let me ask to the list about the virtual IPMI implementation. > Does anybody know such other implementations of the virtual IPMI? > If there are, we may need to take into account them. I couldn't find any other implementations of the virtual IPMI, so my opinion is that we do not need an object related to the virtual IPMI or something like it. If you find any, I'd like you to let me know. Thank you, Hirochika On Aug 30, 2013, at 10:17 AM, Hirochika Asai = wrote: > Hi Joe, >=20 > Thank you for your comments. >=20 > I have a question on the management address. Do you mean a > management interface that is attached to virtual machine as a > network interface and that cannot be distinguished as a > management interface from the hypervisor w/o VMware tools etc? > Or, do you mean a management interface provided by the hypervisor > for a virtual machine (let's call it a virtual IPMI here)? >=20 > If you mean the former, I think it is reasonable to include it in > entLogicalTable of ENTITY-MIB but not in the VMM-MIB . However, > if you mean the latter, I think it should be included in the VMM-MIB. >=20 > There is a patch of the virtual IPMI for qemu though it haven't been > merged the trunk as follows: > https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02516.html > https://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02525.html >=20 > Does anybody know such other implementations of the virtual IPMI? > If there are, we may need to take into account them. >=20 > Thank you, > Hirochika >=20 >=20 > On Aug 20, 2013, at 5:54 AM, Joe Marcus Clarke = wrote: >=20 >> On 8/19/13 4:52 PM, Michael MacFaden wrote: >>>> If I understand you right this time, and the VM >>>> inserts entLogicalTable entries in the HV ENTITY-MIB, would it not = make >>>> sense to add a pointer in the VMM-MIB to indicate their index in = the >>>> entLogicalTable? >>>=20 >>> Yes, exactly. Create a row in entLogicalTable if there is data to = provide >>> regarding pointers to agents in GOS and have a way to get at it = to/from=20 >>> the VMM-MIB. >>=20 >> Okay, so in that case I would change Joe-2 to ask for an object in = this >> table to point to such a conceptual row (or 0). >>=20 >> Joe >>=20 >>=20 >> --=20 >> 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: jclarke@cisco.com >>=20 >> = --------------------------------------------------------------------------= -- >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 > --=20 > Hirochika Asai , The University of Tokyo >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Hirochika Asai , The University of Tokyo From mrm@vmware.com Thu Aug 29 18:44:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E72411E8191 for ; Thu, 29 Aug 2013 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SflcX5Pbbxla for ; Thu, 29 Aug 2013 18:44:08 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3858211E815B for ; Thu, 29 Aug 2013 18:44:08 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2A93528AD9; Thu, 29 Aug 2013 18:44:08 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 1E133B040E; Thu, 29 Aug 2013 18:44:08 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 0A876E004E; Thu, 29 Aug 2013 18:44:08 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Thu, 29 Aug 2013 18:44:07 -0700 (PDT) Date: Thu, 29 Aug 2013 18:44:07 -0700 (PDT) From: Michael MacFaden To: Hirochika Asai Message-ID: <359743075.3699910.1377827047802.JavaMail.root@vmware.com> In-Reply-To: <3C80E218-DCAD-4FAA-9F4C-BC8A3BED67D4@hongo.wide.ad.jp> References: <521158A7.2090407@cisco.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> <521285FE.2020507@cisco.com> <3C80E218-DCAD-4FAA-9F4C-BC8A3BED67D4@hongo.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) Thread-Index: n+cA8gdK3Fep2irw4Jj9fogQz7VrTA== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 01:44:13 -0000 Asai-san writes: > But let me ask to the list about the virtual IPMI implementation. > > Does anybody know such other implementations of the virtual IPMI? > > If there are, we may need to take into account them. > I couldn't find any other implementations of the virtual IPMI, so my > opinion is that we do not need an object related to the virtual IPMI > or something like it. If you find any, I'd like you to let me know. I'm not aware of either a virtualized or just pass-through access to IPMI hardware in VMware products or I'd have been happily usig it many times over to allow me to test ESXi SNMP agent RFC 2790 implementation in a VM[1] If there are none, lets just make sure the MIB module doesn't preclude adding that... Regards, Mike [1] $ esxcfg-info | grep Product Name |----Product Name.............................................IBM System x3200 M2 -[4368AC1]- # diagnostics report $/bin/snmpd -S INFO: fetching sensors... record id: 8, length: 42, type: 2 entity: 7 instance: 1 record id: 9, length: 35, type: 2 entity: 7 instance: 1 record id: 14, length: 37, type: 2 entity: 3 instance: 1 record id: 15, length: 37, type: 2 entity: 20 instance: 1 record id: 17, length: 36, type: 2 entity: 23 instance: 1 record id: 18, length: 37, type: 2 entity: 7 instance: 1 record id: 20, length: 42, type: 2 entity: 7 instance: 1 record id: 21, length: 40, type: 2 entity: 7 instance: 1 record id: 22, length: 40, type: 2 entity: 7 instance: 1 record id: 29, length: 40, type: 2 entity: 23 instance: 1 record id: 34, length: 39, type: 2 entity: 3 instance: 1 record id: 36, length: 34, type: 2 entity: 7 instance: 1 record id: 60, length: 41, type: 2 entity: 4 instance: 2 record id: 61, length: 41, type: 2 entity: 4 instance: 1 record id: 62, length: 41, type: 2 entity: 4 instance: 4 record id: 63, length: 41, type: 2 entity: 4 instance: 5 record id: 64, length: 41, type: 2 entity: 4 instance: 6 record id: 65, length: 41, type: 2 entity: 4 instance: 7 record id: 66, length: 41, type: 2 entity: 4 instance: 8 record id: 74, length: 41, type: 2 entity: 4 instance: 3 record id: 75, length: 38, type: 2 entity: 21 instance: 1 record id: 76, length: 38, type: 2 entity: 21 instance: 2 record id: 77, length: 41, type: 2 entity: 21 instance: 3 record id: 78, length: 41, type: 2 entity: 21 instance: 4 record id: 79, length: 38, type: 2 entity: 21 instance: 5 record id: 80, length: 37, type: 2 entity: 0 instance: 1 INFO: sensor sweep completed, using total of 11 sensor entries in sdr [0] name: VRD Status, inst: 1, type: POWER, status: D_Normal, errors: 0 [1] name: PS 1 Status, inst: 1, type: POWER, status: D_Normal, errors: 0 [2] name: PS 2 Status, inst: 2, type: POWER, status: D_Normal, errors: 0 [3] name: PS Overspec, inst: 5, type: POWER, status: D_Normal, errors: 0 [4] name: Fan 1 Tach, inst: 1, type: FAN, status: D_Normal, errors: 0 [5] name: Fan 2 Tach, inst: 2, type: FAN, status: D_Normal, errors: 0 [6] name: Fan 3 Tach, inst: 3, type: FAN, status: D_Normal, errors: 0 [7] name: PS 1 Fan Fault, inst: 3, type: FAN, status: D_Normal, errors: 0 [8] name: PS 2 Fan Fault, inst: 4, type: FAN, status: D_Normal, errors: 0 [9] name: CPU Status, inst: 1, type: CPU, status: D_Normal, errors: 0 [10] name: CPU OverTemp, inst: 1, type: CPU, status: D_Normal, errors: 0 INFO: report complete From keiichi.shima.1016@gmail.com Thu Aug 29 21:00:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9215811E8166 for ; Thu, 29 Aug 2013 21:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoRcTFig1KMI for ; Thu, 29 Aug 2013 21:00:34 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E8D2221F9FD5 for ; Thu, 29 Aug 2013 21:00:33 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so1320126pdj.17 for ; Thu, 29 Aug 2013 21:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bK3C12pbfoCozdrH0wAG/nrUxZAK/GS+KOEy4FOlnVg=; b=bYPx1ll/s6sPjjK8mh2LJSoWedPs0jeLZrrZk2YO3f3DrJlCY263Q6hB5zzVmtwbyI unXfy4GvxE3Ma0Ius0dRsTAKcfu71etxvqlbZZiyhEsuRva2cgfIZj5d+skf1uaXcKhx OiZ7Tld6I0YVRq3BmedAFATxmz7eUEoGQ93S3btRsVXBWSV7ct8kODkmmHCRUIL807sd WHOSsRJsg7jIB2jQuxPETeotPWVMHBAumOm6YLHIV0IN/nCHkJ/b+994UK9chQx/ASj8 89CuJoDRfl3diXrsfAaQHFzCfmpDeBEVFhhve0wTrPXVxWNWdbvzv5dbJbLcdddJkN0N W2EA== X-Received: by 10.68.238.34 with SMTP id vh2mr7428115pbc.101.1377835233612; Thu, 29 Aug 2013 21:00:33 -0700 (PDT) Received: from [10.110.116.136] (122x216x29x254.ap122.ftth.ucom.ne.jp. [122.216.29.254]) by mx.google.com with ESMTPSA id ht5sm41479500pbb.29.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 Aug 2013 21:00:32 -0700 (PDT) Sender: Keiichi SHIMA Content-Type: multipart/signed; boundary="Apple-Mail=_D871355B-4F3A-4EA2-8C59-05D87CCE1B26"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: SHIMA Keiichi In-Reply-To: <20130829105950.GB56383@elstar.local> Date: Fri, 30 Aug 2013 13:00:28 +0900 Message-Id: <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 04:00:39 -0000 --Apple-Mail=_D871355B-4F3A-4EA2-8C59-05D87CCE1B26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, On 2013/08/29, at 19:59, Juergen Schoenwaelder = wrote: >> Do we have any usage scenario of the blocked state? >=20 > I thing this is backwards. I like my SNMP agent to access the current > state and report it. It does not matter whether I believe the state is > short lived or not. I like to see the actual state - not a translation > of it.=20 I understand that you want to see the 'raw' state of virtual machines. = I agree with you as an engineer :) But as an operator, I tend to think we need some kind of 'translation', = or in other words, higher level state information here. My previous wording of 'short-lived' might not be a proper word. Let me = try to make myself clearer. Maybe my question is that whether the 'blocked' state is a primary state = or not, in the sense of virtual machine operation. I think we need to = have some abstraction here. How it is implemented is a different = discussion. Well, we may provide the implementation specific state to MIB users, but = it is different level of information. I'm not saying that we should not = provide any detailed status information through VMM-MIB. For example, = in the KVM environment, we may want to know the process state = information of a running 'kvm' process as a detailed state information. What I want say here is that we probably need 'different' level of = information, or a model of virtual machine operation. It seems to me = that the 'blocked' state is not a primary state. It is rather a kind of = a sub-state of primary states, or an attribute of primary states (e.g. a = VM is running (and blocked)). I might think that the name of the 'running' state is misleading. If I = rephrase the 'running' state, for example, to 'in-operation' state, does = my opinion become clearer? I may be wrong. Any comments are welcome :) --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/08/29, at 19:59, Juergen Schoenwaelder = wrote: > On Thu, Aug 29, 2013 at 07:27:40PM +0900, SHIMA Keiichi wrote: >=20 > [...] >=20 >> Do we have any usage scenario of the blocked state? >=20 > I thing this is backwards. I like my SNMP agent to access the current > state and report it. It does not matter whether I believe the state is > short lived or not. I like to see the actual state - not a translation > of it. The worst experience when I debug problems is when software > tries to hide reality. And, btw, being blocked is really not uncommon > in a Xen setup. >=20 > $ sudo xm list > Name ID Mem VCPUs State = Time(s) > Domain-0 0 4160 8 r----- = 267537.1 > foo 3 512 1 -b---- = 39148.0 > bar 17 2048 1 -b---- = 71467.1 > baz 20 2048 1 -b---- = 80750.0 > bing 6 1024 1 -b---- = 66408.8 > bong 8 256 1 -b---- = 57365.8 > bang 21 1024 1 -b---- = 36534.1 > yum 10 256 1 -b---- = 41611.5 > yam 15 1024 1 -b---- = 49363.2 > yim 16 2048 1 -b---- = 44081.6 >=20 > (Taken from a live machine with names obfuscated.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_D871355B-4F3A-4EA2-8C59-05D87CCE1B26 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKRDCCBNcw ggK/oAMCAQICCwDVKQnjpxHSzZzEMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNVBAYTAkpQMRUwEwYD VQQKDAxXSURFIFByb2plY3QxHzAdBgNVBAMMFm1lbWJlcnMgb3JpZW50ZWQgQ0EgMDMwHhcNMTMw NjI1MTQzNjM3WhcNMTUwNjMwMjM1OTU5WjBkMQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQ cm9qZWN0MR0wGwYDVQQDDBQwMzI4IEtlaWljaGkgU2hpbWEgNDEfMB0GCSqGSIb3DQEJARYQc2hp bWFAd2lkZS5hZC5qcDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM//e0ghqwWrhi0o dqz+plMayBUy8JK22Ov3qwKHJpti152W1ww6+US3TZqK0NMHQgsHnCyMZYbYdnunzWT2/TPfmKPx JX4WF/ZTP7RphWFaUfgmz9Iykoo+K93qVBngFda6j6fUP3Kk8jkU0vL5RH/EnBLZG8aKy0Orgcc0 1n8VdePqSpldueDw1F9A3aA/IdKY74jo+/aRnvCfEo5mxhZUV5ULgsWvsja9HhGXZdxotj5/2Da4 HB9Paj2skamGiA0KJKphE/VKCF8ksOPeYXxR5J7rr8Ti3azfEMR5EM2UAFO9VOXJqRoGYdaKIeo1 8e+2rRVkamPDWT7EhiO89u8CAwEAAaOBqDCBpTALBgNVHQ8EBAMCBLAwGwYDVR0RBBQwEoEQc2hp bWFAd2lkZS5hZC5qcDAvBgNVHR8EKDAmMCSgIqAghh5odHRwOi8vbW9jYS53aWRlLmFkLmpwL2Ny bC5jcmwwHwYDVR0jBBgwFoAUlpT82BlfTL9FMdyssrhbVQdMiw8wJwYDVR0lBCAwHgYIKwYBBQUH AwQGCCsGAQUFBwMDBggrBgEFBQcDAjANBgkqhkiG9w0BAQsFAAOCAgEAKNpKYrelWSNM3Xg2n5mE kAqYptfQYVQYbWlHEndLnGjIP2FsXby4pKNVa11LczoW5y28HE5rQ8HUQGcgXDeOTTup27eq62UR IbywlGIWH+PjYly4Vivt74+ICjh8dXyZ55R2OvkrViSl6mSzP6j0SNr1e9Z/Y594isTl6UkfnD3m IDPvfCAheaNBUF2DPJ6dsABjaFfGA4FY3R4Aczrtvlh5IzpGvsDzj1RyL+VlUCSkPw2pB3aiR6Qu 072C482j0B3FvD4huoxnvaAV0Qh5qqRCosbe0dkLMLfs8G3LgaMADWzlvsgiHKHb2C0FMBWWVWvL i+y1acfqNSxcVQlgvIBlndPPa4eNrGIEeplw7MQ62YCQTtb+4dc6aE2uJf2rprE3gw+wduvURL0G E2p3bx9RA2Biq+Bq1c+kT2dsfGmFSAWMVPoUxm405QJMl++/PbW377CQKnkBe1gAhwyrC/dnwFEY g8tTf/xmtzbV637LcHD4f+B3TR+wcnbVoOOEXBOZVMdLk6/qxpX4TD/i+2v3qLEtVm3pD8Fwunuy KRRV3mM3iApBM2j1EhAUGjv7FHtreijbRUlHPE+5mjzDLaPHM5nvnR0TDmbly/RCkuU0j/UE3QeV RXeocpf8QfsfxJzi4zJwnLLu8vcB75plyj+a+KZYCKQPWzdyECDItBQwggVlMIIDTaADAgECAgsA 3pfLDt1eq5DA7TANBgkqhkiG9w0BAQsFADA+MQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQ cm9qZWN0MRgwFgYDVQQDDA9XSURFIFJPT1QgQ0EgMDMwHhcNMTMwNjAzMTIwMDI0WhcNMjMwNjMw MTQwNTEyWjBFMQswCQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQcm9qZWN0MR8wHQYDVQQDDBZt ZW1iZXJzIG9yaWVudGVkIENBIDAzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAnX+t N/1KWgtexAc658h4NY5IvJbShg3gIpoITVP8IAFhcFSed6t7RQaKomEFP0NZxL4+rntl6F80MB/2 freB2pGkCxA81tC1gRw8ZkgWMS9+qPZYOAW5hBOMjrykrSI7+NyGno7bL2Sso/b+FRmHASqWJ05L qOs64EX3g40sNjFNx2AHQXoas1HdWNvj8QpZipCPv1ZFdvUlu9eZ2CQj7rd9bvUBGrdCuV2rBb1v n5LbtjHgYsw/Ic5f8PLlJ0BOPdYYRjtgHW1UNzERxGnambcH+dRE4L0+ThCPNQiJu7nxBvkMG9t5 K+1b/rF8BuvYJrM3BpYtc50y3YmAFTrqlkE85iPsGe1BP8/s6EphkSBeKBq1aYSds4rhiM+tr5dS CKoowiNR41OWC7kEbew5bmiM0MDqqhJx4QKs0LsgngjwdwR1gyCWrR4DwaQn13H+fbEj9C4g3jy5 wIS6wI/pgjfBtYZNlR6LbRwqmq98e5TLmbeooDcTpBQVlfozDVGib0u2BT3toc1GZeXO1aL41xye CnMaKdlxWLcymp1Pue7FJEQwW5J5vKkD08m5DE0IX0i9R2aHgm5tN4AJBWSo2dc9w6HhD/PjugaM BhTIDdgkxibAjVxI8grPwDLdLWDwwhl7+ZPRTQ17Qe+nqjF/w3kOhiWYAKBTBMGcvt/ZpYECAwEA AaNdMFswHQYDVR0OBBYEFJaU/NgZX0y/RTHcrLK4W1UHTIsPMB8GA1UdIwQYMBaAFDhrU7/rSxuL APgA6CJlDQCm847qMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBCwUAA4IC AQCDysFnIkZoio7HmwBZ0MaIv6REQtCweXy4P0LVka1HwqoqepCgOBZJY2MMXE6ZUxbuT+HEsskk iMjloh4xCRyL9ds3zZ6gMhDvx3pEgGhe7iusJI/bfCe10ZIGTcrWaZwohN9ubbHXyC47QqDTh6Oj EMosEjnWTUzm6H9NsoKQNYKQCCpP4bNJO1urUueHR74FuH5i6taI/RAm1qdoRoeH7qwL2Lvg/kPL yJE3hUiNpw3VQSC29Tx9KUgvltodiwX6tu5oroM+MgywMWwgNlmKEYmqa9DWeXIBzA47m3l9Bruo qXXdsUTzzF7K/bkflJWNIhCzaJfkFnJqGacuJiBFnjeqy0aOZ5gWvG3rBpJgGro8Pdgz/9NHTXe4 9zhFmR1eeDDNNmWL2U060NjwxCBZKe1UQs+7qiCKsybHwv7e43UB2LZodD356WLtAb3jwslVHah2 ZGzX2LihURz4s7UO8XiqFO0GAtcFbTj0if30ex7EHVe7Y+xg/MCmu2Dy1P071fNrkZhEaZcrU1PV ubfZQJG5mAEW3K4HDMwZl7SH624K/s8QpWZgBoz1FYvh3W0dj1y/i+dAi3hmwRlCx07+jUA4FhWH CI/8KxZLg/z4jj5F8BVI7FLOr1rgFOPdU2JjPDIaKIj0Ggrun7KtNRyEect37auh6rCZTfL3SAwv UDGCAqgwggKkAgEBMFQwRTELMAkGA1UEBhMCSlAxFTATBgNVBAoMDFdJREUgUHJvamVjdDEfMB0G A1UEAwwWbWVtYmVycyBvcmllbnRlZCBDQSAwMwILANUpCeOnEdLNnMQwCQYFKw4DAhoFAKCCASkw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwODMwMDQwMDI5WjAj BgkqhkiG9w0BCQQxFgQUDqNMtK7WmAJ0bdHvpiFrXd4NBaAwYwYJKwYBBAGCNxAEMVYwVDBFMQsw CQYDVQQGEwJKUDEVMBMGA1UECgwMV0lERSBQcm9qZWN0MR8wHQYDVQQDDBZtZW1iZXJzIG9yaWVu dGVkIENBIDAzAgsA1SkJ46cR0s2cxDBlBgsqhkiG9w0BCRACCzFWoFQwRTELMAkGA1UEBhMCSlAx FTATBgNVBAoMDFdJREUgUHJvamVjdDEfMB0GA1UEAwwWbWVtYmVycyBvcmllbnRlZCBDQSAwMwIL ANUpCeOnEdLNnMQwDQYJKoZIhvcNAQEBBQAEggEAjgQaYpd3OMKR+K41g8miC912g9K8u7gVHrSc I6t2DPx/3tVmnuQRkvH7TSTrgpcsu0YOacMnLFUfAy61aBJZ50BBEjJfritxMS9GFOr2LOew1kVw 22bdpuRWD5x74H31RoeFmZ8i0gpQW4bDqCEv41CvEdxTFC8gB4zEqoXLDSAq8OkII488Cg+QA//j cROXKWTaP/TQOeJH0RCC0/dlzCzj4H1tbpw0loJmZANrmC7ee/781NCfuby+l27SflCSGB2XWHfr pXhcPl9bB6hHVGvYS8nfvSfMmapsFohUbDa7VVA5ugP2IBPKjPkUIUQiXOsyqoIXdsYtL7cas5q6 pQAAAAAAAA== --Apple-Mail=_D871355B-4F3A-4EA2-8C59-05D87CCE1B26-- From mrm@vmware.com Thu Aug 29 22:03:05 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C318321E8092 for ; Thu, 29 Aug 2013 22:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqlhPQ7uIIYr for ; Thu, 29 Aug 2013 22:02:54 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0717721E8085 for ; Thu, 29 Aug 2013 22:02:53 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 2853728AC0; Thu, 29 Aug 2013 22:02:51 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 2647C18380; Thu, 29 Aug 2013 22:02:51 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 11E89E0044; Thu, 29 Aug 2013 22:02:51 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Thu, 29 Aug 2013 22:02:50 -0700 (PDT) Date: Thu, 29 Aug 2013 22:02:50 -0700 (PDT) From: Michael MacFaden To: SHIMA Keiichi Message-ID: <472961438.3755064.1377838970831.JavaMail.root@vmware.com> In-Reply-To: <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VMM-MIB: question about vmAdminState values Thread-Index: rEQSpTchqiooLTKYBYmxHikc9I7wVQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 05:03:05 -0000 > Maybe my question is that whether the 'blocked' state is a primary state or > not, in the sense of virtual machine operation. I think we need to have > some abstraction here. How it is implemented is a different discussion. Yes. > What I want say here is that we probably need 'different' level of > information, or a model of virtual machine operation. It seems to me that > the 'blocked' state is not a primary state. It is rather a kind of a > sub-state of primary states, or an attribute of primary states (e.g. a VM is > running (and blocked)). The key thing in any standard is that different folks read the standard and implement it. We then have a bakeoff/implementation report and see if we got it right nor not. I haven't put my two cents into the state machine yet either. And to me blocked given what is written so far is quite generic. Question is: what would an operator do if they saw a vm in blocked state? Here's some blocked states in VMware's implemtation. 1) Operator moved a vm fileset (vmx config file, vmdk virtual disks from a usb to a new machine and powered on. vmx process will block waiting for a connection to the vmx to answer the question (did you move or copy the vm?) It then updates the vmx config file appropriately. There are quite a number of "questions" that can block a VM. 2) VM can block operation during hot add/delete of devices, when doing live migration (vmotion (tm)) and so forth. Again is blocked something the operator has to deal with or not? Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA From j.schoenwaelder@jacobs-university.de Thu Aug 29 22:17:19 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5411E8195 for ; Thu, 29 Aug 2013 22:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.237 X-Spam-Level: X-Spam-Status: No, score=-103.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI2KMGgHitNF for ; Thu, 29 Aug 2013 22:17:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 652F711E80E8 for ; Thu, 29 Aug 2013 22:17:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79A9520C5F; Fri, 30 Aug 2013 07:17:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PSNhwozNdHHl; Fri, 30 Aug 2013 07:17:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A52A420C5B; Fri, 30 Aug 2013 07:17:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2B4072815A8A; Fri, 30 Aug 2013 07:17:00 +0200 (CEST) Date: Fri, 30 Aug 2013 07:16:59 +0200 From: Juergen Schoenwaelder To: SHIMA Keiichi Message-ID: <20130830051659.GA58870@elstar.local> Mail-Followup-To: SHIMA Keiichi , opsawg@ietf.org References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 05:17:20 -0000 X-List-Received-Date: Fri, 30 Aug 2013 05:17:20 -0000 On Fri, Aug 30, 2013 at 01:00:28PM +0900, SHIMA Keiichi wrote: > Hello, > > On 2013/08/29, at 19:59, Juergen Schoenwaelder wrote: > > >> Do we have any usage scenario of the blocked state? > > > > I thing this is backwards. I like my SNMP agent to access the current > > state and report it. It does not matter whether I believe the state is > > short lived or not. I like to see the actual state - not a translation > > of it. > > I understand that you want to see the 'raw' state of virtual machines. I agree with you as an engineer :) > But as an operator, I tend to think we need some kind of 'translation', or in other words, higher level state information here. > > My previous wording of 'short-lived' might not be a proper word. Let me try to make myself clearer. > > Maybe my question is that whether the 'blocked' state is a primary state or not, in the sense of virtual machine operation. I think we need to have some abstraction here. How it is implemented is a different discussion. > > Well, we may provide the implementation specific state to MIB users, but it is different level of information. I'm not saying that we should not provide any detailed status information through VMM-MIB. For example, in the KVM environment, we may want to know the process state information of a running 'kvm' process as a detailed state information. > > What I want say here is that we probably need 'different' level of information, or a model of virtual machine operation. It seems to me that the 'blocked' state is not a primary state. It is rather a kind of a sub-state of primary states, or an attribute of primary states (e.g. a VM is running (and blocked)). > > I might think that the name of the 'running' state is misleading. If I rephrase the 'running' state, for example, to 'in-operation' state, does my opinion become clearer? > I do not get your point, probably because of a lack of definition of 'primary state'. ;-) Perhaps you want to write management software that provides other abstractions on top of what the various MIB modules provide - thats fine. I doubt the SNMP agent is the right place to provide abstractions though. And for the KVM case, please note that the process state is already available from other existing MIB modules. I repeat myself: For troubleshooting purposes, you want the real state and not a classification of states - which may be fuzzy. Or more precisely, whether a blocked VM is good or bad depends on the context. Requiring the SNMP agent to figure out the context correctly and to classify the state accordingly is adding significant complexity and agent code is much harder to change and adapt than management software. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From panda@hongo.wide.ad.jp Thu Aug 29 22:35:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58EB21E805A for ; Thu, 29 Aug 2013 22:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INXS2w87l-wU for ; Thu, 29 Aug 2013 22:34:50 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id CE25F21E8054 for ; Thu, 29 Aug 2013 22:34:49 -0700 (PDT) Received: from [157.82.5.171] (unknown [157.82.5.171]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 07D9F108E50A; Fri, 30 Aug 2013 14:25:30 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <359743075.3699910.1377827047802.JavaMail.root@vmware.com> Date: Fri, 30 Aug 2013 14:34:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <521158A7.2090407@cisco.com> <52126061.2000008@cisco.com> <531716211.32859971.1376937482642.JavaMail.root@vmware.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> <521285FE.2020507@cisco.com> <3C80E218-DCAD-4FAA-9F4C-BC8A3BED67D4@hongo.wide.ad.jp> <359743075.3699910.1377827047802.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 05:35:01 -0000 Yes, I agree that the MIB module shouldn't preclude adding any = functionalities. So we'd better not to have the virtual IPMI object in the MIB in order = not to prevent adding them from developers. Best regards, Hirochika On Aug 30, 2013, at 10:44 AM, Michael MacFaden wrote: > Asai-san writes: >> But let me ask to the list about the virtual IPMI implementation. >>> Does anybody know such other implementations of the virtual IPMI? >>> If there are, we may need to take into account them. >> I couldn't find any other implementations of the virtual IPMI, so my >> opinion is that we do not need an object related to the virtual IPMI >> or something like it. If you find any, I'd like you to let me know. >=20 > I'm not aware of either a virtualized or just pass-through access to = IPMI > hardware in VMware products or I'd have been happily usig it many = times=20 > over to allow me to test ESXi SNMP agent RFC 2790 implementation in a = VM[1] >=20 > If there are none, lets just make sure the MIB module doesn't preclude > adding that... >=20 > Regards, > Mike >=20 > [1]=20 > $ esxcfg-info | grep Product Name > |----Product Name.............................................IBM = System x3200 M2 -[4368AC1]- > # diagnostics report > $/bin/snmpd -S > INFO: fetching sensors... > record id: 8, length: 42, type: 2 entity: 7 instance: 1 > record id: 9, length: 35, type: 2 entity: 7 instance: 1 > record id: 14, length: 37, type: 2 entity: 3 instance: 1 > record id: 15, length: 37, type: 2 entity: 20 instance: 1 > record id: 17, length: 36, type: 2 entity: 23 instance: 1 > record id: 18, length: 37, type: 2 entity: 7 instance: 1 > record id: 20, length: 42, type: 2 entity: 7 instance: 1 > record id: 21, length: 40, type: 2 entity: 7 instance: 1 > record id: 22, length: 40, type: 2 entity: 7 instance: 1 > record id: 29, length: 40, type: 2 entity: 23 instance: 1 > record id: 34, length: 39, type: 2 entity: 3 instance: 1 > record id: 36, length: 34, type: 2 entity: 7 instance: 1 > record id: 60, length: 41, type: 2 entity: 4 instance: 2 > record id: 61, length: 41, type: 2 entity: 4 instance: 1 > record id: 62, length: 41, type: 2 entity: 4 instance: 4 > record id: 63, length: 41, type: 2 entity: 4 instance: 5 > record id: 64, length: 41, type: 2 entity: 4 instance: 6 > record id: 65, length: 41, type: 2 entity: 4 instance: 7 > record id: 66, length: 41, type: 2 entity: 4 instance: 8 > record id: 74, length: 41, type: 2 entity: 4 instance: 3 > record id: 75, length: 38, type: 2 entity: 21 instance: 1 > record id: 76, length: 38, type: 2 entity: 21 instance: 2 > record id: 77, length: 41, type: 2 entity: 21 instance: 3 > record id: 78, length: 41, type: 2 entity: 21 instance: 4 > record id: 79, length: 38, type: 2 entity: 21 instance: 5 > record id: 80, length: 37, type: 2 entity: 0 instance: 1 > INFO: sensor sweep completed, using total of 11 sensor entries in sdr > [0] name: VRD Status, inst: 1, type: POWER, status: D_Normal, errors: = 0 > [1] name: PS 1 Status, inst: 1, type: POWER, status: D_Normal, errors: = 0 > [2] name: PS 2 Status, inst: 2, type: POWER, status: D_Normal, errors: = 0 > [3] name: PS Overspec, inst: 5, type: POWER, status: D_Normal, errors: = 0 > [4] name: Fan 1 Tach, inst: 1, type: FAN, status: D_Normal, errors: 0 > [5] name: Fan 2 Tach, inst: 2, type: FAN, status: D_Normal, errors: 0 > [6] name: Fan 3 Tach, inst: 3, type: FAN, status: D_Normal, errors: 0 > [7] name: PS 1 Fan Fault, inst: 3, type: FAN, status: D_Normal, = errors: 0 > [8] name: PS 2 Fan Fault, inst: 4, type: FAN, status: D_Normal, = errors: 0 > [9] name: CPU Status, inst: 1, type: CPU, status: D_Normal, errors: 0 > [10] name: CPU OverTemp, inst: 1, type: CPU, status: D_Normal, errors: = 0 > INFO: report complete >=20 --=20 Hirochika Asai , The University of Tokyo From mrm@vmware.com Thu Aug 29 22:40:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8FA21F999E for ; Thu, 29 Aug 2013 22:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l623wU9KnJKa for ; Thu, 29 Aug 2013 22:40:26 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3B73A21F994A for ; Thu, 29 Aug 2013 22:40:26 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id E07A92838E; Thu, 29 Aug 2013 22:40:22 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id D92A0402FC; Thu, 29 Aug 2013 22:40:22 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id C2509E0049; Thu, 29 Aug 2013 22:40:22 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Thu, 29 Aug 2013 22:40:22 -0700 (PDT) Date: Thu, 29 Aug 2013 22:40:22 -0700 (PDT) From: Michael MacFaden To: Hirochika Asai Message-ID: <953549733.3762987.1377841222039.JavaMail.root@vmware.com> In-Reply-To: References: <521158A7.2090407@cisco.com> <52128177.9020600@cisco.com> <767970431.33038278.1376945535247.JavaMail.root@vmware.com> <521285FE.2020507@cisco.com> <3C80E218-DCAD-4FAA-9F4C-BC8A3BED67D4@hongo.wide.ad.jp> <359743075.3699910.1377827047802.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) Thread-Index: EAcR0Nv4jeHRxCMYTl/AzOaA1ydHTA== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VM-MIB: Proposal: Joe-2 (was Re: Comments on draft-asai-vmm-mib-04) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 05:40:37 -0000 > Yes, I agree that the MIB module shouldn't preclude adding any > functionalities. > So we'd better not to have the virtual IPMI object in the MIB in order not to > prevent adding them from developers. I agree. Mike From keiichi.shima.1016@gmail.com Fri Aug 30 02:08:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA921E80AB for ; Fri, 30 Aug 2013 02:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAwJKW3HGp5T for ; Fri, 30 Aug 2013 02:08:05 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id C403521E80A3 for ; Fri, 30 Aug 2013 02:08:05 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so1616787pdj.12 for ; Fri, 30 Aug 2013 02:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r+iUDHQrbD4t1A/shQ2t1vhp0M+QPt0XTPglKHmO/w0=; b=Hnj5k+Je98QQnTIscK2Jf1SbZIaacidt2eSsomLR1TmDqEykWGfi6mFJWzEcr2z1o3 zHGRZAVUPQiBWS6iMzB/eg6fGmEcQy+3iqyXH7YxRrKLYJvFSOHG7FVaVMSS2ozrw2/7 XVtPNkvsXPi6uf8Ov4J/yfphNghbxeTNXpmhcl9lAfyp3IXpy36W5qXy0FQn00dLm1bY I0HHxw2JgfApFzbmmUgXNvC3MCCJ8A/5r4PPTTdRni61Jtu1FK1iiIx8HJLdf4qsyANm NIOi++Neejhoq3UC8nZ53KG+4tgjOv6xAc8SLjNN5yUPyMRU9jmsqmL1JUQYbsHkU/w5 eG3w== X-Received: by 10.66.154.169 with SMTP id vp9mr845028pab.190.1377853677589; Fri, 30 Aug 2013 02:07:57 -0700 (PDT) Received: from ?IPv6:2001:240:11e:c01:1d46:ef07:c181:1709? ([2001:240:11e:c01:1d46:ef07:c181:1709]) by mx.google.com with ESMTPSA id wp8sm43161999pbc.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 02:07:56 -0700 (PDT) Sender: Keiichi SHIMA Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: SHIMA Keiichi In-Reply-To: <472961438.3755064.1377838970831.JavaMail.root@vmware.com> Date: Fri, 30 Aug 2013 18:07:54 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9C83AD2E-732B-4277-A337-1D166FB1A188@wide.ad.jp> References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> <472961438.3755064.1377838970831.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 09:08:06 -0000 Hello, On 2013/08/30, at 14:02, Michael MacFaden wrote: > Here's some blocked states in VMware's implemtation. >=20 > 1) Operator moved a vm fileset (vmx config file, vmdk virtual disks = from=20 > a usb to a new machine and powered on. vmx process will block waiting = for > a connection to the vmx to answer the question (did you move or copy = the vm?) > It then updates the vmx config file appropriately. There are quite a = number > of "questions" that can block a VM. Thank you for showing some examples in VMware. Since I'm not very = familiar with it, the above information is quite useful to me. And, the above examples are cases what I was not thinking about. They = are events caused by procedures of virtual machine 'operation'. I tend = to agree that the VirtualMachineOperState should be able to distinguish = the above situations=E2=80=A6 I still think the above situations and the blocked state of Xen (caused = by I/O wait between DomU and Dom0, which is not cased by operator's = actions) are a bit different context. In the current VMM-MIB draft = though, both situations are marked as blocked. But I'm not sure it is a = correct design or not. I noticed that I have one assumption that we haven't shared among us. = In my understanding, the state transition is initiated by operation = actions (except the crash case). So, the transition to/from the blocked = state looks a bit strange to me. But Juergen doesn't have such an = assumption. That is the reason of the gap between I and others, maybe. > 2) VM can block operation during hot add/delete of devices, when doing > live migration (vmotion (tm)) and so forth. This case is also a confusing case to me. In the current draft, when a = VM is migrated, its state is changed to the 'migrating' state. But in = the VMware case, the state is blocked (or migrating & blocked, maybe). It may be necessary to review and refine the meanings of = VirtualMachineOperState and the model of the state machine more = carefully. Though I'm not sure if it must be done in the current = version. Or maybe in the next major revision based on inputs from = implementors and operators. Regards, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/08/30, at 14:02, Michael MacFaden wrote: >> Maybe my question is that whether the 'blocked' state is a primary = state or >> not, in the sense of virtual machine operation. I think we need to = have >> some abstraction here. How it is implemented is a different = discussion. >=20 > Yes. >=20 >=20 >> What I want say here is that we probably need 'different' level of >> information, or a model of virtual machine operation. It seems to me = that >> the 'blocked' state is not a primary state. It is rather a kind of a >> sub-state of primary states, or an attribute of primary states (e.g. = a VM is >> running (and blocked)). >=20 > The key thing in any standard is that different folks read the = standard > and implement it. We then have a bakeoff/implementation report and see = if > we got it right nor not. >=20 > I haven't put my two cents into the state machine yet either. And to = me > blocked given what is written so far is quite generic. >=20 > Question is: what would an operator do if they saw a vm in blocked = state? >=20 > Here's some blocked states in VMware's implemtation. >=20 > 1) Operator moved a vm fileset (vmx config file, vmdk virtual disks = from=20 > a usb to a new machine and powered on. vmx process will block waiting = for > a connection to the vmx to answer the question (did you move or copy = the vm?) > It then updates the vmx config file appropriately. There are quite a = number > of "questions" that can block a VM. >=20 > 2) VM can block operation during hot add/delete of devices, when doing > live migration (vmotion (tm)) and so forth. >=20 > Again is blocked something the operator has to deal with or not? >=20 >=20 > Mike MacFaden Staff Engineer R&D Apps VMware, Inc Palo Alto CA > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From keiichi.shima.1016@gmail.com Fri Aug 30 02:08:27 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1838F21E80B3 for ; Fri, 30 Aug 2013 02:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoCeN6jdkqPB for ; Fri, 30 Aug 2013 02:08:25 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B721E80AE for ; Fri, 30 Aug 2013 02:08:11 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so2078496pad.4 for ; Fri, 30 Aug 2013 02:08:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/pDXpV92wKLy1jOEVMfJnUP+6jcyLMWQkSkk7dmMukA=; b=YCghTImWKCNeOP8otGewLW9te9anMtKY3rLIxBOMLzQWIdZsgKsUK68Zh6tlJ2OC1N f9rguB0idg4zngPkwb8DlA7h8Gh5y87mf/OwWmoBd/7z27LMXcpEUUt+hjpb/npcYx80 V3cBcVssKMPtoTywZse7i57DTfmCdShchOyLktdIAqzZa51yocs1OsI1JOKvXw9V+Ydu 9lfZVBis7oX+pvBoVpFrvR3Fe/xVBeX6vW5lfxLjkMqgWzGVq+KX9SQVeKgkmL/beJpk 8uP89+8YggqHvDqRMvtOxLsksYxxJDsjgC8VBQPmgz/7JFNrwy3EG5p6JnktwywIM3r6 fhsg== X-Received: by 10.66.102.1 with SMTP id fk1mr9492625pab.90.1377853691409; Fri, 30 Aug 2013 02:08:11 -0700 (PDT) Received: from ?IPv6:2001:240:11e:c01:1d46:ef07:c181:1709? ([2001:240:11e:c01:1d46:ef07:c181:1709]) by mx.google.com with ESMTPSA id wp8sm43161999pbc.26.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 02:08:10 -0700 (PDT) Sender: Keiichi SHIMA Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: SHIMA Keiichi In-Reply-To: <20130830051659.GA58870@elstar.local> Date: Fri, 30 Aug 2013 18:08:10 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3E194864-ABEA-45DF-B37B-C5674EBE0558@wide.ad.jp> References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> <20130830051659.GA58870@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 09:08:27 -0000 Hello, Thank you for your comments. On 2013/08/30, at 14:16, Juergen Schoenwaelder = wrote: > I do not get your point, probably because of a lack of definition of > 'primary state'. ;-) >=20 > Perhaps you want to write management software that provides other > abstractions on top of what the various MIB modules provide - thats > fine. I doubt the SNMP agent is the right place to provide > abstractions though. So, you are saying that the MIB should provide a kind of raw data, and = how it is translated (or understood) should be done in upper layer = applications. Is my understanding correct? Yes, I must agree with you. As I mentioned in my previous mail, my understanding of = VirtualMachineOperState and yours is a bit different, I guess. I was = thinking the state transition is initiated by an operator, and the next = state is determined by the result of the operator's action. But you = are thinking that VirtualMachineOperState is also changed by other = factors (like I/O blocking in a hypervisor level). Once we have a concrete definition of VirtualMachineOperState, maybe my = question will be solved. > And for the KVM case, please note that the > process state is already available from other existing MIB modules. Ok, thank you for this information! > I repeat myself: For troubleshooting purposes, you want the real state > and not a classification of states - which may be fuzzy. Or more > precisely, whether a blocked VM is good or bad depends on the context. > Requiring the SNMP agent to figure out the context correctly and to > classify the state accordingly is adding significant complexity and > agent code is much harder to change and adapt than management = software. I understand your concern. I am not saying we should not provide real (or detailed) state = information. It is certainly useful to get state information as is. As I mentioned above, I believe that the definition of the meaning of = VirtualMachineOperState is the key to conclude this discussion. In = section 3.2, there is a text about how the vmOperState changes. "The transition of `vmOperState' by the write access to `vmAdminState' and the notifications generated by the operational state changes are summarized in Figure 2." If I'm not missing, there is no other explanation about how the = vmOperState should behave. Maybe we need more concrete description in = the vmOperState section. Currently, it just says as below. "The current operational state of the virtual machine." Also, if we keep the blocked state and the state machine figure, then it = would be better to provide a complete state transition table. The = current figure-style state machine lacks transition flows between the = blocked state and other states. I don't want to draw that part in the = figure, since it will mess up the figure :) How about adding a separate = table in a appendix section? Regards, --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/08/30, at 14:16, Juergen Schoenwaelder = wrote: > On Fri, Aug 30, 2013 at 01:00:28PM +0900, SHIMA Keiichi wrote: >> Hello, >>=20 >> On 2013/08/29, at 19:59, Juergen Schoenwaelder = wrote: >>=20 >>>> Do we have any usage scenario of the blocked state? >>>=20 >>> I thing this is backwards. I like my SNMP agent to access the = current >>> state and report it. It does not matter whether I believe the state = is >>> short lived or not. I like to see the actual state - not a = translation >>> of it.=20 >>=20 >> I understand that you want to see the 'raw' state of virtual = machines. I agree with you as an engineer :) >> But as an operator, I tend to think we need some kind of = 'translation', or in other words, higher level state information here. >>=20 >> My previous wording of 'short-lived' might not be a proper word. Let = me try to make myself clearer. >>=20 >> Maybe my question is that whether the 'blocked' state is a primary = state or not, in the sense of virtual machine operation. I think we = need to have some abstraction here. How it is implemented is a = different discussion. >>=20 >> Well, we may provide the implementation specific state to MIB users, = but it is different level of information. I'm not saying that we should = not provide any detailed status information through VMM-MIB. For = example, in the KVM environment, we may want to know the process state = information of a running 'kvm' process as a detailed state information. >>=20 >> What I want say here is that we probably need 'different' level of = information, or a model of virtual machine operation. It seems to me = that the 'blocked' state is not a primary state. It is rather a kind of = a sub-state of primary states, or an attribute of primary states (e.g. a = VM is running (and blocked)). >>=20 >> I might think that the name of the 'running' state is misleading. If = I rephrase the 'running' state, for example, to 'in-operation' state, = does my opinion become clearer? >>=20 >=20 > I do not get your point, probably because of a lack of definition of > 'primary state'. ;-) >=20 > Perhaps you want to write management software that provides other > abstractions on top of what the various MIB modules provide - thats > fine. I doubt the SNMP agent is the right place to provide > abstractions though. And for the KVM case, please note that the > process state is already available from other existing MIB modules. >=20 > I repeat myself: For troubleshooting purposes, you want the real state > and not a classification of states - which may be fuzzy. Or more > precisely, whether a blocked VM is good or bad depends on the context. > Requiring the SNMP agent to figure out the context correctly and to > classify the state accordingly is adding significant complexity and > agent code is much harder to change and adapt than management = software. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Fri Aug 30 02:30:16 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D9021E80C1 for ; Fri, 30 Aug 2013 02:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.238 X-Spam-Level: X-Spam-Status: No, score=-103.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rum-5nSPIH-C for ; Fri, 30 Aug 2013 02:30:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B062621E80B3 for ; Fri, 30 Aug 2013 02:30:09 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E562720C80; Fri, 30 Aug 2013 11:30:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CrTckbINH5Be; Fri, 30 Aug 2013 11:30:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8412B20C88; Fri, 30 Aug 2013 11:30:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD9A62816268; Fri, 30 Aug 2013 11:29:58 +0200 (CEST) Date: Fri, 30 Aug 2013 11:29:58 +0200 From: Juergen Schoenwaelder To: SHIMA Keiichi Message-ID: <20130830092958.GA59719@elstar.local> Mail-Followup-To: SHIMA Keiichi , opsawg@ietf.org References: <20130826105955.GA17723@elstar.local> <20130829105950.GB56383@elstar.local> <49ABC6BC-EA97-434E-A340-53214054CADE@wide.ad.jp> <20130830051659.GA58870@elstar.local> <3E194864-ABEA-45DF-B37B-C5674EBE0558@wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E194864-ABEA-45DF-B37B-C5674EBE0558@wide.ad.jp> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB: question about vmAdminState values X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 09:30:16 -0000 On Fri, Aug 30, 2013 at 06:08:10PM +0900, SHIMA Keiichi wrote: > > If I'm not missing, there is no other explanation about how the vmOperState should behave. Maybe we need more concrete description in the vmOperState section. Currently, it just says as below. > > "The current operational state of the virtual machine." > I think this is pretty clear - it is the _current_ _operational_ state and indeed a virtual machine may cycle between states or it may go through a sequence of state changes while carrying out a complex administrative action like migrate from hypervisor A to B. The MIB module is not modeling such administrative actions - its aim is only to report what is actually happening for monitoring or troubleshooting purposes. In other words, if you instruct your hypervisor controller to migrate a virtual machine from hypervisor A to B, then the MIB module allows you to monitor how this migration process is carried out. I see this very similar to process states and process state changes at the operating system level. If you, for example, tell an application to terminate, then the underlying processes still go through a sequence of state changes until they finally (hopefully) disappear. > Also, if we keep the blocked state and the state machine figure, > then it would be better to provide a complete state transition > table. The current figure-style state machine lacks transition > flows between the blocked state and other states. I don't want to > draw that part in the figure, since it will mess up the figure :) > How about adding a separate table in a appendix section? Perhaps we can add an arrow from running to blocked and another from blocked to running. But I would not try to cover all possible transitions since you can transition into the crashed state from many states. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103