From panda@hongo.wide.ad.jp Mon Sep 3 20:57:49 2012 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 B675321F8552 for ; Mon, 3 Sep 2012 20:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.504 X-Spam-Level: *** X-Spam-Status: No, score=3.504 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V4SgCMaHxnv for ; Mon, 3 Sep 2012 20:57:49 -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 43F3F21F8484 for ; Mon, 3 Sep 2012 20:57:46 -0700 (PDT) Received: from [192.168.1.103] (KD106170150186.au-net.ne.jp [106.170.150.186]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id A36C9108E4C7; Tue, 4 Sep 2012 12:57:44 +0900 (JST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <20120731062557.GB77752@elstar.local> Date: Tue, 4 Sep 2012 12:57:42 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <9032A714-7304-4A29-82B9-3D2955158925@hongo.wide.ad.jp> <20120731062557.GB77752@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1278) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-asai-vmm-mib-00 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, 04 Sep 2012 03:57:49 -0000 js, Thanks for your comments and sorry for replying late. On Jul 30, 2012, at 11:25 PM, Juergen Schoenwaelder wrote: > Your MIB module still does not compile. Most of the issues seem > fixable. I am appending the output of smilint -s -l4 ./VMM-MIB: I'm trying to fix them. I'm ashamed to say but I didn't know smilint tool. >> 1. vifIndex >> We define vifIndex that is different from the pointers to ifIndex >> of IF-MIB and recommended to starting from 1. This is because is >> shall be changed on re-initialization of virtual machines. So, we >> think vmIfIndex is not resilient to the re-initialization and it is >> not good as the index. Moreover, the order of the underlying >> interface is not guaranteed to match the order at the virtual >> machine. For example, the order mismatches when vnic1 and vnic2 of >> the virtual machine can be assigned to tap101(ifIndex=201) and >> tap100(ifIndex=200), respectively. > > Not sure I understand this. I guess it boils down to the question > whether the MIB is written from the viewpoint of the virtual machines > or from the viewpoint of the hypervisor or host system. Yes, our MIB is written from the viewpoint of the virtual machines. As for the viewpoint, we are trying to hear operators opinions to think about which viewpoint is generically the best for the MIB. Just a note from the viewpoint of an implementer: At this time, I had a problem with the difference between Type-1 (a.k.a. bare metal) and Type-2 (a.k.a. hosted), and the layer of the management OS that runs the SNMP agent when I use hvCpuDeviceIndex to refer to HV's CPU load; for example, Xen's Dom-0 cannot refer to the hypervisor's CPUs but it corresponds to a priviledged virtual machine. I also try to generalize this point. Thanks, Hirochika -- Hirochika Asai , The University of Tokyo From melinda.shore@gmail.com Fri Sep 7 19:42:14 2012 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 F390921E80B4 for ; Fri, 7 Sep 2012 19:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7i2Eq9Zn7VD for ; Fri, 7 Sep 2012 19:42:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82E4221E805A for ; Fri, 7 Sep 2012 19:42:13 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so421049pbb.31 for ; Fri, 07 Sep 2012 19:42:13 -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=thNZfdBrH0zWatudwIMox0o/vlxyGoS+JUQ1T79ilTM=; b=qUHd5CwrXRiYYBnThB5fpEceSmg7j4OM9Em2/+ViHN4YWYrMXL5UjpXQIp0NikXEYg Qux/FXbVrm9PxaK9oCCb62NRURZ3LKQif25RewRP+okZC7mr5NG4cEdFJBsX2hFJ8W0I jeboTUif6p4B+HDguAv8XSLOfB5R4nFRhPF8RwqsUFw3UbBuRMOMKv7CKyS0Knqn6Ynu bigrchzScM8czIJusm1ohVNFo+Jv31hKD3DYjPd79D+WyJcEuvo+Ab/jcVpkGBt37kN0 PJcWd21YY6+OExDMvcYSJjiNGkKDMYG0scOrg3SHeNUZyxTI6lB7TNY79PQEShH0jUzD FoGQ== Received: by 10.68.226.134 with SMTP id rs6mr13120592pbc.5.1347072133343; Fri, 07 Sep 2012 19:42:13 -0700 (PDT) Received: from spandex.local (66-230-80-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.80.245]) by mx.google.com with ESMTPS id hr1sm4269888pbc.23.2012.09.07.19.42.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Sep 2012 19:42:12 -0700 (PDT) Message-ID: <504AB082.2050601@gmail.com> Date: Fri, 07 Sep 2012 18:42:10 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] IETF 85 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, 08 Sep 2012 02:42:14 -0000 It's time to start thinking about IETF 85. If you're working on something that you think should be discussed at the meeting, *now* is the time to get your draft published and start a discussion on the mailing list. Thanks, Melinda From liljenstolpe@gmail.com Fri Sep 7 21:14:40 2012 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 3EB2D21E80B4 for ; Fri, 7 Sep 2012 21:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF4EPKxPFJ8h for ; Fri, 7 Sep 2012 21:14:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 341D821E8064 for ; Fri, 7 Sep 2012 21:14:39 -0700 (PDT) Received: by dadf8 with SMTP id f8so166742dad.31 for ; Fri, 07 Sep 2012 21:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=LAS/TnNHgvUpVuqtbiY78d91Kbq0IybayX6ANvcMdtk=; b=gRpkvrEr9Z4khCLsRhk8+0mm1Sge97fov2fKRXm2MO9ib2/P2OglZgRsZ5EkNl84Sa qsQK+L3cUTeHPRfluVDlEGWhK4sGzVbpVh1XL6BvC/0pDmq8F1X0204RmcujsXsq/XV/ vGB8xsoZrhxDjDuvijYaCp+1m6y9zRsZHdso35aqq5NcaKbzcv+lhIsXQXoHNlmdbIYw +6bfiEd3yOk2Dw+cv2xPEv3Mb5x/014awbn/upjy0N1LHuQpUfcfw/lRDm6U34l9jnGT FcttovcxdXBXljgVGEMavnj+R1t2wXfQ0pgORqZAnA7/DUniur/QW+YPYEqvMhSu/8D8 JWMQ== Received: by 10.68.229.6 with SMTP id sm6mr13217763pbc.120.1347077678974; Fri, 07 Sep 2012 21:14:38 -0700 (PDT) Received: from gondul.asgaard.org (50-76-34-190-ip-static.hfc.comcastbusiness.net. [50.76.34.190]) by mx.google.com with ESMTPS id io1sm4408873pbc.43.2012.09.07.21.14.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Sep 2012 21:14:38 -0700 (PDT) From: Christopher LILJENSTOLPE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <1B2BD2D0-7EA4-4C13-AF4D-8119C28E7810@gmail.com> Date: Fri, 7 Sep 2012 21:13:03 -0700 To: "opsawg@ietf.org" , opsarea@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) X-Mailer: Apple Mail (2.1485) Subject: [OPSAWG] meeting minutes 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, 08 Sep 2012 04:14:40 -0000 Greetings, Here are the meeting minutes, sorry about the delay. They will = be posted shortly. Christopher IETF Operations Area Open Meeting and Operations Area Working Group Combined Meeting 2 August 2012, 1510-1710, Vancouver, BC Minutes by Tom Nadeau - edited by Christopher LILJENSTOLPE 1) Agenda bashing 2) draft-janapath-opsawg-flowoam-req Sam Aldrin: This seems very general, very high level. Tom Nadeau: Ori/GOogle: This seems like a good idea, but like it could be quite = bloated. Co-chair: There is a body of work around this that applies to many = areas. There are common security issues that make sense. Is there real = interest in solving this problem? Jeff Hass: There is plenty of interest in solving this problem. But = seeing this from a vendor perspective, you have two choices: generate = data with characteristics you are looking for and getting a reply, or a = packet with all characteristics. Then you tell the data path to send = that like a normal packet. The work is admirable, but ambitious. Bonica: You need to figure out which of the two paths in this work you = are interested in: data plane or control plane. If its the second, we = have plenty of tools. SNMP, CLI, etc=E2=80=A6 Jeff Haas: the fundamental problem we have is the programming we have in = the hardware. The problem you want to solve though, is to ask the = question of what is happening to my data once it hits the link. Which = path is chosen? Do you want to ask the data plane what its going versus = testing it. Scott Bradner: This is the same discussion around OAM that came up in = MPLS. The conclusion there is that you bake new silicon. You might want = to review these discussions. IF there is a solution to be had we should = have it, but it isn't easy. Warren: You can do this in the forwarding plane and the control plane. = If you do it in the data plane, vendors will complain. If you do this in = the control plane, you can do this and query this. Kireeti: Jeff said its hard, and scott did. Its harder than you think=E2=80= =A6 you mentioned data center. We have 16 new encapsulations for there. = This results in new hashing. Hardware is difficult because we have = random seeds generated in the hardware, which makes it difficult to be = told everything you need to know. Going back to what scott was saying = in MPLS, we found that we don't hash well there so we cheat. Now we hash = on random fields in the packet header. To solve that problem we = introduced something called Entropy Labels which improves hashing of = labels. The connection between data and control planes is important. = The CP and DP thought they were doing different things. We have a = trace route model and a ping mode. In the TR mode you find a field in = the header that can help you ping every path. That allows you to ping = every path. Chris: from jabber. Amir wants to agree with you. Bill Manning: How big is your data center? Why is there a data center = orientation if we are designing things for the IP protocol? What do you = do about virtualization. Is this time bounded? What are the constraints? = You have some clear issue of scoping. Jeff Haas: one other thing that=E2=80=99s in the draft that is = interesting in the draft is to say, "this link is underutilized, I want = to better utilize that" how do I do this? Its different functionality, = but useful. How do I split it out. Chris L: this example is DC centric, but I know of multiple other = examples that are CLOS like that are similar. DC is not the only = application. 3) draft-schoenw-opsawg-vm-mib Chair: There are two drafts for VM MIBs, one from Japan and one from = Vmware. Dan: If you ask for an opinion=E2=80=A6I believe the last state change = is better. A time filter is more resource heavy. It moves the problem to = the agent, but I do not believe it is an issue. George from jabber: Amed =E2=80=93 does it make sense to have threshold = flags in the mib to indicate that there is something going on in that = tree? Chris: slide 3, previous presentation. =E2=80=A6 How about you guys take = it offline/mailing list. Dan: The question is whether it is worth the pain, pointing to an OID. J: We want to now if a vm is migrated, how or when. The question is do = we need to go from the entitymib and stick it in there, or =E2=80=A6 Adrian: is the cpu feature a free-form string? At least there ought to = be a common subset. Will IANA standardize these? Should there be common = ones called out, and if vendor-specific we should handle those too. Kireeti: I was wondering why we there're different tables. If someone = wants to move a physical machine into the cloud, you want to handle = that. What ever features you put here are interesting for the physical = machine and another for the virtual. Its more interesting if you can use = the same table for both types of machines. J: I agree we should represent a machine in the same way, but where it = shows up is different. Chris L: as far as cpu characteristics you called out speed. That is as = important as things like power state and # of threads. I'm thinking of = this as allowing someone to drive a migration and wondering if that = station has left the station and how many people will use a mIB for = that. Something like Openstack or virtual center change their interal = workings change their products to use this. You might want to ask the = folks doing that if they want to use this. J: The goal of this is to provide another interface for debugging and = monitoring. That data may already exist in another environment. I am = not sure. Ron Bonica: normally when we write a mIB, there is a normative = reference. Do you intent on a reference? J: Its not critical to have a reference for a MIB. Entity MIB, etc=E2=80=A6= don't have one. Ron Bonica: opinions of the room? Dan R: my opinion/experience what you describe is true for specific = protocols. You can provide some examples where there is no reference. = We modeled. Ron Bonica: Bradner: A reference to a vmware technical document makes sense too. Kireeti: You need to write a virtual MIB. What you just said made = sense: people use SNMP so someone has to write it. I also think it = would be good to have a common model (I.E. net mod). J: This is really for monitoring and troubleshooting. SNMP is good for = that. It is read-only. Benoit: There is a good point in what you said. Last year ops has = several protocols. What do we use with operational data in a yang = model? There is a bigger question of operational data related to a yang = model. This should give a clear signal to all areas in the IETF. Kireeti: If you are saying legacy is forcing you to write a mib because = of newer technology, you will never use the newer technology to manage = that. J: For some things snmp is more efficient, and others netconf. ?: we need to separate which protocol and data model we are using. 4) draft-fan-opsawg-transmission-interruption Sharam: is anything less than 50ms an issue? Wes George: 150ms is the lower limit of human perception. Chris L: 150ms at the bottom end, probably higher, the GSM phones we = have give us a different expectation for quality. This work is = interesting in that its trying to figure out what delay applications can = tolerate. Kireeti: there are 2 things going on. The services, do they need 50 ms? = I'd agree with you that we're maybe a little strict. But if IP is my = underlying infrastructure, and I have an outage, how much damage am I = really doing? You made a comment that I don't like: IP is unstable. If = you never converge, IP will never converge. But the underlying = infrastructure needs to be really stable. George Swallow: I wanted to make correction =E2=80=93 the SONET spec has = 50ms set because they were still interfacing with the tdm system that = took quite a while to switch over. So they had to get sonnet way down to = meet the total allotment. Humans can tolerate 100-200ms. Chair: We are running late, so can we take this to the list? Adrian Farrel: There eis a lot of use in this work to understand what = apps actually need but I want to distinguish between "some apps need = 50ms" and others don't. The OAM we build needs to support 50ms = regardless of what the other applications need. We have had requirements = imposed on us from other SDOs like rfc5654. But unless we have a long = list of apps and none of them needs 50 ms, we might not be able to = influence what goes on in the network. Jeff Haas: The motivation of this doc seems to be saying 50ms isn't = important, as have apps that demonstrate that. When you build devices = what seems to set your expectations. For example, financial apps need = less than 50ms. Rather that having a doc that sets the tolerances, let = the applications set their tolerances. : the motivation here is based on information from a deployed = backhaul network. If we built an MPLS TE network the cost can be much = higher. Our analysts say that not all services need 50ms of outtage = time. So we can get more performance from different IETF WGs. Wes George: 50ms is a crutch. Somewhere we decided that is a = requirement. So we build networks with this requirement. Somewhere you = get diminishing returns based on building a network for that = requirement. We need a different discussion forum that provides guidance = for new applications. There are apps that will need less than 50 ms = (financials), but that doesn't mean that eveyr network needs to support = this (its a boiler plate requirement in most specs now). Speaker: we want to do some investigation to list some examples.= From dromasca@avaya.com Sun Sep 9 01:49:47 2012 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 3448B21F8499 for ; Sun, 9 Sep 2012 01:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.787 X-Spam-Level: X-Spam-Status: No, score=-101.787 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+aX8gpG-0f5 for ; Sun, 9 Sep 2012 01:49:46 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC2321F84D5 for ; Sun, 9 Sep 2012 01:49:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAO1XTFDGmAcF/2dsb2JhbABFu1N3EIIgAQEBAQMBAQEPHgo0CwwEAgEIDQQEAQELBgwLAQYBJh8JCAEBBAESCBqHbgudVpt9BIsThVZgA5teihyCaA X-IronPort-AV: E=Sophos;i="4.80,394,1344225600"; d="scan'208";a="26047156" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 Sep 2012 04:43:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Sep 2012 04:42:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Sep 2012 10:49:20 +0200 Message-ID: In-Reply-To: <504AB082.2050601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] IETF 85 Thread-Index: Ac2Na5FQG6MDraeIQM2cYUhcBvIAmwA+qd9g References: <504AB082.2050601@gmail.com> From: "Romascanu, Dan (Dan)" To: "Melinda Shore" , Cc: Edward Beili Subject: Re: [OPSAWG] IETF 85 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, 09 Sep 2012 08:49:47 -0000 Hi Melinda,=20 Ed Beili and a few other authors plan to submit two documents - one related that updates RFC 5066, the second that documents the process of transition of the Ethernet MIBs to IEEE 802.3. Pending on the final advice from the ADs we will probably ask to do this work in the OPSAWG. When the I-Ds are submitted we will the let the OPSAWG know, and start the discussion on the mailing list.=20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Saturday, September 08, 2012 5:42 AM > To: opsawg@ietf.org > Subject: [OPSAWG] IETF 85 >=20 > It's time to start thinking about IETF 85. If you're working on > something that you think should be discussed at the meeting, *now* is > the time to get your draft published and start a discussion on the > mailing list. >=20 > Thanks, >=20 > Melinda > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From sheppyreno@gmail.com Tue Sep 11 08:48:59 2012 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 8810F21F87AB for ; Tue, 11 Sep 2012 08:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I14DnSfmHNg9 for ; Tue, 11 Sep 2012 08:48:59 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7928921F87A8 for ; Tue, 11 Sep 2012 08:48:58 -0700 (PDT) Received: by lbky2 with SMTP id y2so538166lbk.31 for ; Tue, 11 Sep 2012 08:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YsDmPEIvlhSWPwdXJN4AaOV4jkqNFmxiIF7d3ZxlfFc=; b=pbuxwB7TxCh1s6mxh6yj278zpLq6h3rnPQ45YYy5f296aGEOJGJLh+CLVn8IWnSbsT BzbgQwrH2/MTUUFw9ae6/ucK40SPwlSfiWNHXEbb+f7K/ax+ajbvfUp/JRfpEhJHVEfK Au/Jl04FzTedZdE5EjVFDmO54vxyjdU5Digys76XXk7Xfnr6602xbgjwMaoZ8Uza9s4k Ro7E52xWJlqHPUtXDTVCGRVOTkAW6CHHRYJN7pyFQ/fvLnhoMEGdamvVW8ELJUHOJqWX xQcwBK2cOw8NoP9pHp5hIFXbnJZfljhM3EntVNhPuFRqIGjSubOAHdDAKs2LzTnXNqBL p1gQ== MIME-Version: 1.0 Received: by 10.112.86.169 with SMTP id q9mr2106631lbz.65.1347378537440; Tue, 11 Sep 2012 08:48:57 -0700 (PDT) Received: by 10.112.87.231 with HTTP; Tue, 11 Sep 2012 08:48:57 -0700 (PDT) Date: Tue, 11 Sep 2012 11:48:57 -0400 Message-ID: From: Sheppy Reno To: opsawg@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fae91a244704c96f0362 Subject: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 15:48:59 -0000 --f46d0401fae91a244704c96f0362 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable After working with SNMP for quite a while we=92ve repeatedly run into issue= s where monitoring software is unable to accurately determine the utilization of volumes on some Linux partitions due to regular processes being unable to access the reserved file space. I believe that the best way to correct this issue is to include an additional data point in the Host Resources MIB (RFC2790) that will return available space. This should have no negative impact on systems that do not utilization reserved space, but will allow for a much more accurate picture of the space that is truly available on those partitions using reserved space. I=92ve been reading through the IETF site a bit, but I=92m still not sure a= s to the best process to get this implemented. I was hoping someone on here could give me some tips on proceeding with this. From what I can see, I just need to update RFC2790 with the below information and resubmit. RFC 2790 Add: hrStorageAvail OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION =93The amount of the storage represented by this entry that is available to non-superusers, in units of hrStorageAllocationUnits.=94 ::=3D { hrStorageEntry 8 } Thanks, Sheppy Reno --f46d0401fae91a244704c96f0362 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

After working with SNMP for quite a while we=92ve repeated= ly run into issues where monitoring software is unable to accurately determ= ine the utilization of volumes on some Linux partitions due to regular proc= esses being unable to access the reserved file space.=A0 I believe that the best way to correct this issue is to include an additio= nal data point in the Host Resources MIB (RFC2790) that will return availab= le space.=A0 This should have no negative impact on syst= ems that do not utilization reserved space, but will allow for a much more = accurate picture of the space that is truly available on those partitions u= sing reserved space.=A0

=A0

I=92ve been reading through the IETF site a bit, but I=92m= still not sure as to the best process to get this implemented.= =A0 I was hoping someone on here could give me some tips on proceedi= ng with this.=A0 From what I can see, I just need to upd= ate RFC2790 with the below information and resubmit.=A0 =

=A0

RFC 2790

=A0

Add:

=A0

hrStorageAvail OBJECT-TYPE

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = SYNTAX=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Integer32 (0..2147483647)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = MAX-ACCESS=A0=A0=A0=A0 read-only

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = STATUS=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 current

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = DESCRIPTION

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =93The amount of th= e storage represented by this entry

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 that is available t= o non-superusers, in units of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hrStorageAllocation= Units.=94

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ::=3D { hrStorageEntry 8 }

=A0

=A0

Thanks,

Sheppy Reno

--f46d0401fae91a244704c96f0362-- From melinda.shore@gmail.com Tue Sep 11 08:57:19 2012 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 B903021F87D8 for ; Tue, 11 Sep 2012 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCru1S8eg7lV for ; Tue, 11 Sep 2012 08:57:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 413EB21F85EA for ; Tue, 11 Sep 2012 08:57:19 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1172817obb.31 for ; Tue, 11 Sep 2012 08:57:18 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=ZNJwhoQ8rJFMBmDmRogQoGbTEcc4VFDK5GIDewNQ+7Q=; b=doP81gq00IpAOwFNaWGSTnX6K0iaLyUoHQ6OxZrDHfkXJTQMJGpzn5D8XkQ/zfgSzE jQSA+ZmWoSuYKa79Y59I+eLLeGbZAj+y9+nwr+EulraLLdQocKHjifrc+2H/J113I9Ue RRCMOG7sutYfuMxfPZP03mK3YCpgPjr7h1g6KXN5G0MfsmlF4/f34Zb3Yt3OsYeoGmI5 OvP+hlsCsZ5cl/hnhv7hPdsBKR+q9fptLPzRSr9Hw8kGdJSwNcC5ObbNx245aoaTugMc VRcdhsOsx0zF9cDT68HfwF/Kw6bTUsrFYHrvlnTe1W/mETJ4ULmxvt4F2edYllaP9JLV LpXA== Received: by 10.182.44.74 with SMTP id c10mr19001238obm.29.1347379038930; Tue, 11 Sep 2012 08:57:18 -0700 (PDT) Received: from spandex.local (66-230-80-245-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.80.245]) by mx.google.com with ESMTPS id k3sm16629363obw.4.2012.09.11.08.57.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Sep 2012 08:57:18 -0700 (PDT) Message-ID: <504F5F5C.9020706@gmail.com> Date: Tue, 11 Sep 2012 07:57:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sheppyreno@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 15:57:19 -0000 On 9/11/12 7:48 AM, Sheppy Reno wrote: > I’ve been reading through the IETF site a bit, but I’m still not sure as > to the best process to get this implemented. I was hoping someone on > here could give me some tips on proceeding with this. From what I can > see, I just need to update RFC2790 with the below information and > resubmit. Probably the best approach would be to write up your proposal in the form of an internet draft describing the problem you're encountering, your proposal, and the rationale for your proposal. Melinda From sheppyreno@gmail.com Tue Sep 11 09:15:07 2012 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 15EA621F8703 for ; Tue, 11 Sep 2012 09:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gClF+i4OD2-v for ; Tue, 11 Sep 2012 09:15:06 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE27D21F8535 for ; Tue, 11 Sep 2012 09:15:05 -0700 (PDT) Received: by lahm15 with SMTP id m15so506999lah.31 for ; Tue, 11 Sep 2012 09:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LdeaOASTWM7i1lDd1cT6wVh3o5SciU+UMm0h7WfVhg0=; b=QH3wpxBvgIa9yoqJCK/zR0ou4fAADxG9xaq5K604LLDjTJOdJqO4rNkvw4QMJL8rUR syDPcAFWeBw98fL/5j45VmsP/zjKUqwlu+aUTKqQ3s6VigNwk4mk2bdKcHJ+gDIJf7EZ BwWPEYI4Z0ucnI58VTs/5JUcd1OZOAw6Bnc1HBEqc4FqgvLEV3rBVqzZSASIqAckQnUJ aODirZqyoCP28QJLb9kQCeb8uJXr7Hz7YxNnn+OSjfyPdXitu3JgRXDXo/2gEZgv4Vyi QfJo/O7ELr4rI3NL6COqFAcxqI83HuWZNj1QNcRUbxxgydiEOQZsWfHYQNxq6xOdRsTq eveQ== MIME-Version: 1.0 Received: by 10.152.147.72 with SMTP id ti8mr16366203lab.20.1347380104824; Tue, 11 Sep 2012 09:15:04 -0700 (PDT) Received: by 10.112.87.231 with HTTP; Tue, 11 Sep 2012 09:15:04 -0700 (PDT) In-Reply-To: <504F5F5C.9020706@gmail.com> References: <504F5F5C.9020706@gmail.com> Date: Tue, 11 Sep 2012 12:15:04 -0400 Message-ID: From: Sheppy Reno To: Melinda Shore Content-Type: multipart/alternative; boundary=e89a8f22be0786873b04c96f600e Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 16:15:07 -0000 --e89a8f22be0786873b04c96f600e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore wr= ote: > On 9/11/12 7:48 AM, Sheppy Reno wrote: > > I=92ve been reading through the IETF site a bit, but I=92m still not su= re as > > to the best process to get this implemented. I was hoping someone on > > here could give me some tips on proceeding with this. From what I can > > see, I just need to update RFC2790 with the below information and > > resubmit. > > Probably the best approach would be to write up your proposal in the > form of an internet draft describing the problem you're encountering, > your proposal, and the rationale for your proposal. > Melinda > Melinda, Thanks for the prompt response. My issues arise from not knowing how to properly submit this as an internet draft. http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared towards new drafts than to updates for current RFCs. From the information on that page I would assume that the proper way to proceed would be to modify RFC2790, add in the Internet Draft comments in the header, remove anything mentioning RFC, etc. I'm just worried because this seems like a counterintuitive approach to submitting a modification. Is there a process by which I just submit the changes instead of rebuilding the entire RFC this is based on? I don't mind doing the extra work if a complete rewrite of the original RFC is required, but I want to make sure I'm making the submission properly. Thanks, Sheppy --e89a8f22be0786873b04c96f600e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore = <melinda.shore@gmail.com> wrote:
On 9/11/12 7:48 AM, Sheppy Reno wrote:
> I=92ve bee= n reading through the IETF site a bit, but I=92m still not sure as
> = to the best process to get this implemented. =A0I was hoping someone on
= > here could give me some tips on proceeding with this. =A0From what I c= an
> see, I just need to update RFC2790 with the below information and
&= gt; resubmit.

Probably the best approach would be to write up = your proposal in the
form of an internet draft describing the problem yo= u're encountering,
your proposal, and the rationale for your proposal.
Melinda
=A0
=A0
Melinda,
Thanks for the prompt response.=A0 My issues arise from no= t knowing how to properly submit this as an internet draft.=A0 http://www.ietf.org/ietf-f= tp/1id-guidelines.html seems to be more geared towards new drafts than = to updates for current RFCs.=A0 From the information on that page I would a= ssume that the proper way to proceed would be to modify RFC2790, add in the= Internet Draft comments in the header, remove anything mentioning RFC, etc= .=A0 I'm just worried because this seems like a counterintuitive approa= ch to submitting a modification.
=A0
Is there a process by which I just submit the changes instead of reb= uilding the entire RFC this is based on?=A0 I don't mind doing the extr= a work if a complete rewrite of the original RFC is required, but I want to= make sure I'm making the submission properly.
Thanks,
Sheppy

--e89a8f22be0786873b04c96f600e-- From ietfc@btconnect.com Tue Sep 11 10:19:41 2012 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 C874621F87A5 for ; Tue, 11 Sep 2012 10:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.335 X-Spam-Level: X-Spam-Status: No, score=-3.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzwWWA8OJlJW for ; Tue, 11 Sep 2012 10:19:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 168AD21F869C for ; Tue, 11 Sep 2012 10:19:40 -0700 (PDT) Received: from mail207-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 11 Sep 2012 17:19:39 +0000 Received: from mail207-ch1 (localhost [127.0.0.1]) by mail207-ch1-R.bigfish.com (Postfix) with ESMTP id 7333446007E; Tue, 11 Sep 2012 17:19:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zzbb2dI98dI9371I542M1432I4015I1447I99a6mzz1202h1d1ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail207-ch1 (localhost.localdomain [127.0.0.1]) by mail207-ch1 (MessageSwitch) id 134738397888836_11015; Tue, 11 Sep 2012 17:19:38 +0000 (UTC) Received: from CH1EHSMHS017.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail207-ch1.bigfish.com (Postfix) with ESMTP id 08DB5400050; Tue, 11 Sep 2012 17:19:38 +0000 (UTC) Received: from AM2PRD0710HT005.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS017.bigfish.com (10.43.70.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 11 Sep 2012 17:19:37 +0000 Received: from BL2PRD0410HT001.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.255.165.40) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 11 Sep 2012 17:19:28 +0000 Message-ID: <00ce01cd9041$b1054900$4001a8c0@gateway.2wire.net> From: t.petch To: Sheppy Reno , Melinda Shore References: <504F5F5C.9020706@gmail.com> Date: Tue, 11 Sep 2012 18:12:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.240.85] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 17:19:41 -0000 Sheppy You should look too at RFC4181 which gives the current guidelines for writing a MIB module, which is what you would, de facto, be doing. The practice has moved on and this RFC will give you some idea of what would be involved in making even a one word change to a MIB module from an earlier time:-( Tom Petch ----- Original Message ----- From: "Sheppy Reno" To: "Melinda Shore" Cc: Sent: Tuesday, September 11, 2012 5:15 PM Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore wrote: > On 9/11/12 7:48 AM, Sheppy Reno wrote: > > I=92ve been reading through the IETF site a bit, but I=92m still not sure as > > to the best process to get this implemented. I was hoping someone on > > here could give me some tips on proceeding with this. From what I can > > see, I just need to update RFC2790 with the below information and > > resubmit. > > Probably the best approach would be to write up your proposal in the > form of an internet draft describing the problem you're encountering, > your proposal, and the rationale for your proposal. > Melinda > Melinda, Thanks for the prompt response. My issues arise from not knowing how to properly submit this as an internet draft. http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared towards new drafts than to updates for current RFCs. From the information on that page I would assume that the proper way to proceed would be to modify RFC2790, add in the Internet Draft comments in the header, remove anything mentioning RFC, etc. I'm just worried because this seems like a counterintuitive approach to submitting a modification. Is there a process by which I just submit the changes instead of rebuilding the entire RFC this is based on? I don't mind doing the extra work if a complete rewrite of the original RFC is required, but I want to make sure I'm making the submission properly. Thanks, Sheppy ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From simon.perreault@viagenie.ca Tue Sep 11 10:35:03 2012 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 DCB8B21F87A8 for ; Tue, 11 Sep 2012 10:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJRqy7SyYKe4 for ; Tue, 11 Sep 2012 10:35:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 51B6321F8773 for ; Tue, 11 Sep 2012 10:35:03 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:1d7c:5db4:d43e:122c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AAF7145BCC for ; Tue, 11 Sep 2012 13:35:01 -0400 (EDT) Message-ID: <504F7645.4010502@viagenie.ca> Date: Tue, 11 Sep 2012 13:35:01 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <504F5F5C.9020706@gmail.com> <00ce01cd9041$b1054900$4001a8c0@gateway.2wire.net> In-Reply-To: <00ce01cd9041$b1054900$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 17:35:04 -0000 Le 2012-09-11 13:12, t.petch a écrit : > You should look too at RFC4181 which gives the current guidelines for > writing a MIB module, which is what you would, de facto, be doing. The > practice has moved on and this RFC will give you some idea of what would > be involved in making even a one word change to a MIB module from an > earlier time:-( Is it really necessary to do a bis document just for adding a single OID? Why not just define the new OID by itself and refer to the existing RFC? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From ietfdbh@comcast.net Tue Sep 11 12:30:34 2012 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 4B9E021F8668 for ; Tue, 11 Sep 2012 12:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.436 X-Spam-Level: X-Spam-Status: No, score=-100.436 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP2x10xy0IlP for ; Tue, 11 Sep 2012 12:30:32 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id E05FA21F86B3 for ; Tue, 11 Sep 2012 12:30:31 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id xuoH1j0060Fqzac5DvWVZR; Tue, 11 Sep 2012 19:30:29 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta08.westchester.pa.mail.comcast.net with comcast id xvWL1j00J3Ecudz3UvWLob; Tue, 11 Sep 2012 19:30:21 +0000 From: "ietfdbh" To: "'Sheppy Reno'" References: <504F5F5C.9020706@gmail.com> In-Reply-To: Date: Tue, 11 Sep 2012 15:30:22 -0400 Message-ID: <064901cd9053$e32bb470$a9831d50$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_064A_01CD9032.5C1DBDF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8MFqTQBbCnnHmM8QmwG426WXmkQJkLAfCAyGpG5KYe+du4A== Content-Language: en-us Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 19:30:34 -0000 This is a multipart message in MIME format. ------=_NextPart_000_064A_01CD9032.5C1DBDF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sheppy, Updating a standard is a fairly difficult task. This is deliberate; If standards were constantly changing, it would be hard to get consistent implementations across products. The IETF would need to publish a new RFC to obsolete the existing RFC. Before they would do this, the IESG (standards approval committee) would need to verify that the change to the standard represented IETF consensus. So any proposed change would need to be discussed by the IETF community before being accepted. There are likely other changes people would like, so changing the standard would likely include a number of changes, all of which would need IETF community consensus. Updating a standard MIB is a slightly more difficult task than normal. MIB modules contain compliance statements to ensure/encourage interoperability across implementations. There are specific rules about how to update a MIB so that existing compliant implementations do not become non-compliant. That's why writing up a proposal is important - so the IETF can read/study your proposal in detail. A simpler approach would be to write a new MIB module that could be implemented in addition to the standard, without updating the standard MIB module. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Sheppy Reno Sent: Tuesday, September 11, 2012 12:15 PM To: Melinda Shore Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore wrote: On 9/11/12 7:48 AM, Sheppy Reno wrote: > I've been reading through the IETF site a bit, but I'm still not sure as > to the best process to get this implemented. I was hoping someone on > here could give me some tips on proceeding with this. From what I can > see, I just need to update RFC2790 with the below information and > resubmit. Probably the best approach would be to write up your proposal in the form of an internet draft describing the problem you're encountering, your proposal, and the rationale for your proposal. Melinda Melinda, Thanks for the prompt response. My issues arise from not knowing how to properly submit this as an internet draft. http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared towards new drafts than to updates for current RFCs. From the information on that page I would assume that the proper way to proceed would be to modify RFC2790, add in the Internet Draft comments in the header, remove anything mentioning RFC, etc. I'm just worried because this seems like a counterintuitive approach to submitting a modification. Is there a process by which I just submit the changes instead of rebuilding the entire RFC this is based on? I don't mind doing the extra work if a complete rewrite of the original RFC is required, but I want to make sure I'm making the submission properly. Thanks, Sheppy ------=_NextPart_000_064A_01CD9032.5C1DBDF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sheppy,

 

Updating a standard is a fairly difficult task. =

This is deliberate; If standards were constantly changing, it would = be hard to get consistent implementations across = products.

 

The IETF would need to publish a new RFC to obsolete the existing = RFC.

Before they would do this, the IESG (standards approval committee) = would need to verify that the change to the standard represented IETF = consensus.

So any proposed change would need to be discussed by the IETF = community before being accepted.

There are likely other changes people would like, so changing the = standard would likely include a number of changes, all of which would = need IETF community consensus.

 

 

Updating a standard MIB is a slightly more difficult task than = normal.

MIB modules contain compliance statements to ensure/encourage = interoperability across implementations.

There are specific rules about how to update a MIB so that existing = compliant implementations do not become = non-compliant.

 

That’s why writing up a proposal is important – so the = IETF can read/study your proposal in detail.

 

A simpler approach would be to write a new MIB module that could be = implemented in addition to the standard, without updating the standard = MIB module.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of = Sheppy Reno
Sent: Tuesday, September 11, 2012 12:15 = PM
To: Melinda Shore
Cc: = opsawg@ietf.org
Subject: Re: [OPSAWG] Addition of Available = Space to Host-Resources-MIB

 

 

On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore <melinda.shore@gmail.com> = wrote:

On 9/11/12 7:48 AM, Sheppy Reno = wrote:
> I’ve been reading through the IETF site a bit, but = I’m still not sure as
> to the best process to get this = implemented.  I was hoping someone on
> here could give me = some tips on proceeding with this.  From what I can
> see, I = just need to update RFC2790 with the below information and
> = resubmit.

Probably the best = approach would be to write up your proposal in the
form of an = internet draft describing the problem you're encountering,
your = proposal, and the rationale for your proposal.
Melinda

 

 

Melinda,
Thanks for the prompt response.  My = issues arise from not knowing how to properly submit this as an internet = draft.  http://www.ietf= .org/ietf-ftp/1id-guidelines.html seems to be more geared towards = new drafts than to updates for current RFCs.  From the information = on that page I would assume that the proper way to proceed would be to = modify RFC2790, add in the Internet Draft comments in the header, remove = anything mentioning RFC, etc.  I'm just worried because this seems = like a counterintuitive approach to submitting a = modification.
 
Is there a process by which I just submit the = changes instead of rebuilding the entire RFC this is based on?  I = don't mind doing the extra work if a complete rewrite of the original = RFC is required, but I want to make sure I'm making the submission = properly.
Thanks,
Sheppy

 

------=_NextPart_000_064A_01CD9032.5C1DBDF0-- From randy_presuhn@mindspring.com Tue Sep 11 13:10:38 2012 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 14E0521F874A for ; Tue, 11 Sep 2012 13:10:38 -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_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ot1RgpZB4oiX for ; Tue, 11 Sep 2012 13:10:37 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5D621F86B1 for ; Tue, 11 Sep 2012 13:10:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=tQalPlLk213Zjb12M5DkoPMH+FESGWAEvIGMYLStEtiOwCTvWnGVAABA9MAZx8KH; 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.33.94.36] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TBWn6-0006RQ-Nt; Tue, 11 Sep 2012 16:10:37 -0400 Message-ID: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Tue, 11 Sep 2012 13:17:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1ca57203a9ae4d59c8c41aec187d99ac6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.33.94.36 Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 11 Sep 2012 20:10:38 -0000 Hi - To make what the other folks have been saying more concrete: Submit an internet draft. The draft would contain a MIB module. That MIB module would contain two definitions. The first would be for a "conceptual row" containing a single object (which you defined as "hrStorageAvail" below) with an AUGMENTS clause referring to the base conceptual row in the Host Resources MIB. The second would be the definition you proposed below. Including boilerplate and your explanation of the rationale, the whole thing should weigh in at about seven pages. Randy ----- Original Message ----- From: "Sheppy Reno" To: Sent: Tuesday, September 11, 2012 8:48 AM Subject: [OPSAWG] Addition of Available Space to Host-Resources-MIB After working with SNMP for quite a while we’ve repeatedly run into issues where monitoring software is unable to accurately determine the utilization of volumes on some Linux partitions due to regular processes being unable to access the reserved file space. I believe that the best way to correct this issue is to include an additional data point in the Host Resources MIB (RFC2790) that will return available space. This should have no negative impact on systems that do not utilization reserved space, but will allow for a much more accurate picture of the space that is truly available on those partitions using reserved space. I’ve been reading through the IETF site a bit, but I’m still not sure as to the best process to get this implemented. I was hoping someone on here could give me some tips on proceeding with this. From what I can see, I just need to update RFC2790 with the below information and resubmit. RFC 2790 Add: hrStorageAvail OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION “The amount of the storage represented by this entry that is available to non-superusers, in units of hrStorageAllocationUnits.” ::= { hrStorageEntry 8 } Thanks, Sheppy Reno -------------------------------------------------------------------------------- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From dromasca@avaya.com Wed Sep 12 01:41:14 2012 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 B6CB321F8568 for ; Wed, 12 Sep 2012 01:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk4L42PkZu3k for ; Wed, 12 Sep 2012 01:41:12 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id D3F6921F8564 for ; Wed, 12 Sep 2012 01:41:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwHAOxJUFDGmAcF/2dsb2JhbABCA4JLhhuwJYJAgQeCIAEBAQEDEgoRA0kQAgEIDQQEAQEBCgYMCwEGASAlCQgCBAESCAELDodcAwwLnl+TYAgFiVOKLWODHoJEYAOIIItpAYdWhRSFCoEugTo X-IronPort-AV: E=Sophos;i="4.80,409,1344225600"; d="scan'208,217";a="26490325" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Sep 2012 04:35:29 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Sep 2012 04:34:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD90C2.5AD815FD" Date: Wed, 12 Sep 2012 10:41:06 +0200 Message-ID: In-Reply-To: <064901cd9053$e32bb470$a9831d50$@comcast.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Addition of Available Space to Host-Resources-MIB Thread-Index: AQE8MFqTQBbCnnHmM8QmwG426WXmkQJkLAfCAyGpG5KYe+du4IABDTLQ References: <504F5F5C.9020706@gmail.com> <064901cd9053$e32bb470$a9831d50$@comcast.net> From: "Romascanu, Dan (Dan)" To: "ietfdbh" , "Sheppy Reno" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 08:41:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD90C2.5AD815FD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with the suggestions made by David and Randy. =20 My only observation would be to:=20 =20 =D8 A simpler approach would be to write a new MIB module that could be = implemented in addition to the standard, without updating the standard = MIB module. =20 =20 Actually I believe that in RFC terminology the new RFC including the = incremental MIB module (if approved) will update RFC 2790, but will not = obsolete it.=20 =20 Dan =20 =20 =20 =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of ietfdbh Sent: Tuesday, September 11, 2012 10:30 PM To: 'Sheppy Reno' Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB =20 Hi Sheppy, =20 Updating a standard is a fairly difficult task.=20 This is deliberate; If standards were constantly changing, it would be = hard to get consistent implementations across products. =20 The IETF would need to publish a new RFC to obsolete the existing RFC. Before they would do this, the IESG (standards approval committee) would = need to verify that the change to the standard represented IETF = consensus. So any proposed change would need to be discussed by the IETF community = before being accepted. There are likely other changes people would like, so changing the = standard would likely include a number of changes, all of which would = need IETF community consensus. =20 =20 Updating a standard MIB is a slightly more difficult task than normal. MIB modules contain compliance statements to ensure/encourage = interoperability across implementations. There are specific rules about how to update a MIB so that existing = compliant implementations do not become non-compliant. =20 That's why writing up a proposal is important - so the IETF can = read/study your proposal in detail. =20 A simpler approach would be to write a new MIB module that could be = implemented in addition to the standard, without updating the standard = MIB module. =20 David Harrington ietfdbh@comcast.net =20 +1-603-828-1401 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of Sheppy Reno Sent: Tuesday, September 11, 2012 12:15 PM To: Melinda Shore Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB =20 =20 On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore = wrote: On 9/11/12 7:48 AM, Sheppy Reno wrote: > I've been reading through the IETF site a bit, but I'm still not sure = as > to the best process to get this implemented. I was hoping someone on > here could give me some tips on proceeding with this. From what I can > see, I just need to update RFC2790 with the below information and > resubmit. Probably the best approach would be to write up your proposal in the form of an internet draft describing the problem you're encountering, your proposal, and the rationale for your proposal. Melinda =20 =20 Melinda, Thanks for the prompt response. My issues arise from not knowing how to = properly submit this as an internet draft. = http://www.ietf.org/ietf-ftp/1id-guidelines.html seems to be more geared = towards new drafts than to updates for current RFCs. From the = information on that page I would assume that the proper way to proceed = would be to modify RFC2790, add in the Internet Draft comments in the = header, remove anything mentioning RFC, etc. I'm just worried because = this seems like a counterintuitive approach to submitting a = modification. =20 Is there a process by which I just submit the changes instead of = rebuilding the entire RFC this is based on? I don't mind doing the = extra work if a complete rewrite of the original RFC is required, but I = want to make sure I'm making the submission properly. Thanks, Sheppy=20 =20 ------_=_NextPart_001_01CD90C2.5AD815FD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with the suggestions made by David and = Randy.

 

My only observation would be to:

 

=D8  A simpler approach would be to write a new MIB module that could be = implemented in addition to the standard, without updating the standard = MIB module.

 

 

Actually I believe that in RFC terminology the new RFC including the = incremental MIB module (if approved) will update RFC 2790, but will not = obsolete it.

 

Dan

 

 

 

 

From:= = opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of = ietfdbh
Sent: Tuesday, September 11, 2012 10:30 = PM
To: 'Sheppy Reno'
Cc: = opsawg@ietf.org
Subject: Re: [OPSAWG] Addition of Available = Space to Host-Resources-MIB

 

Hi Sheppy,

 

Updating a standard is a fairly difficult task. =

This is deliberate; If standards were constantly changing, it would = be hard to get consistent implementations across = products.

 

The IETF would need to publish a new RFC to obsolete the existing = RFC.

Before they would do this, the IESG (standards approval committee) = would need to verify that the change to the standard represented IETF = consensus.

So any proposed change would need to be discussed by the IETF = community before being accepted.

There are likely other changes people would like, so changing the = standard would likely include a number of changes, all of which would = need IETF community consensus.

 

 

Updating a standard MIB is a slightly more difficult task than = normal.

MIB modules contain compliance statements to ensure/encourage = interoperability across implementations.

There are specific rules about how to update a MIB so that existing = compliant implementations do not become = non-compliant.

 

That’s why writing up a proposal is important – so the = IETF can read/study your proposal in detail.

 

A simpler approach would be to write a new MIB module that could be = implemented in addition to the standard, without updating the standard = MIB module.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = opsawg-bounces@ietf.org = [mailto:opsawg-bounces@ietf.org] On Behalf Of Sheppy Reno
Sent: Tuesday, September = 11, 2012 12:15 PM
To: Melinda Shore
Cc: opsawg@ietf.org
Subject: = Re: [OPSAWG] Addition of Available Space to = Host-Resources-MIB

 

 

On Tue, Sep 11, 2012 at 11:57 AM, Melinda Shore <melinda.shore@gmail.com> = wrote:

On 9/11/12 7:48 AM, Sheppy Reno = wrote:
> I’ve been reading through the IETF site a bit, but = I’m still not sure as
> to the best process to get this = implemented.  I was hoping someone on
> here could give me = some tips on proceeding with this.  From what I can
> see, I = just need to update RFC2790 with the below information and
> = resubmit.

Probably the best = approach would be to write up your proposal in the
form of an = internet draft describing the problem you're encountering,
your = proposal, and the rationale for your proposal.
Melinda

 

 

Melinda,
Thanks for the prompt response.  My = issues arise from not knowing how to properly submit this as an internet = draft.  http://www.ietf= .org/ietf-ftp/1id-guidelines.html seems to be more geared towards = new drafts than to updates for current RFCs.  From the information = on that page I would assume that the proper way to proceed would be to = modify RFC2790, add in the Internet Draft comments in the header, remove = anything mentioning RFC, etc.  I'm just worried because this seems = like a counterintuitive approach to submitting a = modification.
 
Is there a process by which I just submit the = changes instead of rebuilding the entire RFC this is based on?  I = don't mind doing the extra work if a complete rewrite of the original = RFC is required, but I want to make sure I'm making the submission = properly.
Thanks,
Sheppy

 

------_=_NextPart_001_01CD90C2.5AD815FD-- From dromasca@avaya.com Wed Sep 12 01:46:45 2012 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 B159021F859A for ; Wed, 12 Sep 2012 01:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2n-w6Qaun0l for ; Wed, 12 Sep 2012 01:46:44 -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 49B1E21F8594 for ; Wed, 12 Sep 2012 01:46:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPlKUFDGmAcF/2dsb2JhbABFu0uBB4IgAQEBAQMBAQEPFQk+FwQCAQgNBAQBAQsGDAsBBgEmHwkIAQEEARIIGodrC55gnUCLEIViYAOIII5ThG2KHoJo X-IronPort-AV: E=Sophos;i="4.80,409,1344225600"; d="scan'208";a="366672546" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 12 Sep 2012 04:41:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Sep 2012 04:39:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Sep 2012 10:46:41 +0200 Message-ID: In-Reply-To: <504F7645.4010502@viagenie.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Addition of Available Space to Host-Resources-MIB Thread-Index: Ac2QQ8lnZ3tkY0bNSs2z8RL7MUBpbQAfrPrQ References: <504F5F5C.9020706@gmail.com><00ce01cd9041$b1054900$4001a8c0@gateway.2wire.net> <504F7645.4010502@viagenie.ca> From: "Romascanu, Dan (Dan)" To: "Simon Perreault" , Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 08:46:45 -0000 Hi Simon, According to SMI and MIB definition rules OIDs (actually I believe that = you meant new objects) can be defined only within MIB modules.=20 The proposal made by Randy does what you are suggesting following the = SMI MIB definition rules, by defining a minimal MIB module that augments = the existing MIB module defined in RFC 2790.=20 It's the minimal thing that I can think about, it still requires = defining a MIB module in an RFC.=20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf > Of Simon Perreault > Sent: Tuesday, September 11, 2012 8:35 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] Addition of Available Space to = Host-Resources-MIB >=20 > Le 2012-09-11 13:12, t.petch a =E9crit : > > You should look too at RFC4181 which gives the current guidelines = for > > writing a MIB module, which is what you would, de facto, be doing. > > The practice has moved on and this RFC will give you some idea of = what > > would be involved in making even a one word change to a MIB module > > from an earlier time:-( >=20 > Is it really necessary to do a bis document just for adding a single > OID? Why not just define the new OID by itself and refer to the = existing > RFC? >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From internet-drafts@ietf.org Wed Sep 12 01:55:34 2012 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 F228221F861E; Wed, 12 Sep 2012 01:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfTKGXjzUzaZ; Wed, 12 Sep 2012 01:55:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9421F861A; Wed, 12 Sep 2012 01:55:34 -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.34 Message-ID: <20120912085534.7059.22366.idtracker@ietfa.amsl.com> Date: Wed, 12 Sep 2012 01:55:34 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-oam-overview-07.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, 12 Sep 2012 08:55:35 -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 : An Overview of Operations, Administration, and Maintenan= ce (OAM) Mechanisms Author(s) : Tal Mizrahi Nurit Sprecher Elisa Bellagamba Yaacov Weingarten Filename : draft-ietf-opsawg-oam-overview-07.txt Pages : 28 Date : 2012-09-12 Abstract: Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset that can be used for fault detection and isolation, and for performance measurement. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-oam-overview There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-oam-overview-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed Sep 12 05:06:54 2012 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 A881221F8623 for ; Wed, 12 Sep 2012 05:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HkN-Qhj8wcm for ; Wed, 12 Sep 2012 05:06:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC021F8622 for ; Wed, 12 Sep 2012 05:06:54 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d41c:a6c5:d5dd:8e98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9659A40093; Wed, 12 Sep 2012 08:06:50 -0400 (EDT) Message-ID: <50507ADA.2070002@viagenie.ca> Date: Wed, 12 Sep 2012 08:06:50 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <504F5F5C.9020706@gmail.com><00ce01cd9041$b1054900$4001a8c0@gateway.2wire.net> <504F7645.4010502@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 12:06:54 -0000 Le 2012-09-12 04:46, Romascanu, Dan (Dan) a écrit : > According to SMI and MIB definition rules OIDs (actually I believe > that you meant new objects) can be defined only within MIB modules. > > The proposal made by Randy does what you are suggesting following the > SMI MIB definition rules, by defining a minimal MIB module that > augments the existing MIB module defined in RFC 2790. > > It's the minimal thing that I can think about, it still requires > defining a MIB module in an RFC. Thanks, that answers my question perfectly. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wjhns1@hardakers.net Wed Sep 12 09:30:02 2012 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 7CBAB21F8652 for ; Wed, 12 Sep 2012 09:30:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGcOoA3T4TnS for ; Wed, 12 Sep 2012 09:30:02 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCBF21F861E for ; Wed, 12 Sep 2012 09:30:02 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id DD9583F; Wed, 12 Sep 2012 09:30:01 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" In-Reply-To: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Tue, 11 Sep 2012 13:17:36 -0700") References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) Date: Wed, 12 Sep 2012 09:30:01 -0700 Message-ID: <0lr4q7gq5y.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 16:30:02 -0000 "Randy Presuhn" writes: > Submit an internet draft. The draft would contain a MIB module. > That MIB module would contain two definitions. The first would > be for a "conceptual row" containing a single object (which you > defined as "hrStorageAvail" below) with an AUGMENTS clause > referring to the base conceptual row in the Host Resources MIB. > The second would be the definition you proposed below. You know, I know that's the right approach. I've always known that. But... I've always hated it. I've always failed to see why we can't add a new column to an existing table, which is all that is needed. Simply republish the existing MIB with the new column. There are really only two downsides: 1) Badly written management code that is doing a full table walk and is not looking at the output careful to realize it should discard some things it doesn't care about being returned. I honestly don't know how much of this type of code exists in the world, where after the last column in a table it can't handle extra data. Maybe it's more than I'd like. 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually don't care about this too much. We (the IETF) has already admitted that we have issues with "levels". In reality, we need only the new parts to be PROPOSED and everything else remain DRAFT, but we can't do that without doing the augment-in-a-new-draft-thing, which is painful to the end user: IE, the people that matter. In netconf we now have the ability to augment in place (Yay!), but the output of netconf is less human readable in it's raw-ish form because of the namespace tag marking explosions (Boo!). Yes, I'm ranting about the known-failings of the SMI, which no matter how hard we try to move from it's still very very very important in the IETF world as new changes and new MIBs are being written constantly. But the failings of the SMI actually aren't the SMI at all, it's how we let ourselves use the SMI in publications "don't change it at all, even when it's safe to do so". [note that conformance statements aren't a problem, IMHO, you just need to add another and let the existing one remain. A device can still be conformant to the old conformance requirements.] -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From sheppyreno@gmail.com Wed Sep 12 09:38:15 2012 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 07EAF21F84AE for ; Wed, 12 Sep 2012 09:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2onmkzc3lMi for ; Wed, 12 Sep 2012 09:38:14 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88D6821F8512 for ; Wed, 12 Sep 2012 09:38:13 -0700 (PDT) Received: by lbky2 with SMTP id y2so1409322lbk.31 for ; Wed, 12 Sep 2012 09:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bLOplPFBl6EVfYp2ycL6vfYkoSoRghbgR2PYoQnl9Dg=; b=tE4zzS44W/X2VmWXHV5fUH11lkNbs0WTpjJPpM0V0ZDVpXP4iVFkXtvIUmzTvc37DQ TY2ec4hnXGElkMq1YryUpGz4kEvKY4tAJnVHgIc72O/LMuE8vRcgX0O0vW9rfivOfWim G6xOaKV3GtFLIj0gOBtYAh3fLkiIgh/wbUviiB59p5EoQE2P5lalR4tEObcNT7mnyCZh KimzGnTL5M3kfAw5iA8RqRW5OAdsIh5ICGFlr5vTZDTQN1ekJTo4jEaCDGxjV78nTOgG S8+P5RwBrJVLkeJdt1DlFxhLItkq9WDQXM88Ko1z28HJwZmEg5N7wAEeIYq1N1H+AlXf Z+UA== MIME-Version: 1.0 Received: by 10.152.131.68 with SMTP id ok4mr19700231lab.47.1347467892422; Wed, 12 Sep 2012 09:38:12 -0700 (PDT) Received: by 10.112.87.231 with HTTP; Wed, 12 Sep 2012 09:38:12 -0700 (PDT) In-Reply-To: <0lr4q7gq5y.fsf@wjh.hardakers.net> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0lr4q7gq5y.fsf@wjh.hardakers.net> Date: Wed, 12 Sep 2012 12:38:12 -0400 Message-ID: From: Sheppy Reno To: Wes Hardaker Content-Type: multipart/alternative; boundary=f46d0435c1d212f8eb04c983d181 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 16:38:15 -0000 --f46d0435c1d212f8eb04c983d181 Content-Type: text/plain; charset=ISO-8859-1 If I submit this as an AUGMENT would it still mean that hrStorageAvailable would appear grouped with the rest of the hrStorage table in an SNMP walk or would it be a completely separate MIB? I've read http://tools.ietf.org/html/rfc2578#page-29 quite a few times, but I can't say that its any clearer now than it was the first read through. On Wed, Sep 12, 2012 at 12:30 PM, Wes Hardaker wrote: > "Randy Presuhn" writes: > > > Submit an internet draft. The draft would contain a MIB module. > > That MIB module would contain two definitions. The first would > > be for a "conceptual row" containing a single object (which you > > defined as "hrStorageAvail" below) with an AUGMENTS clause > > referring to the base conceptual row in the Host Resources MIB. > > The second would be the definition you proposed below. > > > > You know, I know that's the right approach. I've always known that. > But... I've always hated it. > > I've always failed to see why we can't add a new column to an existing > table, which is all that is needed. Simply republish the existing MIB > with the new column. > > There are really only two downsides: > > 1) Badly written management code that is doing a full table walk and is > not looking at the output careful to realize it should discard some > things it doesn't care about being returned. I honestly don't know > how much of this type of code exists in the world, where after the > last column in a table it can't handle extra data. Maybe it's more > than I'd like. > > 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually > don't care about this too much. We (the IETF) has already admitted > that we have issues with "levels". In reality, we need only the new > parts to be PROPOSED and everything else remain DRAFT, but we can't > do that without doing the augment-in-a-new-draft-thing, which is > painful to the end user: IE, the people that matter. > > In netconf we now have the ability to augment in place (Yay!), but the > output of netconf is less human readable in it's raw-ish form because of > the namespace tag marking explosions (Boo!). > > Yes, I'm ranting about the known-failings of the SMI, which no matter > how hard we try to move from it's still very very very important in the > IETF world as new changes and new MIBs are being written constantly. > But the failings of the SMI actually aren't the SMI at all, it's how we > let ourselves use the SMI in publications "don't change it at all, even > when it's safe to do so". > > [note that conformance statements aren't a problem, IMHO, you just need > to add another and let the existing one remain. A device can still be > conformant to the old conformance requirements.] > > > > -- > Wes Hardaker > My Pictures: http://capturedonearth.com/ > My Thoughts: http://pontifications.hardakers.net/ > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --f46d0435c1d212f8eb04c983d181 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If I submit this as an AUGMENT would it still mean that hrStorageAvail= able would appear grouped with the rest of the hrStorage table in an SNMP w= alk or would it be a completely separate MIB?
=A0
I've read h= ttp://tools.ietf.org/html/rfc2578#page-29=A0quite a few times, but I ca= n't say that its any clearer now than it was the first read through.
On Wed, Sep 12, 2012 at 12:30 PM, Wes Hardaker <= span dir=3D"ltr"><wjhns1@hardakers.net> wrote:
"Randy Presuhn" <randy_presuhn@mindspring.com> writes:

&g= t; Submit an internet draft. =A0The draft would contain a MIB module.
&g= t; That MIB module would contain two definitions. =A0The first would
> be for a "conceptual row" containing a single object (which = you
> defined as "hrStorageAvail" below) with an AUGMENTS c= lause
> referring to the base conceptual row in the Host Resources MI= B.
> The second would be the definition you proposed below.

&l= t;rant-with-no-real-expectations-of-change>

You know, I know that= 's the right approach. =A0I've always known that.
But... =A0I= 9;ve always hated it.

I've always failed to see why we can't add a new column to an e= xisting
table, which is all that is needed. =A0Simply republish the exis= ting MIB
with the new column.

There are really only two downsides= :

1) Badly written management code that is doing a full table walk and is=
=A0 =A0not looking at the output careful to realize it should discard s= ome
=A0 =A0things it doesn't care about being returned. =A0I honestl= y don't know
=A0 =A0how much of this type of code exists in the world, where after the=A0 =A0last column in a table it can't handle extra data. =A0Maybe it= 's more
=A0 =A0than I'd like.

2) It'd drop the existi= ng DRAFT standard back to PROPOSED. =A0I actually
=A0 =A0don't care about this too much. =A0We (the IETF) has already adm= itted
=A0 =A0that we have issues with "levels". =A0In reality,= we need only the new
=A0 =A0parts to be PROPOSED and everything else re= main DRAFT, but we can't
=A0 =A0do that without doing the augment-in-a-new-draft-thing, which is
= =A0 =A0painful to the end user: IE, the people that matter.

In netco= nf we now have the ability to augment in place (Yay!), but the
output of= netconf is less human readable in it's raw-ish form because of
the namespace tag marking explosions (Boo!).

Yes, I'm ranting ab= out the known-failings of the SMI, which no matter
how hard we try to mo= ve from it's still very very very important in the
IETF world as new= changes and new MIBs are being written constantly.
But the failings of the SMI actually aren't the SMI at all, it's ho= w we
let ourselves use the SMI in publications "don't change it= at all, even
when it's safe to do so".

[note that confo= rmance statements aren't a problem, IMHO, you just need
to add another and let the existing one remain. =A0A device can still beconformant to the old conformance requirements.]

</rant-with-no-= real-expectations-of-change>

--
Wes Hardaker
My Pictures: =A0http://capturedonearth.com/
My Thoughts: =A0http://pont= ifications.hardakers.net/
_______________________________________________
OPSAWG= mailing list
OPSAWG@ietf.org
= = https://www.ietf.org/mailman/listinfo/opsawg

--f46d0435c1d212f8eb04c983d181-- From j.schoenwaelder@jacobs-university.de Wed Sep 12 09:52:57 2012 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 F087421F8535 for ; Wed, 12 Sep 2012 09:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08uJ8Daf-3hW for ; Wed, 12 Sep 2012 09:52:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 017CE21F84F6 for ; Wed, 12 Sep 2012 09:52:55 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86CE920CEF; Wed, 12 Sep 2012 18:52:54 +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 jMRiF4U4VN-a; Wed, 12 Sep 2012 18:52:54 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC02620C89; Wed, 12 Sep 2012 18:52:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1F8E21BE9C8; Wed, 12 Sep 2012 18:52:47 +0200 (CEST) Date: Wed, 12 Sep 2012 18:52:47 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20120912165247.GA3185@elstar.local> Mail-Followup-To: Wes Hardaker , Randy Presuhn , opsawg@ietf.org References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0lr4q7gq5y.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lr4q7gq5y.fsf@wjh.hardakers.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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: Wed, 12 Sep 2012 16:52:57 -0000 On Wed, Sep 12, 2012 at 09:30:01AM -0700, Wes Hardaker wrote: > Yes, I'm ranting about the known-failings of the SMI, which no matter > how hard we try to move from it's still very very very important in the > IETF world as new changes and new MIBs are being written constantly. > But the failings of the SMI actually aren't the SMI at all, it's how we > let ourselves use the SMI in publications "don't change it at all, even > when it's safe to do so". Yes, the SMIv2 is just fine with adding a column. Easy, nothing breaks. It is the procedures and requirements we created through all the years and with the best intentions that may make this one object addition a rather unattractive exercise paired with a fear that once we open up a document, we might end up with a rather large request for all sorts of changes and we would not know where to draw the line. The later can be dealt with by having restrictive words in a WG charter for such a MIB module update. The former can be dealt with by positive thinking; lets not spent time worrying about all the potential problems but instead see how we can make the processes work most efficient if we agree that such an update indeed makes sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Wed Sep 12 09:55:24 2012 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 A34A321F85A3 for ; Wed, 12 Sep 2012 09:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.858 X-Spam-Level: X-Spam-Status: No, score=-1.858 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5ShTbmAqjuP for ; Wed, 12 Sep 2012 09:55:23 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8794721F8535 for ; Wed, 12 Sep 2012 09:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id BAAA0540558; Wed, 12 Sep 2012 18:55:21 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FThZrDMPBimi; Wed, 12 Sep 2012 18:55:16 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E4E865401C6; Wed, 12 Sep 2012 18:55:14 +0200 (CEST) From: Ladislav Lhotka To: Wes Hardaker , Randy Presuhn In-Reply-To: <0lr4q7gq5y.fsf@wjh.hardakers.net> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0lr4q7gq5y.fsf@wjh.hardakers.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 12 Sep 2012 18:55:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 16:55:24 -0000 Wes Hardaker writes: > "Randy Presuhn" writes: > >> Submit an internet draft. The draft would contain a MIB module. >> That MIB module would contain two definitions. The first would >> be for a "conceptual row" containing a single object (which you >> defined as "hrStorageAvail" below) with an AUGMENTS clause >> referring to the base conceptual row in the Host Resources MIB. >> The second would be the definition you proposed below. > > > > You know, I know that's the right approach. I've always known that. > But... I've always hated it. > > I've always failed to see why we can't add a new column to an existing > table, which is all that is needed. Simply republish the existing MIB > with the new column. > > There are really only two downsides: > > 1) Badly written management code that is doing a full table walk and is > not looking at the output careful to realize it should discard some > things it doesn't care about being returned. I honestly don't know > how much of this type of code exists in the world, where after the > last column in a table it can't handle extra data. Maybe it's more > than I'd like. > > 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually > don't care about this too much. We (the IETF) has already admitted > that we have issues with "levels". In reality, we need only the new > parts to be PROPOSED and everything else remain DRAFT, but we can't > do that without doing the augment-in-a-new-draft-thing, which is > painful to the end user: IE, the people that matter. > > In netconf we now have the ability to augment in place (Yay!), but the > output of netconf is less human readable in it's raw-ish form because of > the namespace tag marking explosions (Boo!). Use the current SVN revision of pyang and translate it to JSON. If the data model schema is sane, the namespaces will be completely gone. If the schema is less sane, the names of YANG modules will be used as namespace identifiers where necessary. Lada > > Yes, I'm ranting about the known-failings of the SMI, which no matter > how hard we try to move from it's still very very very important in the > IETF world as new changes and new MIBs are being written constantly. > But the failings of the SMI actually aren't the SMI at all, it's how we > let ourselves use the SMI in publications "don't change it at all, even > when it's safe to do so". > > [note that conformance statements aren't a problem, IMHO, you just need > to add another and let the existing one remain. A device can still be > conformant to the old conformance requirements.] > > > > -- > Wes Hardaker > My Pictures: http://capturedonearth.com/ > My Thoughts: http://pontifications.hardakers.net/ > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From randy_presuhn@mindspring.com Wed Sep 12 11:25:52 2012 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 AE38721F8720 for ; Wed, 12 Sep 2012 11:25:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+Gr7nLR9DDZ for ; Wed, 12 Sep 2012 11:25:52 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1326521F871D for ; Wed, 12 Sep 2012 11:25:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IpNYGvZGcFkcaQi8rI/r379SpgrBS6CwArPBCR4awp3661LwZScv0yFSeATj+dOB; 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 [76.254.54.251] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TBrdG-0002nD-Nd for opsawg@ietf.org; Wed, 12 Sep 2012 14:25:51 -0400 Message-ID: <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> Date: Wed, 12 Sep 2012 11:32:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1cb1de25a6534d6bd621f3f7a28c5d71f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.251 Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 18:25:52 -0000 Hi - > From: "Wes Hardaker" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, September 12, 2012 9:23 AM > Subject: Re: Addition of Available Space to Host-Resources-MIB ... > ... > 1) Badly written management code that is doing a full table walk and is ... I wouldn't worry about it. I seem to recall this being one of the cases tested in the early interoperability bake-offs way back when. This argument is just as (in)valid with regard to the use of any less-used protocol feature, or to the addition of anything to a data model. > 2) It'd drop the existing DRAFT standard back to PROPOSED. I actually ... It also doesn't bother me, but I think that's a question for the folks with products in that market segment. > Keeping the amount of paperwork to a minimum, how about doing something that, while perfectly legal as far as I can tell, might *really* irk badly written code: hrExtStorageEntry OBJECT-TYPE SYNTAX HrExtStorageEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A (conceptual) entry for one logical storage area on the host, containing extensions to the information contained in the corresponding hrStorageEntry." AUGMENTS { hrStorageEntry } ::= { hrStorageTable 2 } -- yes, that's a TWO! hrExtStorageAvail OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION "The amount of the storage represented by this entry that is available to non-superusers, in units of hrStorageAllocationUnits." ::= { hrExtStorageEntry 8 } Randy From randy_presuhn@mindspring.com Wed Sep 12 11:46:11 2012 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 50D9521F8709 for ; Wed, 12 Sep 2012 11:46:11 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi+CHVoFP7HA for ; Wed, 12 Sep 2012 11:46:10 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id B18FE21F86B9 for ; Wed, 12 Sep 2012 11:46:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ozMnlj1FU212VmdKQYZufHSA34i2x2eBrJdmYlgf9evujCmpmCQ5j7TTtCl6qEu1; 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 [76.254.54.251] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TBrwv-0003x3-SF for opsawg@ietf.org; Wed, 12 Sep 2012 14:46:10 -0400 Message-ID: <002701cd9117$dcf484a0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer><0lr4q7gq5y.fsf@wjh.hardakers.net> Date: Wed, 12 Sep 2012 11:53:12 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f18211947796a0ab5ae0e5eb9ce4f1c0e6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.251 Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 12 Sep 2012 18:46:11 -0000 Hi - > From: "Sheppy Reno" > To: "Wes Hardaker" > Cc: "Randy Presuhn" ; > Sent: Wednesday, September 12, 2012 9:38 AM > Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB > > If I submit this as an AUGMENT would it still mean that hrStorageAvailable > would appear grouped with the rest of the hrStorage table in an SNMP walk > or would it be a completely separate MIB? The question mixes two distinct issues. How stuff is grouped for presentation to the user is up to the designer of the tool in question, and should not be determined by whether the relevant portions of the data model were defined in one or multiple MIB modules, or how they're scattered by so-called lexicographical ordering. (If you think about how SMI indexing works in SNMP protocol, closely related bits of information are already scattered all over the place in the responses to getNext or getBulk. It's lame, but that's how it was designed.) The designer of, for example, a "host resources" tool needs to develop an information model to suit the use cases s/he would like to address, and then figure out how that information model can be realized using the available data models, modulo their implementation quirks. Most management applications deal with multiple data models, even if their developers haven't consciously made the decision to do so. Consider how many MIB objects have discontinuity indicators defined in other MIB modules. Without the philosophizing, here's the tradeoff. You can A) try to re-spin the host resources MIB. While this would put the new column in the table and keep brainless MIB-walker happy, this is also the most work in terms of IETF process, editorial and reviewer cycles. I do not see any way in which this would be a significant win for intelligent management applications. B) create a new MIB module, using AUGMENTS, etc. While this won't help the brainless MIB walker, for intelligent management applications, and even for fairly simple-minded script-driven applications, this works as well as (A), with orders of magnitude less institutional overhead. C) You can try to change the process to make (A) less of an institutional burden. Of these, only (B) has in my opinion much chance of being accomplished quickly. Randy From wjhns1@hardakers.net Thu Sep 13 10:59:14 2012 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 E92D721F8606 for ; Thu, 13 Sep 2012 10:59:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8mS9yDYHus7 for ; Thu, 13 Sep 2012 10:59:14 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id B880021F84EF for ; Thu, 13 Sep 2012 10:59:14 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:c004:3973:a15f:f1df]) by mail.hardakers.net (Postfix) with ESMTPSA id 4FFE8538; Thu, 13 Sep 2012 10:59:14 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" In-Reply-To: <002701cd9117$dcf484a0$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 12 Sep 2012 11:53:12 -0700") References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0lr4q7gq5y.fsf@wjh.hardakers.net> <002701cd9117$dcf484a0$6b01a8c0@oemcomputer> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) Date: Thu, 13 Sep 2012 10:59:14 -0700 Message-ID: <0l627herd9.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 13 Sep 2012 17:59:15 -0000 "Randy Presuhn" writes: [I'd like to remind people that it was a rant; I don't expect something different than the AUGMENT approach to actually be taken] > A) try to re-spin the host resources MIB. While this would > put the new column in the table and keep brainless > MIB-walker happy, this is also the most work in terms > of IETF process, editorial and reviewer cycles. I do not > see any way in which this would be a significant win for > intelligent management applications. Note: I tend to optimize for the "most people" most of the time. There are a whole heck of a lot of brainless mib-walkers, but there is only one document author. In terms of time-spent, I suspect putting more work on the document author and less on the brainless means a positive energy balance if "it must be done in the first place". But I realize that's not the right approach in terms of optimizing for the author, reviewers, iesg, etc. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From wjhns1@hardakers.net Thu Sep 13 10:59:53 2012 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 A7FAD21F860D for ; Thu, 13 Sep 2012 10:59:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6U6iR9CuLeU for ; Thu, 13 Sep 2012 10:59:53 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3121F8606 for ; Thu, 13 Sep 2012 10:59:53 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:c004:3973:a15f:f1df]) by mail.hardakers.net (Postfix) with ESMTPSA id 0947B175; Thu, 13 Sep 2012 10:59:53 -0700 (PDT) From: Wes Hardaker To: Ladislav Lhotka In-Reply-To: (Ladislav Lhotka's message of "Wed, 12 Sep 2012 18:55:13 +0200") References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0lr4q7gq5y.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) Date: Thu, 13 Sep 2012 10:59:52 -0700 Message-ID: <0l4nn1erc7.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 13 Sep 2012 17:59:53 -0000 Ladislav Lhotka writes: > Use the current SVN revision of pyang and translate it to JSON. If the > data model schema is sane, the namespaces will be completely gone. If > the schema is less sane, the names of YANG modules will be used as > namespace identifiers where necessary. I very much realize that there are tool-ways around doing things. And they should be used, I agree. -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From wjhns1@hardakers.net Thu Sep 13 11:04:10 2012 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 D797F21F8504 for ; Thu, 13 Sep 2012 11:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2q+wdlJPur2 for ; Thu, 13 Sep 2012 11:04:10 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3621F84F6 for ; Thu, 13 Sep 2012 11:04:10 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:c004:3973:a15f:f1df]) by mail.hardakers.net (Postfix) with ESMTPSA id 9F716175; Thu, 13 Sep 2012 11:04:09 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> Date: Thu, 13 Sep 2012 11:04:09 -0700 In-Reply-To: <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Wed, 12 Sep 2012 11:32:50 -0700") Message-ID: <0ly5kddckm.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 13 Sep 2012 18:04:11 -0000 "Randy Presuhn" writes: > Keeping the amount of paperwork to a minimum, how about doing > something that, while perfectly legal as far as I can tell, > might *really* irk badly written code: > > hrExtStorageEntry OBJECT-TYPE > SYNTAX HrExtStorageEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A (conceptual) entry for one logical storage area on > the host, containing extensions to the information > contained in the corresponding hrStorageEntry." > AUGMENTS { hrStorageEntry } > ::= { hrStorageTable 2 } > > -- yes, that's a TWO! Heh. I'd be more tempted to simply define the new column in a new MIB module and import the existing entry spec and just place the new column into the table from afar. IE, just do this: > hrExtStorageAvail OBJECT-TYPE > SYNTAX Integer32 (0..2147483647) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The amount of the storage represented > by this entry that is available to > non-superusers, in units of > hrStorageAllocationUnits." > ::= { hrExtStorageEntry 8 } (which is actually a copy of what you put because you forgot to add the 2 to your OID clause in the first place) -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ From sheppyreno@gmail.com Thu Sep 13 11:15:21 2012 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 879FF21F85C3 for ; Thu, 13 Sep 2012 11:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGxyiytKVWCl for ; Thu, 13 Sep 2012 11:15:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A41A121F859F for ; Thu, 13 Sep 2012 11:15:20 -0700 (PDT) Received: by lbky2 with SMTP id y2so2336314lbk.31 for ; Thu, 13 Sep 2012 11:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KLPOH5yG4U96ZF3e2pe/u9jgoMLwYIAiDVS0zdtbTVI=; b=GS0g8PXCuyEgNpCsDRvDaKWNGkxcjj6rOJv6kekRGmI9qeSIJi8C7po5KjKnSYOpfQ eT6vXY868sZGkRjo7DvVNwuBfGZZwW/h5oqhlkWpgo3O6oOoH8X2EgbM4KsRyk+Xgep/ ioiaYPnppLqlvYz5rekF0QObA3GAJbn7RWFe0njlOf61g09/4eo3oGN5RJc1ZxJMGivo 8UEhNwWxOuYWc6bGcsjllB+0eor97RZRugBVXo7sC0dDfFXnmaeSv4hM9sGuTr8w1XBq FfvLh/ZdnTtKAjd+OOVfCfhUQvGQRmSwYc4pUIBwseSzRflturzlW5zdhuR03x5Vtq+c G8Yg== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr61524lam.38.1347560119382; Thu, 13 Sep 2012 11:15:19 -0700 (PDT) Received: by 10.112.87.231 with HTTP; Thu, 13 Sep 2012 11:15:19 -0700 (PDT) In-Reply-To: <0ly5kddckm.fsf@wjh.hardakers.net> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> Date: Thu, 13 Sep 2012 14:15:19 -0400 Message-ID: From: Sheppy Reno To: Wes Hardaker Content-Type: multipart/alternative; boundary=bcaec550b3ae3ab07d04c9994a08 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 13 Sep 2012 18:15:21 -0000 --bcaec550b3ae3ab07d04c9994a08 Content-Type: text/plain; charset=ISO-8859-1 I'm in the position of having to go through IETF because none of the work arounds that I proposed were acceptable for various reasons (a large part of it boils down to manpower considerations). It seems that from everything I've read, that updating the Host-Resources-MIB RCF itself is the proper way to implement this -- manpower considerations aside. I believe that this is the right way to go and another RFC said something to the effect that once an OID is placed somewhere it can't be moved. I'd rather not go through the process of getting it added as an augment only to find out that RFC2790 was superseded in the next year or two and I'm unable to get this added correctly. Sorry if I seem a bit dense, but RFCs relating to the ins and outs of RFC documentation is very difficult to navigate for the uninitiated. As far as manpower is concerned, assuming I want to proceed with getting RFC2790 itself updated are there steps that I can take to reduce the overhead of others as much as possible? Thanks again, Sheppy --bcaec550b3ae3ab07d04c9994a08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm in the position of having to go through IETF because none of t= he work arounds that I proposed were acceptable for various reasons (a larg= e part of it boils down to manpower considerations).=A0 It seems that from = everything I've read, that updating the Host-Resources-MIB RCF itself i= s the proper way to implement this -- manpower considerations aside.=A0 I b= elieve that this is the right way to go and another RFC said something to t= he effect that once an OID is placed somewhere it can't be moved.=A0 I&= #39;d rather not go through the process of getting it added as an augment o= nly to find out that RFC2790 was superseded in the next year or two and I&#= 39;m unable to get this added correctly.
=A0
Sorry if I seem a bit dense, but RFCs=A0relating to the ins and outs o= f RFC documentation is very difficult to navigate for the uninitiated.
=A0
As far as manpower is concerned, assuming I want to proceed with getti= ng RFC2790 itself updated are there steps that I can take to reduce the ove= rhead of others as much as possible?
=A0
Thanks again,
Sheppy
--bcaec550b3ae3ab07d04c9994a08-- From ietfc@btconnect.com Fri Sep 14 06:55:22 2012 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 B544721F853A for ; Fri, 14 Sep 2012 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu9eYKIQH8Gn for ; Fri, 14 Sep 2012 06:55:22 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0B10821F8528 for ; Fri, 14 Sep 2012 06:55:21 -0700 (PDT) Received: from mail44-ch1-R.bigfish.com (10.43.68.250) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Sep 2012 13:55:20 +0000 Received: from mail44-ch1 (localhost [127.0.0.1]) by mail44-ch1-R.bigfish.com (Postfix) with ESMTP id CFC44400B3; Fri, 14 Sep 2012 13:55:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1432I111aId6f1izz1202h1d1ah1d2ahzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh1315h304l1155h) Received: from mail44-ch1 (localhost.localdomain [127.0.0.1]) by mail44-ch1 (MessageSwitch) id 1347630918720725_18940; Fri, 14 Sep 2012 13:55:18 +0000 (UTC) Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail44-ch1.bigfish.com (Postfix) with ESMTP id AD70B400077; Fri, 14 Sep 2012 13:55:18 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Sep 2012 13:55:17 +0000 Received: from AMSPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.255.79.164) with Microsoft SMTP Server (TLS) id 14.16.190.9; Fri, 14 Sep 2012 13:55:06 +0000 Message-ID: <008d01cd9280$a156c560$4001a8c0@gateway.2wire.net> From: t.petch To: Sheppy Reno References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer><0ld31ri515.fsf@wjh.hardakers.net><001f01cd9115$04a252a0$6b01a8c0@oemcomputer><0ly5kddckm.fsf@wjh.hardakers.net> Date: Fri, 14 Sep 2012 14:54:22 +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.5] X-OriginatorOrg: btconnect.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 13:55:22 -0000 ----- Original Message ----- From: "Sheppy Reno" To: "Wes Hardaker" Cc: Sent: Thursday, September 13, 2012 7:15 PM > I'm in the position of having to go through IETF because none of the work > arounds that I proposed were acceptable for various reasons (a large part > of it boils down to manpower considerations). It seems that from > everything I've read, that updating the Host-Resources-MIB RCF itself is > the proper way to implement this -- manpower considerations aside. I > believe that this is the right way to go and another RFC said something to > the effect that once an OID is placed somewhere it can't be moved. I'd > rather not go through the process of getting it added as an augment only to > find out that RFC2790 was superseded in the next year or two and I'm unable > to get this added correctly. > > Sorry if I seem a bit dense, but RFCs relating to the ins and outs of RFC > documentation is very difficult to navigate for the uninitiated. > > As far as manpower is concerned, assuming I want to proceed with getting > RFC2790 itself updated are there steps that I can take to reduce the > overhead of others as much as possible? Get everything perfect first time:-) With any I-D/RFC, you either get it adopted by a Working Group or you do it as an individual submission. In terms of your work, both are about equal. In terms of the work of others, the latter tends to burden some people more than the former so there is a push to use a WG. There is no WG currently in the IETF that focuses on MIBs, this, OPSAWG, is about the nearest. The key players are the WG chairs and an Area Director; the web site tells you who they are and you can see on the WG list archive what they have said lately about what and form a view as to how supportive they are. Well, ask them directly if that is your style. Look too at the WG charter "The OPSAWG will undertake only work items that are proved to have at least a reasonable level of interest from the operators and users community and have a committed number of editors and reviewers." Um. On the route of individual submission, it as an AD and a WG chair (or perhaps a former WG chair) who have a lot more work to do to push an I-D through to a standard; you would need their active support. Hence the push to use a WG - and if the WG and/or its chairs are reluctant to take it on, then the work is unlikely to happen. As you probably gather, SNMP and MIB modules are regarded somewhat as a legacy technology, Netconf/Netmod being the current incarnation. So if you were to propose the conversion of the hr MIB module to netmod, then I would expect you to see more enthusiasm; but that is, of course, a quantum leap. Tom Petch > Thanks again, > Sheppy > From ietfdbh@comcast.net Fri Sep 14 08:40:54 2012 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 084F321F851E for ; Fri, 14 Sep 2012 08:40:54 -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=[AWL=0.001, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-HD5tOmgbWs for ; Fri, 14 Sep 2012 08:40:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3936821F851C for ; Fri, 14 Sep 2012 08:40:53 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id yyn91j0021HzFnQ533gwwq; Fri, 14 Sep 2012 15:40:56 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id z3gs1j00o3Ecudz3a3gu2t; Fri, 14 Sep 2012 15:40:55 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 14 Sep 2012 11:40:49 -0400 From: David Harrington To: "t.petch" , Sheppy Reno Message-ID: Thread-Topic: [OPSAWG] Addition of Available Space to Host-Resources-MIB In-Reply-To: <008d01cd9280$a156c560$4001a8c0@gateway.2wire.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 15:40:54 -0000 Hi, Comments inline. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 9/14/12 9:54 AM, "t.petch" wrote: > >With any I-D/RFC, you either get it adopted by a Working Group or you do >it as an individual submission. In terms of your work, both are about >equal. In terms of the work of others, the latter tends to burden some >people more than the former so there is a push to use a WG. I see things differently. I think the individual draft requires less work by others. An AD can sponsor the draft, and ask the IESG to approve it. A WG is used to get a wider review of the proposal. >There is no >WG currently in the IETF that focuses on MIBs, this, OPSAWG, is about >the nearest. The key players are the WG chairs and an Area Director; >the web site tells you who they are and you can see on the WG list >archive what they have said lately about what and form a view as to how >supportive they are. Well, ask them directly if that is your style. >Look too at the WG charter > >"The OPSAWG will undertake only work items that are proved to have at >least a reasonable level of interest from the operators and users >community and have a committed number of editors and reviewers." I have not seen a large demand for this proposed object from operators. I think asking the WG for review will be important to 1) establish operator demand, 2) establish implementation feasibility of providing this information via SNMP, 3) help to ensure that a clear, unambiguous definition of "available" > >Um. > >On the route of individual submission, it as an AD and a WG chair (or >perhaps a former WG chair) who have a lot more work to do to push an I-D >through to a standard; you would need their active support. Hence the >push to use a WG - and if the WG and/or its chairs are reluctant to take >it on, then the work is unlikely to happen. IIRC, a WG chair is NOT needed to push an ID through to standard. An AD can sponsor it alone, although most like to see a separate document shepherd (who might be a chair or ex-chair). The AD just needs to convince the IESG to approve it as a standard. And the IESG might want some proof of operator demand, implementation feasibility, and community consensus on the definition. > >As you probably gather, SNMP and MIB modules are regarded somewhat as a >legacy technology, Netconf/Netmod being the current incarnation. So if >you were to propose the conversion of the hr MIB module to netmod, then >I would expect you to see more enthusiasm; but that is, of course, a >quantum leap. Since the object being proposed reports operational state, and is a read-only object that is not configurable, and detection of significant state change may be important for applications, periodic polling of a MIB object using SNMP seems the appropriate choice of tool; I don't see this as configuration information appropriate for the netconf/YANG toolset (except as part of an overall HR configuration data model - but that's a whole different proposal). Therefore I would not expect more enthusiasm for a netconf/YANG solution. > >Tom Petch > >> Thanks again, >> Sheppy >> > > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From heard@pobox.com Fri Sep 14 09:13:36 2012 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 1952521F851E for ; Fri, 14 Sep 2012 09:13:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2YRFJoaehIj for ; Fri, 14 Sep 2012 09:13:35 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34B21F851A for ; Fri, 14 Sep 2012 09:13:35 -0700 (PDT) Received: (qmail 14878 invoked from network); 14 Sep 2012 09:13:34 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Sep 2012 09:13:34 -0700 Date: Fri, 14 Sep 2012 09:13:34 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSAWG In-Reply-To: <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> Message-ID: References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 16:13:36 -0000 On Wed, 12 Sep 2012, Randy Presuhn wrote: > Keeping the amount of paperwork to a minimum, how about doing > something that, while perfectly legal as far as I can tell, > might *really* irk badly written code: > > hrExtStorageEntry OBJECT-TYPE > SYNTAX HrExtStorageEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "A (conceptual) entry for one logical storage area on > the host, containing extensions to the information > contained in the corresponding hrStorageEntry." > AUGMENTS { hrStorageEntry } > ::= { hrStorageTable 2 } > > -- yes, that's a TWO! I wouldn't do that. It that violates RFC 2578 7.10 (1): (1) If the object corresponds to a conceptual table, then only a single assignment, that for a conceptual row, is present immediately beneath that object. The administratively assigned name for the conceptual row object is derived by appending a sub-identifier of "1" to the administratively assigned name for the conceptual table. and it's not unlikely that some implementations exploit this restriction in some way. //cmh From heard@pobox.com Fri Sep 14 09:36:48 2012 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 5FFDB21F8514 for ; Fri, 14 Sep 2012 09:36:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8hom0Y7-TJC for ; Fri, 14 Sep 2012 09:36:47 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id E059721F84C4 for ; Fri, 14 Sep 2012 09:36:47 -0700 (PDT) Received: (qmail 26675 invoked from network); 14 Sep 2012 09:36:46 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Sep 2012 09:36:46 -0700 Date: Fri, 14 Sep 2012 09:36:46 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Sheppy Reno In-Reply-To: Message-ID: References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 16:36:48 -0000 Greetings, It's not clear from what you write below whether or not you have considered and rejected the idea of creating a proprietary supplemental MIB module to augment the IETF Host-Resources-MIB. Basically, this is suggestion (B) in Randy Presuhn's message http://www.ietf.org/mail-archive/web/opsawg/current/msg02368.html but with the supplemental object(s) registered under an enterprise OID subtree (available from IANA for the asking) instead of an IETF OID subtree. This approach would not require any standardization effort at all, just the effort to write the supplemental MIB module and to implement the object(s) in it. If the IETF community has low interest in standardizing the extension you are asking for, then this is probably the right way to go. On the other hand, if your extension is seen as broadly useful, updating the Host-Resources-MIB itself is probably the right way to go. It's true that once an object is defined and registered under a given OID the object's semantics are not allowed to change (except in some very limited ways spelled out in RFC 2580) and that OID under which it is registered cannot be reused for something else. But I don't follow why you are worried that if you create an augmenting table for your proposed extension that you would be left high and dry by a subsequent update of the Host-Resources-MIB. Such updates (if they occur) are supposed to be backward-compatible. Mike Heard On Thu, 13 Sep 2012, Sheppy Reno wrote: > I'm in the position of having to go through IETF because none of the work > arounds that I proposed were acceptable for various reasons (a large part > of it boils down to manpower considerations). It seems that from > everything I've read, that updating the Host-Resources-MIB RCF itself is > the proper way to implement this -- manpower considerations aside. I > believe that this is the right way to go and another RFC said something to > the effect that once an OID is placed somewhere it can't be moved. I'd > rather not go through the process of getting it added as an augment only to > find out that RFC2790 was superseded in the next year or two and I'm unable > to get this added correctly. > > Sorry if I seem a bit dense, but RFCs relating to the ins and outs of RFC > documentation is very difficult to navigate for the uninitiated. > > As far as manpower is concerned, assuming I want to proceed with getting > RFC2790 itself updated are there steps that I can take to reduce the > overhead of others as much as possible? > > Thanks again, > Sheppy > From melinda.shore@gmail.com Fri Sep 14 11:36:23 2012 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 C61C821F8545 for ; Fri, 14 Sep 2012 11:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJSzuKQwAObw for ; Fri, 14 Sep 2012 11:36:23 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE5221F853E for ; Fri, 14 Sep 2012 11:36:23 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so5993366pbb.31 for ; Fri, 14 Sep 2012 11:36:23 -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 :references:in-reply-to:content-type:content-transfer-encoding; bh=+5SUN5GZqcK0KrnY4luV8RqkXVIhXf8KNpl7CNjtFVc=; b=IrOdqzEE9crCv75950uFH8WsFcjdXM17nzEdFyU7zYdGspHOfn7UuIVgkWDDdlvIpU RZxdZDZ5CPA6TXjBUCeCDmMTUzGt8q7vfCdEsfEFTqqLIGYlgqkcaq8Fb5NkCqhoDpZf YViOaAyfcoTiejP5bfw1ZAlD9vX/Pw4X12QYUT967CGwWabFoq4j0bBWpwSNhg1yw28T GrPcvZuWGbecx/3QOrQ0CcR2DWDKKFJlYqY1ZTt+erDRVDD/yu+CqEpylVXFl++kXed9 a1J1vMV2wWVEFhUV3aZDlxH09EtPhfsr8hIAuWQ6QQUToTNELJzL8uy/TeViZMZXorEW EgEw== Received: by 10.68.226.134 with SMTP id rs6mr6239404pbc.5.1347647783165; Fri, 14 Sep 2012 11:36:23 -0700 (PDT) Received: from spandex.local (66-230-101-241-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.101.241]) by mx.google.com with ESMTPS id ou6sm1392968pbc.9.2012.09.14.11.36.21 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Sep 2012 11:36:21 -0700 (PDT) Message-ID: <50537923.2040509@gmail.com> Date: Fri, 14 Sep 2012 10:36:19 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "C. M. Heard" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 18:36:23 -0000 On 9/14/12 8:36 AM, C. M. Heard wrote: > This approach would not require any standardization effort at all, > just the effort to write the supplemental MIB module and to > implement the object(s) in it. If the IETF community has low > interest in standardizing the extension you are asking for, then > this is probably the right way to go. I think that's probably the case - I haven't seen anybody else express interest or support, although the discussion so far has really focused on how to get it done if it's decided that it should be. If this turns out to be the best option (a proprietary supplemental MIB) it might be possible to publish it as an individual contribution, documenting something that's out there and deployed. Thanks, Mike. Melinda From heard@pobox.com Fri Sep 14 13:18:03 2012 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 D6B1A21F8540 for ; Fri, 14 Sep 2012 13:18: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PDBCxuR3Mtx for ; Fri, 14 Sep 2012 13:18:03 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4E21F853E for ; Fri, 14 Sep 2012 13:18:03 -0700 (PDT) Received: (qmail 11276 invoked from network); 14 Sep 2012 13:18:01 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Sep 2012 13:18:01 -0700 Date: Fri, 14 Sep 2012 13:18:00 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Melinda Shore In-Reply-To: <50537923.2040509@gmail.com> Message-ID: References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 20:18:04 -0000 On Fri, 14 Sep 2012, Melinda Shore wrote: > On 9/14/12 8:36 AM, C. M. Heard wrote: > > This approach would not require any standardization effort at all, > > just the effort to write the supplemental MIB module and to > > implement the object(s) in it. If the IETF community has low > > interest in standardizing the extension you are asking for, then > > this is probably the right way to go. > > I think that's probably the case - I haven't seen anybody else > express interest or support, although the discussion so far has > really focused on how to get it done if it's decided that it > should be. > > If this turns out to be the best option (a proprietary > supplemental MIB) it might be possible to publish it as an > individual contribution, documenting something that's out > there and deployed. That's true. However, the person doing the work is the one who would have to decide if it's worth the effort. There is no obligation on the part of an implementor to publish proprietary MIB extensions. Being able to "just do it" and not go through any IETF or RFC Editor process hassles is one of the upsides of the proprietary MIB extension approach. //cmh From randy_presuhn@mindspring.com Fri Sep 14 14:47:53 2012 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 1C12E21F8471 for ; Fri, 14 Sep 2012 14:47:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRo6rIPMUDaY for ; Fri, 14 Sep 2012 14:47:52 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 89B9A21F8472 for ; Fri, 14 Sep 2012 14:47:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=HiTy00f/gSbe+quSR/Ct6VcvHsA4D1Ekk0YxwhNZRgSUTTL1FoIGT1UFWLfw/W7+; 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.35.227.98] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TCdjr-00073s-DM for opsawg@ietf.org; Fri, 14 Sep 2012 17:47:51 -0400 Message-ID: <006701cd92c3$96c23380$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "OPSAWG" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer><0ld31ri515.fsf@wjh.hardakers.net><001f01cd9115$04a252a0$6b01a8c0@oemcomputer><0ly5kddckm.fsf@wjh.hardakers.net><50537923.2040509@gmail.com> Date: Fri, 14 Sep 2012 14:54:59 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f184ed17d106644b8a8843053d919c4fbb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.98 Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 14 Sep 2012 21:47:53 -0000 Hi - > From: "C. M. Heard" > To: "Melinda Shore" > Cc: "OPSAWG" > Sent: Friday, September 14, 2012 1:18 PM > Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB ... > That's true. However, the person doing the work is the one who > would have to decide if it's worth the effort. There is no > obligation on the part of an implementor to publish proprietary MIB > extensions. Being able to "just do it" and not go through any IETF > or RFC Editor process hassles is one of the upsides of the > proprietary MIB extension approach. As I understand the post that started this thread, the problem is that there are important use cases that the Host-Resources-MIB does not adequately support. To address these use cases, managed systems need to make available an additional piece of information. For this to do anyone any good, this means (1) updating the instrumentation in the managed systems, and (2) making that information available in a reasonably "standardized" manner. Addressing (2) is best accomplished with an RFC, even if its "merely" informational. An unpublished proprietary MIB or extension MIB is of little value there. This discussion has thus far not touched on (1) at all, and I note that the folks who I know were most visible in Host-Resources-MIB implementations have been conspicuously absent from this discussion. Without some interest in (1), or at least some assurance that the major code bases might get updated, the main value of a document would be to describe the shortcoming and other possible operational workarounds, if they exist. Randy From wjhns1@hardakers.net Mon Sep 17 09:52:47 2012 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 F2F6721F844F for ; Mon, 17 Sep 2012 09:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr5PbToCbc53 for ; Mon, 17 Sep 2012 09:52:46 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C9521F8545 for ; Mon, 17 Sep 2012 09:52:46 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:b838:9baf:a3d1:1beb]) by mail.hardakers.net (Postfix) with ESMTPSA id EA10A387; Mon, 17 Sep 2012 09:52:43 -0700 (PDT) From: Wes Hardaker To: Melinda Shore References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> Date: Mon, 17 Sep 2012 09:52:43 -0700 In-Reply-To: <50537923.2040509@gmail.com> (Melinda Shore's message of "Fri, 14 Sep 2012 10:36:19 -0800") Message-ID: <0lobl4zj50.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "C. M. Heard" , OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 16:52:47 -0000 Melinda Shore writes: >> This approach would not require any standardization effort at all, >> just the effort to write the supplemental MIB module and to >> implement the object(s) in it. If the IETF community has low >> interest in standardizing the extension you are asking for, then >> this is probably the right way to go. > > I think that's probably the case - I haven't seen anybody else > express interest or support, although the discussion so far has > really focused on how to get it done if it's decided that it > should be. FYI, I support the standardization of additional objects to the HR mib. There are a number of requests I've heard over time that have needed to add additions to the HR mib, and this is really just one of a few. -- Wes Hardaker SPARTA, Inc. From wjhns1@hardakers.net Mon Sep 17 09:53:48 2012 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 C0D9521F85D5 for ; Mon, 17 Sep 2012 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqtcLngR3ibt for ; Mon, 17 Sep 2012 09:53:48 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2A021F8557 for ; Mon, 17 Sep 2012 09:53:48 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:b838:9baf:a3d1:1beb]) by mail.hardakers.net (Postfix) with ESMTPSA id 06E25175; Mon, 17 Sep 2012 09:53:47 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <006701cd92c3$96c23380$6b01a8c0@oemcomputer> Date: Mon, 17 Sep 2012 09:53:47 -0700 In-Reply-To: <006701cd92c3$96c23380$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Fri, 14 Sep 2012 14:54:59 -0700") Message-ID: <0lk3vszj38.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 16:53:48 -0000 "Randy Presuhn" writes: > This discussion has thus far not touched on (1) at all, and I note that > the folks who I know were most visible in Host-Resources-MIB > implementations have been conspicuously absent from this discussion. > Without some interest in (1), or at least some assurance that the > major code bases might get updated, the main value of a document > would be to describe the shortcoming and other possible operational > workarounds, if they exist. Speaking with my vendor hat on: Net-SNMP would almost certainly add support for them. -- Wes Hardaker SPARTA, Inc. From rstory@tislabs.com Mon Sep 17 11:03:59 2012 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 DE3DA21F8691 for ; Mon, 17 Sep 2012 11:03:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zg87zNPV-I+u for ; Mon, 17 Sep 2012 11:03:59 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76E21F863C for ; Mon, 17 Sep 2012 11:03:59 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C516328B003A; Mon, 17 Sep 2012 14:03:58 -0400 (EDT) Received: from tp.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 8E8D01F8032; Mon, 17 Sep 2012 14:03:58 -0400 (EDT) Date: Mon, 17 Sep 2012 14:03:48 -0400 From: Robert Story To: Wes Hardaker Message-ID: <20120917140348.084b8f09@tp.vb.futz.org> In-Reply-To: <0lobl4zj50.fsf@wjh.hardakers.net> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> Organization: SPARTA X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/nTZh3LS4DBSz1ovY0beqhYv"; protocol="application/pgp-signature" Cc: "C. M. Heard" , OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 18:04:00 -0000 --Sig_/nTZh3LS4DBSz1ovY0beqhYv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2012 09:52:43 -0700 Wes wrote: WH> Melinda Shore writes: WH> > I think that's probably the case - I haven't seen anybody else WH> > express interest or support, although the discussion so far has WH> > really focused on how to get it done if it's decided that it WH> > should be. WH>=20 WH> FYI, I support the standardization of additional objects to the HR mib. +1 WH> There are a number of requests I've heard over time that have needed to WH> add additions to the HR mib, and this is really just one of a few. Yep, I had the same though. If we're going to do this, digging up those and doing them at the same time would make sense. Robert -- Senior Software Engineer SPARTA, Inc., a Parsons Company --Sig_/nTZh3LS4DBSz1ovY0beqhYv Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBXZg0ACgkQ7/fVLLY1mnjGwQCeIbd0O8Uf2x0bWCmz2sscLWXx yQMAmgLO8ArgKWFb4VDst3OtXiNwZO98 =qOFv -----END PGP SIGNATURE----- --Sig_/nTZh3LS4DBSz1ovY0beqhYv-- From randy_presuhn@mindspring.com Mon Sep 17 11:29:34 2012 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 0465721F8462 for ; Mon, 17 Sep 2012 11:29:34 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tTST3Cdgp+A for ; Mon, 17 Sep 2012 11:29:33 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 855BE21F844B for ; Mon, 17 Sep 2012 11:29:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=R0WP4koLv1Xl6ZR/FaBQwL8H2mdd+jgzSIyvP1R+rDpbJht8iiIbnYgVaM/8eDoa; 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.30.224.193] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TDg4a-0006hv-D5 for opsawg@ietf.org; Mon, 17 Sep 2012 14:29:32 -0400 Message-ID: <003601cd9503$655f5740$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "OPSAWG" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer><0ld31ri515.fsf@wjh.hardakers.net><001f01cd9115$04a252a0$6b01a8c0@oemcomputer><0ly5kddckm.fsf@wjh.hardakers.net><50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> Date: Mon, 17 Sep 2012 11:36:46 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1d3002070a478a5fc6213b7b2bba5ad5e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.224.193 Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 18:29:34 -0000 Hi - > From: "Wes Hardaker" > To: "Melinda Shore" > Cc: "C. M. Heard" ; "OPSAWG" > Sent: Monday, September 17, 2012 9:52 AM > Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB ... > FYI, I support the standardization of additional objects to the HR mib. > There are a number of requests I've heard over time that have needed to > add additions to the HR mib, and this is really just one of a few. Would you prefer to accomplish this by re-opening the Host-Resources-MIB, or by creating a new MIB module (Host-Resources-Extensions-MIB)? In either case, if there turns out to be sufficient interest in taking this on as a WG item, I'd be willing to edit, if needed. Randy From rstory@tislabs.com Mon Sep 17 14:37:02 2012 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 02FA421E804A for ; Mon, 17 Sep 2012 14:37:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uw-hfnnNR0vC for ; Mon, 17 Sep 2012 14:37:01 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7102521E803D for ; Mon, 17 Sep 2012 14:37:01 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0316C28B003A; Mon, 17 Sep 2012 17:37:01 -0400 (EDT) Received: from tp.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CFB521F8032; Mon, 17 Sep 2012 17:37:00 -0400 (EDT) Date: Mon, 17 Sep 2012 17:36:55 -0400 From: Robert Story To: "Randy Presuhn" Message-ID: <20120917173655.49e75ae0@tp.vb.futz.org> In-Reply-To: <003601cd9503$655f5740$6b01a8c0@oemcomputer> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> Organization: SPARTA X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/qW9JYbrVD5HUN=bcjx5Zi4B"; protocol="application/pgp-signature" Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 21:37:02 -0000 --Sig_/qW9JYbrVD5HUN=bcjx5Zi4B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2012 11:36:46 -0700 Randy wrote: RP> Would you prefer to accomplish this by re-opening the RP> Host-Resources-MIB, or by creating a new MIB module RP> (Host-Resources-Extensions-MIB)? I'm for whichever is most likely to make it though the process (which I suspect would be the new MIB module). RP> In either case, if there turns out to be sufficient interest in taking RP> this on as a WG item, I'd be willing to edit, if needed. I will review.. Robert -- Senior Software Engineer SPARTA, Inc., a Parsons Company --Sig_/qW9JYbrVD5HUN=bcjx5Zi4B Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBXl/wACgkQ7/fVLLY1mnjy6gCdEQiCQFAEZwfINgPZHu7aPCc9 OicAn1tdgsP7UQa6J/Piznd1Xr8ra9qz =1zCi -----END PGP SIGNATURE----- --Sig_/qW9JYbrVD5HUN=bcjx5Zi4B-- From j.schoenwaelder@jacobs-university.de Mon Sep 17 14:53:11 2012 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 4D54821E8063 for ; Mon, 17 Sep 2012 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdSdtrhlVEOf for ; Mon, 17 Sep 2012 14:53: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 98AB621E8053 for ; Mon, 17 Sep 2012 14:53:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B931820C06; Mon, 17 Sep 2012 23:53:09 +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 ovXywtnjGUu3; Mon, 17 Sep 2012 23:53:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 297B4207E0; Mon, 17 Sep 2012 23:53:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 46CC721C9204; Mon, 17 Sep 2012 23:53:04 +0200 (CEST) Date: Mon, 17 Sep 2012 23:53:04 +0200 From: Juergen Schoenwaelder To: Robert Story Message-ID: <20120917215304.GA18904@elstar.local> Mail-Followup-To: Robert Story , Randy Presuhn , OPSAWG References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> <20120917173655.49e75ae0@tp.vb.futz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120917173655.49e75ae0@tp.vb.futz.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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: Mon, 17 Sep 2012 21:53:11 -0000 On Mon, Sep 17, 2012 at 05:36:55PM -0400, Robert Story wrote: > On Mon, 17 Sep 2012 11:36:46 -0700 Randy wrote: > RP> Would you prefer to accomplish this by re-opening the > RP> Host-Resources-MIB, or by creating a new MIB module > RP> (Host-Resources-Extensions-MIB)? > > I'm for whichever is most likely to make it though the process (which I > suspect would be the new MIB module). Both options have a defined process. Before deciding, I suggest to find agreement on the additions that are needed. It now sounds like it is not just one object anymore... ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rstory@tislabs.com Mon Sep 17 15:33:09 2012 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 44EBD21E808C for ; Mon, 17 Sep 2012 15:33:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxi8eusCEghz for ; Mon, 17 Sep 2012 15:33:08 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id C332821E8063 for ; Mon, 17 Sep 2012 15:33:08 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 738EE28B003C; Mon, 17 Sep 2012 18:33:08 -0400 (EDT) Received: from tp.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 4332B1F8032; Mon, 17 Sep 2012 18:33:07 -0400 (EDT) Date: Mon, 17 Sep 2012 18:32:58 -0400 From: Robert Story To: Juergen Schoenwaelder Message-ID: <20120917183258.624a695a@tp.vb.futz.org> In-Reply-To: <20120917215304.GA18904@elstar.local> References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> <20120917173655.49e75ae0@tp.vb.futz.org> <20120917215304.GA18904@elstar.local> Organization: SPARTA X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.8; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/FB40HwspGL5Q1nlFsWVBYRs"; protocol="application/pgp-signature" Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 22:33:09 -0000 --Sig_/FB40HwspGL5Q1nlFsWVBYRs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 17 Sep 2012 23:53:04 +0200 Juergen wrote: JS> Both options have a defined process. Before deciding, I suggest to JS> find agreement on the additions that are needed. It now sounds like JS> it is not just one object anymore... ;-) Indeed.. some other objects we might want to consider: augment hrDiskStorageTable - hrDiskStorageCapacityHC (current KBytes not big enough for TB drives) augment hrPartitionTable - hrPartitionSizeHC (current KBytes not big enough for TB drives) I don't know if we also want to consider hrMemorySizeHC and hrSWRunPerfMemH= C. How far off are systems with terrabytes of memory? Robert -- Senior Software Engineer SPARTA, Inc., a Parsons Company --Sig_/FB40HwspGL5Q1nlFsWVBYRs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlBXpSMACgkQ7/fVLLY1mngHoQCgltdE85bTPpTMZnHQOCmYtYA+ xX8An1rhAESCWxOl3yeSgmGvyNIdtn/u =kz3q -----END PGP SIGNATURE----- --Sig_/FB40HwspGL5Q1nlFsWVBYRs-- From wjhns1@hardakers.net Mon Sep 17 16:22:02 2012 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 8609221E808C for ; Mon, 17 Sep 2012 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8Gg0GSLRERE for ; Mon, 17 Sep 2012 16:22:02 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5AA21E8063 for ; Mon, 17 Sep 2012 16:22:02 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:b838:9baf:a3d1:1beb]) by mail.hardakers.net (Postfix) with ESMTPSA id 4AAF156; Mon, 17 Sep 2012 16:22:00 -0700 (PDT) From: Wes Hardaker To: "Randy Presuhn" References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> Date: Mon, 17 Sep 2012 16:22:00 -0700 In-Reply-To: <003601cd9503$655f5740$6b01a8c0@oemcomputer> (Randy Presuhn's message of "Mon, 17 Sep 2012 11:36:46 -0700") Message-ID: <0ld31kme07.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: OPSAWG Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 17 Sep 2012 23:22:02 -0000 "Randy Presuhn" writes: > Would you prefer to accomplish this by re-opening the Host-Resources-MIB, > or by creating a new MIB module (Host-Resources-Extensions-MIB)? I'd like a new MIB that drops the new objects into the existing structures :-) But... there is no precedence for that. -- Wes Hardaker SPARTA, Inc. From mrm@vmware.com Mon Sep 17 20:18:35 2012 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 D63F221E80A4 for ; Mon, 17 Sep 2012 20:18:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtZbmSb3lqgK for ; Mon, 17 Sep 2012 20:18:35 -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 73AF321E80A0 for ; Mon, 17 Sep 2012 20:18:35 -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 C4B5E287CF; Mon, 17 Sep 2012 20:18:34 -0700 (PDT) Received: from zcs-prod-mta-3.vmware.com (zcs-prod-mta-3.vmware.com [10.113.163.65]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id C0BCE1854B; Mon, 17 Sep 2012 20:18:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-3.vmware.com (Postfix) with ESMTP id 190C6E29B9; Mon, 17 Sep 2012 20:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at zcs-prod-mta-3.vmware.com Received: from zcs-prod-mta-3.vmware.com ([127.0.0.1]) by localhost (zcs-prod-mta-3.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gUi1O1l5QSb; Mon, 17 Sep 2012 20:18:28 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-3.vmware.com (Postfix) with ESMTP id EC0F2E29B4; Mon, 17 Sep 2012 20:18:27 -0700 (PDT) Date: Mon, 17 Sep 2012 20:18:34 -0700 (PDT) From: Michael MacFaden To: OPSAWG Message-ID: <1429670842.44895456.1347938314532.JavaMail.root@vmware.com> In-Reply-To: <0lobl4zj50.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 18 Sep 2012 03:18:36 -0000 > FYI, I support the standardization of additional objects to the HR > mib. There are a number of requests I've heard over time that have needed > toadd additions to the HR mib, and this is really just one of a few. I second Wes call to fix RFC 2790. Having implemented that mib last year, saw a number of objects now showing their age. here's two examples: 1. If one pxe boot an OS, then its possible for hrSystemInitialLoadParameters.0 to be truncated HOST-RESOURCES-MIB::hrSystemInitialLoadParameters.0 = STRING: "/mts/dbc2-c/mrm/pxe//t-bad88fe832d9130c4d88/CUR-visor-x64-26-obj/vmkboot.gz BOOTIF=01-00-30-48-7c-fb-20 debugLogToSerial=1 pxebo" 2. If one has disks larger than max int32, then hrDiskStorageCapacity reports incorrectly, see either agents show a negative value or latch at int32_t max. HOST-RESOURCES-MIB::hrDiskStorageCapacity.33 = INTEGER: -2147483648 KBytes # 2 TB disk Mike MacFaden Staff Engineer, R&D Apps, Palo Alto, VMware, Inc. From melinda.shore@gmail.com Mon Sep 17 20:23:55 2012 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 A37A721F84E1 for ; Mon, 17 Sep 2012 20:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpShf9Dq4S8w for ; Mon, 17 Sep 2012 20:23:55 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B43621F84DF for ; Mon, 17 Sep 2012 20:23:55 -0700 (PDT) Received: by iec9 with SMTP id 9so2561064iec.31 for ; Mon, 17 Sep 2012 20:23:54 -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=Q9wnTDMv43H7gTB7t4PEV5Yh1u3kI49bJzzapONA/yI=; b=X7CQmZ/xd7Tq5pg0IWkbQ/vW96vqIDIj/Vf5iSwB3SlW8a4NiitMQk7uCAX7GiPOCA JwhXcyDP1Q7WxCS3Ud3Az01DWlfYlZUfv1tryWnrsRgIjvHzpZDwcqvEYaHRiXxFn+5M ElAQmsKMF5RLBsDdxM3xnqV0yMFVtKHSFGa0TPPNdjz+wbJpeGv6jTix4mxuL4BCWbfP c2XOBW5DzVccjpa2Zz2QvpF29YAJvHtgm9+T7rsJccJN8oHw8v51bhtvwdrl1e2Q7RFl tLzj8ukWjB8CSyVromls3vjh0lJKuQdWvHxrmRsvtDpPjEc9DjKFaRSLr7uAsrinxVeG HO5Q== Received: by 10.42.180.201 with SMTP id bv9mr10600532icb.43.1347938634542; Mon, 17 Sep 2012 20:23:54 -0700 (PDT) Received: from spandex.local (66-230-86-185-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.86.185]) by mx.google.com with ESMTPS id ua5sm9221723igb.10.2012.09.17.20.23.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Sep 2012 20:23:54 -0700 (PDT) Message-ID: <5057E947.2080603@gmail.com> Date: Mon, 17 Sep 2012 19:23:51 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer> <0ld31ri515.fsf@wjh.hardakers.net> <001f01cd9115$04a252a0$6b01a8c0@oemcomputer> <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> <20120917173655.49e75ae0@tp.vb.futz.org> <20120917215304.GA18904@elstar.local> In-Reply-To: <20120917215304.GA18904@elstar.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 18 Sep 2012 03:23:55 -0000 On 9/17/12 1:53 PM, Juergen Schoenwaelder wrote: > Both options have a defined process. Before deciding, I suggest to > find agreement on the additions that are needed. It now sounds like > it is not just one object anymore... ;-) Okay, it sounds as if there's sufficient interest to have a discussion. Does someone want to work with Sheppy on getting an initial problem description and possibly a proposal written up? Melinda From ietfc@btconnect.com Tue Sep 18 01:51:31 2012 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 4401021F8792 for ; Tue, 18 Sep 2012 01:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.901 X-Spam-Level: X-Spam-Status: No, score=-4.901 tagged_above=-999 required=5 tests=[AWL=1.698, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSYX1xwq9Oka for ; Tue, 18 Sep 2012 01:51:30 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7721F878B for ; Tue, 18 Sep 2012 01:51:30 -0700 (PDT) Received: from mail253-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.23; Tue, 18 Sep 2012 08:51:29 +0000 Received: from mail253-va3 (localhost [127.0.0.1]) by mail253-va3-R.bigfish.com (Postfix) with ESMTP id 0AEB6F000C1; Tue, 18 Sep 2012 08:51:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432Izz1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h1288h12a5h12a9h12bdh304l1155h) Received: from mail253-va3 (localhost.localdomain [127.0.0.1]) by mail253-va3 (MessageSwitch) id 1347958287648146_31223; Tue, 18 Sep 2012 08:51:27 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.252]) by mail253-va3.bigfish.com (Postfix) with ESMTP id 9C0EF1A40042; Tue, 18 Sep 2012 08:51:27 +0000 (UTC) Received: from AM2PRD0710HT004.eurprd07.prod.outlook.com (157.56.249.213) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 18 Sep 2012 08:51:25 +0000 Received: from CH1PRD0710HT002.namprd07.prod.outlook.com (157.56.245.5) by pod51017.outlook.com (10.255.165.39) with Microsoft SMTP Server (TLS) id 14.16.190.9; Tue, 18 Sep 2012 08:51:19 +0000 Message-ID: <015001cd957a$d7ed1500$4001a8c0@gateway.2wire.net> From: t.petch To: Melinda Shore , References: <001901cd905a$7cdfa3a0$6b01a8c0@oemcomputer><0ld31ri515.fsf@wjh.hardakers.net><001f01cd9115$04a252a0$6b01a8c0@oemcomputer><0ly5kddckm.fsf@wjh.hardakers.net><50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net><003601cd9503$655f5740$6b01a8c0@oemcomputer><20120917173655.49e75ae0@tp.vb.futz.org><20120917215304.GA18904@elstar.local> <5057E947.2080603@gmail.com> Date: Tue, 18 Sep 2012 09:51:42 +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.245.5] X-OriginatorOrg: btconnect.com Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 18 Sep 2012 08:51:31 -0000 If change is to be made, I would like it to be an updated, Standards track MIB module, rather than a patch of any shape or form. I would be happy to help with the reviewing of it. I am a user of the HR MIB module rather than implementer. Tom Petch ----- Original Message ----- From: "Melinda Shore" To: Sent: Tuesday, September 18, 2012 4:23 AM Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB > On 9/17/12 1:53 PM, Juergen Schoenwaelder wrote: > > Both options have a defined process. Before deciding, I suggest to > > find agreement on the additions that are needed. It now sounds like > > it is not just one object anymore... ;-) > > Okay, it sounds as if there's sufficient interest to have a discussion. > Does someone want to work with Sheppy on getting an initial problem > description and possibly a proposal written up? > > Melinda From j.schoenwaelder@jacobs-university.de Tue Sep 18 03:09:21 2012 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 1122A21E8043 for ; Tue, 18 Sep 2012 03:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.262, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaDCRvU81PoL for ; Tue, 18 Sep 2012 03:09:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB48521E8064 for ; Tue, 18 Sep 2012 03:09:19 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC32620BFE; Tue, 18 Sep 2012 12:09:17 +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 3BMnGUDEy2_Q; Tue, 18 Sep 2012 12:09:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CAA520BE2; Tue, 18 Sep 2012 12:09:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 95F1721C9E39; Tue, 18 Sep 2012 12:09:12 +0200 (CEST) Date: Tue, 18 Sep 2012 12:09:12 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20120918100912.GA20006@elstar.local> Mail-Followup-To: "t.petch" , Melinda Shore , opsawg@ietf.org References: <0ly5kddckm.fsf@wjh.hardakers.net> <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> <20120917173655.49e75ae0@tp.vb.futz.org> <20120917215304.GA18904@elstar.local> <5057E947.2080603@gmail.com> <015001cd957a$d7ed1500$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015001cd957a$d7ed1500$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 18 Sep 2012 10:09:21 -0000 On Tue, Sep 18, 2012 at 09:51:42AM +0100, t.petch wrote: > If change is to be made, I would like it to be an updated, Standards > track MIB module, rather than a patch of any shape or form. I would be > happy to help with the reviewing of it. I am a user of the HR MIB module > rather than implementer. > Same here. What I heard so far and what I consider useful as well: - Updates to add high capacity counters that are needed for todays storage and memory sizes. - Additional counters that deal with the notion of reserved space in various file systems. - Some boot parameters limitations. - We may want to extend hrDiskStorageMedia or even make it IANA controlled. - Perhaps it makes sense to add hrSWRunPerfVirtualMem since hrSWRunPerfMem seems to report only the resident memory of a process. Perhaps it also makes sense to add hrSWRunPerfSharedMem. - And of course, having a common notion of system load averages would be useful since this is something we always have to dig out of proprietary MIBs. Anyway, I am planning to add support for any of these to the scli program once there is an agent supporting these extensions I can test against. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Sep 19 03:04:36 2012 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 A1E5F21F86BA for ; Wed, 19 Sep 2012 03:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XpyzlJiWrzQ for ; Wed, 19 Sep 2012 03:04:26 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 99C0521F8669 for ; Wed, 19 Sep 2012 03:04:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMeXWVDGmAcF/2dsb2JhbABCA7xMgQiCIAEBAQEDAQEBDx4KNAsMAgICAQgNAQIBBAEBAQoGDAsBBgEaDB8JCAEBBAESCBqHXgudRZ0cBIsYIIJ9gkRgA5tmih+CaIFZ X-IronPort-AV: E=Sophos;i="4.80,448,1344225600"; d="scan'208";a="27573101" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 19 Sep 2012 05:58:18 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Sep 2012 05:57:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Sep 2012 12:04:23 +0200 Message-ID: In-Reply-To: <20120918100912.GA20006@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Addition of Available Space to Host-Resources-MIB Thread-Index: Ac2Vha55T5kJLqZhTFOhMuVh3jNeuAAyDX2g References: <0ly5kddckm.fsf@wjh.hardakers.net><50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net><003601cd9503$655f5740$6b01a8c0@oemcomputer><20120917173655.49e75ae0@tp.vb.futz.org><20120917215304.GA18904@elstar.local> <5057E947.2080603@gmail.com><015001cd957a$d7ed1500$4001a8c0@gateway.2wire.net> <20120918100912.GA20006@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "t.petch" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-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, 19 Sep 2012 10:04:36 -0000 All these seem useful extensions.=20 I am willing to be a reviewer as well if this work is chartered.=20 Question to Juergen - what would be a (rough) definition for the hrSWRunPerfVirtualMem object?=20 Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Juergen Schoenwaelder > Sent: Tuesday, September 18, 2012 1:09 PM > To: t.petch > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Addition of Available Space to Host-Resources-MIB >=20 > On Tue, Sep 18, 2012 at 09:51:42AM +0100, t.petch wrote: > > If change is to be made, I would like it to be an updated, Standards > > track MIB module, rather than a patch of any shape or form. I would be > > happy to help with the reviewing of it. I am a user of the HR MIB > > module rather than implementer. > > >=20 > Same here. What I heard so far and what I consider useful as well: >=20 > - Updates to add high capacity counters that are needed for todays > storage and memory sizes. >=20 > - Additional counters that deal with the notion of reserved space in > various file systems. >=20 > - Some boot parameters limitations. >=20 > - We may want to extend hrDiskStorageMedia or even make it IANA > controlled. >=20 > - Perhaps it makes sense to add hrSWRunPerfVirtualMem since > hrSWRunPerfMem seems to report only the resident memory of a > process. Perhaps it also makes sense to add hrSWRunPerfSharedMem. >=20 > - And of course, having a common notion of system load averages would > be useful since this is something we always have to dig out of > proprietary MIBs. >=20 > Anyway, I am planning to add support for any of these to the scli > program once there is an agent supporting these extensions I can test > against. >=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 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Wed Sep 19 03:33:06 2012 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 91EA721F8665 for ; Wed, 19 Sep 2012 03:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFgXobiX6ash for ; Wed, 19 Sep 2012 03:33:06 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E28C721F8611 for ; Wed, 19 Sep 2012 03:33:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0749B20BEC; Wed, 19 Sep 2012 12:33: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 QrsghEOoCxNw; Wed, 19 Sep 2012 12:33: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 69F3220C31; Wed, 19 Sep 2012 12:33:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6BCC821D58A2; Wed, 19 Sep 2012 12:32:57 +0200 (CEST) Date: Wed, 19 Sep 2012 12:32:57 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120919103256.GA38938@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "t.petch" , opsawg@ietf.org References: <50537923.2040509@gmail.com> <0lobl4zj50.fsf@wjh.hardakers.net> <003601cd9503$655f5740$6b01a8c0@oemcomputer> <20120917173655.49e75ae0@tp.vb.futz.org> <20120917215304.GA18904@elstar.local> <5057E947.2080603@gmail.com> <015001cd957a$d7ed1500$4001a8c0@gateway.2wire.net> <20120918100912.GA20006@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] Addition of Available Space to Host-Resources-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: Wed, 19 Sep 2012 10:33:06 -0000 On Wed, Sep 19, 2012 at 12:04:23PM +0200, Romascanu, Dan (Dan) wrote: > All these seem useful extensions. > > I am willing to be a reviewer as well if this work is chartered. > > Question to Juergen - what would be a (rough) definition for the > hrSWRunPerfVirtualMem object? Something like this: hrSWRunPerfVirtualMem OBJECT-TYPE SYNTAX KBytes UNITS "KBytes" MAX-ACCESS read-only STATUS current DESCRIPTION "The total amount of virtual memory allocated to this process." ::= { hrSWRunPerfEntry 3 } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ccie15672@yahoo.com Mon Sep 24 22:56:53 2012 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 5422E21F8942 for ; Mon, 24 Sep 2012 22:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.722 X-Spam-Level: **** X-Spam-Status: No, score=4.722 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, MPART_ALT_DIFF=0.739, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaN2lNUtWgJW for ; Mon, 24 Sep 2012 22:56:52 -0700 (PDT) Received: from nm19-vm3.bullet.mail.ne1.yahoo.com (nm19-vm3.bullet.mail.ne1.yahoo.com [98.138.91.149]) by ietfa.amsl.com (Postfix) with SMTP id 467EE21F893E for ; Mon, 24 Sep 2012 22:56:52 -0700 (PDT) Received: from [98.138.90.54] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 05:56:45 -0000 Received: from [98.138.89.195] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 05:56:45 -0000 Received: from [127.0.0.1] by omp1053.mail.ne1.yahoo.com with NNFMP; 25 Sep 2012 05:56:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 310187.82982.bm@omp1053.mail.ne1.yahoo.com Received: (qmail 2578 invoked by uid 60001); 25 Sep 2012 05:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1348552605; bh=5cAYnJIZfH4AwoPkRyI0wm7kpwt8rLW9OrVmoSMxIyQ=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=0aXSkW7nG/mjGBfHYliOWkAZbynnqFiHna7wj2iqza0nJbeVHaT99xpucuir/I+6Q1PkTZmAPN8SLi3nLrQNgWuebdhh2TWku7BAldQuym45n+papYTl1/IeB279LZgR1cD1AIP9uBKW3jnezwLu1GbMK4wvQ/aLwKJ3KjeUk0s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=HSAIzsDubuaWXk0lSwF71o4srePI3pD5fZYQYIslAkdcpUtusg2wB9s382yJAGqHkBd3FrXtrpINTFzv5NL6ISwqB1f1G8tQ+fM3z8ARt9TFJxHQLEH+VTD01qTgO3+lYRp7pONt/YMLx6eWQEHjEyCYtpSJfZYGZt4wpUrE6CQ=; X-YMail-OSG: xBAgSXsVM1mitzvgAl56huwOVsXISNXo_qrq_bnI9i88xve LzT4jL1ZIYJ.QdOK0G.rdtcelU1lE2nm2wMTeZ3hx11nfFHZdcJkrM5mVFtr Gs3w5vUumZwU207SJDN0SlXim8r9MRC3Bc1oQCXy3IRKkc91i0fIgzOli5dn 7iGycEjDfMblQuBt4QWZD1.SFSXdfi8WylSinLjEcYbspuUnpD9OdK7DHZV2 9ydmUd7bOFT14ydS7MZbTZu9EfbETWnk5pOzZ2vRTYfv3R0CRO4pTJtsNxsx HZGenO0ObV5w9reWWuZ0ry1e16X6K0fFAlEw_mWmULpgXaWqi0uT2HXo8pZw hEyipcN.hbbPeqGnwkazCFG6TGxHUYYejOo5tdTNaQgS5UHGD_nx1_Le7Iq5 zi1P7gOIATwABJoDNN..xcZOJJbQAN0RYPYi7NAAS6CoHkronL.Ao1jceneR QSEa3ImIjHMGejMwnN2E0AH8G_yQVJBkBhY76.liOPjQYjRo9MacYOBPsudn TvjCTd6QKULJBzjVVfRQ0ZzA3SBqUDgpfvNW3.esvIIL0rMdL90JWc5Xzab2 9rSttkJ52DtUV1p4158VhxBcl9j2wIttpXyhx4bnbf3uXApZUNkYC3AZnRg- - Received: from [153.129.229.99] by web125402.mail.ne1.yahoo.com via HTTP; Mon, 24 Sep 2012 22:56:44 PDT X-Mailer: YahooMailWebService/0.8.121.434 Message-ID: <1348552604.2438.YahooMailNeo@web125402.mail.ne1.yahoo.com> Date: Mon, 24 Sep 2012 22:56:44 -0700 (PDT) From: Derick Winkworth To: mmeiers@wi.rr.com, opsawg@ietf.org, kireeti@juniper.net, brianjwelsh@verizon.net, melmpap@yahoo.com, ip@ioshints.info, dwinkworth@att.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-108205657-241277455-1348552604=:2438" Subject: [OPSAWG] (no subject) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Derick Winkworth List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 05:56:53 -0000 ---108205657-241277455-1348552604=:2438 Content-Type: text/plain; charset=us-ascii http://zfilmz.net/wp-content/plugins/akismet/google.html?eos=ol.mig&rt=cym.wg&mbf=gogp ---108205657-241277455-1348552604=:2438 Content-Type: text/html; charset=us-ascii ---108205657-241277455-1348552604=:2438-- From ramk@Brocade.com Tue Sep 25 10:10:40 2012 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 381281F0CC9 for ; Tue, 25 Sep 2012 10:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJo8W2sWnPdF for ; Tue, 25 Sep 2012 10:10:39 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id C0FAA1F0C82 for ; Tue, 25 Sep 2012 10:10:39 -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 q8PH9WGQ012879; Tue, 25 Sep 2012 10:10:36 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 17k1pwre3v-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2012 10:10:36 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 25 Sep 2012 10:10:37 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Tue, 25 Sep 2012 10:10:24 -0700 From: ramki Krishnan To: Scott Bradner , Chris Liljenstolpe , Melinda Shore Date: Tue, 25 Sep 2012 10:10:20 -0700 Thread-Topic: new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4F457E67HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-25_05:2012-09-25, 2012-09-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1209250189 Cc: Sanjay Khanna , "opsawg@ietf.org" Subject: [OPSAWG] new IETF draft - large flow load-balancing 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, 25 Sep 2012 17:10:40 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F457E67HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, A new IETF draft on large flow load-balancing has been posted. We have very= good feedback so far from Shane Amante; your comments would be much apprec= iated. http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Thanks, ram --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F457E67HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

A new IETF draft on large flow load-balancing has been posted. We have ve= ry good feedback so far from Shane Amante; your comments would be much appr= eciated.

 

<= a href=3D"http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-= load-balancing/">http://datatracker.ietf.org/doc/draft-krishnan-opsawg-larg= e-flow-load-balancing/

 

Thanks, ram

= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F457E67HQ1EXCH01corp_-- From ramk@Brocade.com Tue Sep 25 20:43:00 2012 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 ABF6D1F0CD3 for ; Tue, 25 Sep 2012 20:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xti2n58h8rtn for ; Tue, 25 Sep 2012 20:42:59 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id E44011F0CBB for ; Tue, 25 Sep 2012 20:42:58 -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 q8Q3f876008745; Tue, 25 Sep 2012 20:42:54 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 17k9warhud-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 25 Sep 2012 20:42:54 -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.2.309.2; Tue, 25 Sep 2012 20:42:55 -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, 25 Sep 2012 20:42:54 -0700 From: ramki Krishnan To: Scott Bradner , Chris Liljenstolpe , Melinda Shore , "opsawg@ietf.org" Date: Tue, 25 Sep 2012 20:42:49 -0700 Thread-Topic: new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4F458158HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-26_01:2012-09-25, 2012-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1209250398 Cc: Sanjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 26 Sep 2012 03:43:00 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F458158HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Best Practices for Optimal LAG/ECMP Component Link Utilization in Provider = Backbone networks - Key ideas The suggested techniques in this draft for optimal LAG/ECMP component link = utilization are meant to put forth a locally optimized solution, i.e. local= in the sense of both measuring and optimizing for long-lived large flows a= t individual nodes in the network. This approach would not yield a globally= optimal placement of a large, long-lived flow across several nodes in the = network which some networks may desire/require. On the other hand, this may= be adequate for some operators for the following reasons 1) Different link= s in the network experience different levels of utilization and, thus, a mo= re "targeted" solution is needed for those few hot-spots in the network 2) = Some networks may lack end-to-end visibility. Areas which need further discussion Standards-based data model for exporting long-lived large flow information = from routers to a central management entity. Your comments/feedback would be much appreciated. Thanks, ramki From: ramki Krishnan Sent: Tuesday, September 25, 2012 10:10 AM To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Melinda Shore' Cc: Sanjay Khanna; 'opsawg@ietf.org' Subject: new IETF draft - large flow load-balancing All, A new IETF draft on large flow load-balancing has been posted. We have very= good feedback so far from Shane Amante; your comments would be much apprec= iated. http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Thanks, ram --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F458158HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,<= /p>

 

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

 

Best Practices fo= r Optimal LAG/ECMP Component Link Utilization in Provider Backbone networks= – Key ideas

The suggested= techniques in this draft for optimal LAG/ECMP component link utilization a= re meant to put forth a locally optimized solution, i.e. local in the sense= of both measuring and optimizing for long-lived large flows at individual = nodes in the network. This approach would not yield a globally optimal plac= ement of a large, long-lived flow across several nodes in the network which= some networks may desire/require. On the other hand, this may be adequate = for some operators for the following reasons 1) Different links in the netw= ork experience different levels of utilization and, thus, a more "targ= eted" solution is needed for those few hot-spots in the network 2) Som= e networks may lack end-to-end visibility.

 

Areas which need further= discussion

Standards-based data= model for exporting long-lived large flow information from routers to a ce= ntral management entity.

 

Your comments/feedback would be much appreciated= .

 

Thanks, ramki

 

From: ramki Krishnan
Sent: Tuesday, Septem= ber 25, 2012 10:10 AM
To: 'Scott Bradner'; 'Chris Liljenstolpe'; = 'Melinda Shore'
Cc: Sanjay Khanna; 'opsawg@ietf.org'
Subjec= t: new IETF draft - large flow load-balancing

 

All,

&nbs= p;

A new IETF draft on large flow load-balancing has been posted= . We have very good feedback so far from Shane Amante; your comments would = be much appreciated.

 

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

 <= /p>

Th= anks, ram

= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F458158HQ1EXCH01corp_-- From prvs=461619d1b7=phe@ciena.com Wed Sep 26 06:29:12 2012 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 AF54821F8692 for ; Wed, 26 Sep 2012 06:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZP3EMpEhJKc0 for ; Wed, 26 Sep 2012 06:29:10 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id C70E821F866D for ; Wed, 26 Sep 2012 06:29:10 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.4/8.14.4) with SMTP id q8QDOuBq008407; Wed, 26 Sep 2012 09:29:05 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 17m1cc082w-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 26 Sep 2012 09:29:04 -0400 Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Wed, 26 Sep 2012 09:29:05 -0400 From: "He, Peng" To: ramki Krishnan , Scott Bradner , Chris Liljenstolpe , Melinda Shore , "opsawg@ietf.org" Date: Wed, 26 Sep 2012 09:29:03 -0400 Thread-Topic: new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtAAFCDHoA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-19212.001 x-tm-as-result: No--34.879000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_BD3B1D969FA2704CA817A3A07F3E17CC0114B7F8C7MDWEXGMB02cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-26_04:2012-09-26, 2012-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209260118 Cc: Sanjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 26 Sep 2012 13:29:12 -0000 --_000_BD3B1D969FA2704CA817A3A07F3E17CC0114B7F8C7MDWEXGMB02cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ramki, When talking about LAG, is this the IEEE LAG (802.1ax, or the previous IEEE= 802.3ad) running LACP, or something else? If it is L2 LAG, then how a L3 r= outer can decide which component link in the LAG to send traffic. Long-lived flow/short-lived flows, or long holding-time flows/short holding= -time flows, are sort of relative concepts. Usually how 'longer' a flow com= pared to 'short lived' flows can be defined as a long lived flow. this migh= t be too practical, as it could be different to different networks and traf= fic characteristics. Regards, Peng From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= ramki Krishnan Sent: Tuesday, September 25, 2012 11:43 PM To: Scott Bradner; Chris Liljenstolpe; Melinda Shore; opsawg@ietf.org Cc: Sanjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing All, http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Best Practices for Optimal LAG/ECMP Component Link Utilization in Provider = Backbone networks - Key ideas The suggested techniques in this draft for optimal LAG/ECMP component link = utilization are meant to put forth a locally optimized solution, i.e. local= in the sense of both measuring and optimizing for long-lived large flows a= t individual nodes in the network. This approach would not yield a globally= optimal placement of a large, long-lived flow across several nodes in the = network which some networks may desire/require. On the other hand, this may= be adequate for some operators for the following reasons 1) Different link= s in the network experience different levels of utilization and, thus, a mo= re "targeted" solution is needed for those few hot-spots in the network 2) = Some networks may lack end-to-end visibility. Areas which need further discussion Standards-based data model for exporting long-lived large flow information = from routers to a central management entity. Your comments/feedback would be much appreciated. Thanks, ramki From: ramki Krishnan Sent: Tuesday, September 25, 2012 10:10 AM To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Melinda Shore' Cc: Sanjay Khanna; 'opsawg@ietf.org' Subject: new IETF draft - large flow load-balancing All, A new IETF draft on large flow load-balancing has been posted. We have very= good feedback so far from Shane Amante; your comments would be much apprec= iated. http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Thanks, ram --_000_BD3B1D969FA2704CA817A3A07F3E17CC0114B7F8C7MDWEXGMB02cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ramki,

 

When talking about LAG, is this the IEEE LAG (802.1a= x, or the previous IEEE 802.3ad) running LACP, or something else? If it is = L2 LAG, then how a L3 router can decide which component link in the LAG to = send traffic.

 

Long-lived flow/short-lived flows, or long holding-time flow= s/short holding-time flows, are sort of relative concepts. Usually how R= 16;longer’ a flow compared to ‘short lived’ flows can be = defined as a long lived flow. this might be too practical, as it could be d= ifferent to different networks and traffic characteristics.

 <= /span>

 

Regards,

Peng=

 

 

From: opsawg= -bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of ramk= i Krishnan
Sent: Tuesday, September 25, 2012 11:43 PM
To: Scott Bradner; Chris Liljenstolpe; Melinda Shore; opsawg@ietf.org
= Cc: Sanjay Khanna
Subject: Re: [OPSAWG] new IETF draft - larg= e flow load-balancing

 

All,

 

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

 

Best Practices for Optimal LAG/ECMP= Component Link Utilization in Provider Backbone networks – Key ideas=

The suggested techniques in thi= s draft for optimal LAG/ECMP component link utilization are meant to put fo= rth a locally optimized solution, i.e. local in the sense of both measuring= and optimizing for long-lived large flows at individual nodes in the netwo= rk. This approach would not yield a globally optimal placement of a large, = long-lived flow across several nodes in the network which some networks may= desire/require. On the other hand, this may be adequate for some operators= for the following reasons 1) Different links in the network experience dif= ferent levels of utilization and, thus, a more "targeted" solutio= n is needed for those few hot-spots in the network 2) Some networks may lac= k end-to-end visibility.

 

Areas which need further discussion

Standards-based data model for exporti= ng long-lived large flow information from routers to a central management e= ntity.

 

Your comments/feedback would be much appreciated.

 

Thanks, ramki<= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'>

 

From: ramki Krishnan
Sent: Tuesday, September 25, 2012 10:10= AM
To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Melinda Shore'Cc: Sanjay Khanna; 'opsawg@ietf.org'
Subject: new IETF dr= aft - large flow load-balancing

 

All,

 <= /p>

A = new IETF draft on large flow load-balancing has been posted. We have very g= ood feedback so far from Shane Amante; your comments would be much apprecia= ted.

 

http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-fl= ow-load-balancing/

 

Thanks, ram

= --_000_BD3B1D969FA2704CA817A3A07F3E17CC0114B7F8C7MDWEXGMB02cie_-- From ramk@Brocade.com Wed Sep 26 09:42:39 2012 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 2591F21F852A for ; Wed, 26 Sep 2012 09:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N23Jykez1ePT for ; Wed, 26 Sep 2012 09:42:36 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2CE21F8595 for ; Wed, 26 Sep 2012 09:42:36 -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 q8QGfVSm030599; Wed, 26 Sep 2012 09:42:32 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 17k9warw30-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 26 Sep 2012 09:42:32 -0700 Received: from HQ1WP-EXHUB01.corp.brocade.com (10.70.36.14) by hq1wp-exchub02.corp.brocade.com (10.70.38.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 26 Sep 2012 09:42:33 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 26 Sep 2012 09:42:30 -0700 From: ramki Krishnan To: "He, Peng" , Scott Bradner , "Chris Liljenstolpe" , Melinda Shore , "opsawg@ietf.org" Date: Wed, 26 Sep 2012 09:42:26 -0700 Thread-Topic: new IETF draft - large flow load-balancing Thread-Index: Ac2av6rrKUaKQo5ATLKGesZWpiOTUwAgOoQQABXWhtAAFCDHoAAGx/uQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7634EB63EFD984A978DFB46EA5174F2BF4F4581FCHQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-26_04:2012-09-26, 2012-09-26, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1209260180 Cc: Sanjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 26 Sep 2012 16:42:39 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F4581FCHQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peng, Thanks for the comments. Please find answers inline. Thanks, ramki From: He, Peng [mailto:phe@ciena.com] Sent: Wednesday, September 26, 2012 6:29 AM To: ramki Krishnan; Scott Bradner; Chris Liljenstolpe; Melinda Shore; opsaw= g@ietf.org Cc: Sanjay Khanna Subject: RE: new IETF draft - large flow load-balancing Ramki, When talking about LAG, is this the IEEE LAG (802.1ax, or the previous IEEE= 802.3ad) running LACP, or something else? If it is L2 LAG, then how a L3 r= outer can decide which component link in the LAG to send traffic. [ramki Krishnan] This is IEEE LAG running LACP. Today's Layer 3 routers alw= ays support Layer 2; in other words, a Layer 3 router is also a Layer 2 swi= tch besides being a router. Maybe, I will explicitly clarify this in the dr= aft to avoid ambiguity. Long-lived flow/short-lived flows, or long holding-time flows/short holding= -time flows, are sort of relative concepts. Usually how 'longer' a flow com= pared to 'short lived' flows can be defined as a long lived flow. this migh= t be too practical, as it could be different to different networks and traf= fic characteristics. [ramki Krishnan] Our recommendation in the draft is to make the following p= arameters programmable in the router by the Operator - 1) The minimum time = for which a flow has to be active to deem it a candidate long-lived large f= low. 2) The minimum number of packets during the previously defined time in= terval. The above parameters will translate to a minimum long-lived large f= low rate. This will help addresses various deployment scenarios/application= s. Regards, Peng From: opsawg-bounces@ietf.org [mailto:opsaw= g-bounces@ietf.org] On Behalf Of ramki Krishnan Sent: Tuesday, September 25, 2012 11:43 PM To: Scott Bradner; Chris Liljenstolpe; Melinda Shore; opsawg@ietf.org Cc: Sanjay Khanna Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing All, http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Best Practices for Optimal LAG/ECMP Component Link Utilization in Provider = Backbone networks - Key ideas The suggested techniques in this draft for optimal LAG/ECMP component link = utilization are meant to put forth a locally optimized solution, i.e. local= in the sense of both measuring and optimizing for long-lived large flows a= t individual nodes in the network. This approach would not yield a globally= optimal placement of a large, long-lived flow across several nodes in the = network which some networks may desire/require. On the other hand, this may= be adequate for some operators for the following reasons 1) Different link= s in the network experience different levels of utilization and, thus, a mo= re "targeted" solution is needed for those few hot-spots in the network 2) = Some networks may lack end-to-end visibility. Areas which need further discussion Standards-based data model for exporting long-lived large flow information = from routers to a central management entity. Your comments/feedback would be much appreciated. Thanks, ramki From: ramki Krishnan Sent: Tuesday, September 25, 2012 10:10 AM To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Melinda Shore' Cc: Sanjay Khanna; 'opsawg@ietf.org' Subject: new IETF draft - large flow load-balancing All, A new IETF draft on large flow load-balancing has been posted. We have very= good feedback so far from Shane Amante; your comments would be much apprec= iated. http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ Thanks, ram --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F4581FCHQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Peng,

 

Thanks for the comments. Pl= ease find answers inline.

 

Thanks, ramki

<= span style=3D'font-family:"Arial","sans-serif";color:#1F497D'> 

From: He, Peng [mailto:phe@= ciena.com]
Sent: Wednesday, September 26, 2012 6:29 AM
To:= ramki Krishnan; Scott Bradner; Chris Liljenstolpe; Melinda Shore; opsa= wg@ietf.org
Cc: Sanjay Khanna
Subject: RE: new IETF dra= ft - large flow load-balancing

 

Ramki,

 

When talking about LAG, is this the IEEE LAG (802.1ax, or th= e previous IEEE 802.3ad) running LACP, or something else? If it is L2 LAG, = then how a L3 router can decide which component link in the LAG to send tra= ffic.

[ramki Krishnan] This is IEEE LAG= running LACP. Today’s Layer 3 routers always support Layer 2; in oth= er words, a Layer 3 router is also a Layer 2 switch besides being a router.= Maybe, I will explicitly clarify this in the draft to avoid ambiguity.<= o:p>

 

Long-lived flow/short-lived flows, or long holding-time flows/short holdin= g-time flows, are sort of relative concepts. Usually how ‘longer̵= 7; a flow compared to ‘short lived’ flows can be defined as a l= ong lived flow. this might be too practical, as it could be different to di= fferent networks and traffic characteristics.

[ramki Krishnan] Our recommendation in the draft is to make the foll= owing parameters programmable in the router by the Operator – 1) The = minimum time for which a flow has to be active to deem it a candidate long-= lived large flow. 2) The minimum number of packets during the previously de= fined time interval. The above parameters will translate to a minimum long-= lived large flow rate. This will help addresses various deployment scenario= s/applications.

 

Regards,

Peng

 

 

<= p class=3DMsoNormal>From: opsawg-b= ounces@ietf.org [mailto:opsa= wg-bounces@ietf.org] On Behalf Of ramki Krishnan
Sent:= Tuesday, September 25, 2012 11:43 PM
To: Scott Bradner; Chris Li= ljenstolpe; Melinda Shore; opsawg@ietf.o= rg
Cc: Sanjay Khanna
Subject: Re: [OPSAWG] new IETF= draft - large flow load-balancing

 

All,

=

 

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

 

Best Practices for Opt= imal LAG/ECMP Component Link Utilization in Provider Backbone networks R= 11; Key ideas

The suggested tech= niques in this draft for optimal LAG/ECMP component link utilization are me= ant to put forth a locally optimized solution, i.e. local in the sense of b= oth measuring and optimizing for long-lived large flows at individual nodes= in the network. This approach would not yield a globally optimal placement= of a large, long-lived flow across several nodes in the network which some= networks may desire/require. On the other hand, this may be adequate for s= ome operators for the following reasons 1) Different links in the network e= xperience different levels of utilization and, thus, a more "targeted&= quot; solution is needed for those few hot-spots in the network 2) Some net= works may lack end-to-end visibility.

 

Areas which need further disc= ussion

Standards-based data mode= l for exporting long-lived large flow information from routers to a central= management entity.

 

Your comments/feedback would be much appreciated.

 

T= hanks, ramki=

 

<= p class=3DMsoNormal>From: ramki Krishnan
Sent: Tuesday, September = 25, 2012 10:10 AM
To: 'Scott Bradner'; 'Chris Liljenstolpe'; 'Mel= inda Shore'
Cc: Sanjay Khanna; 'opsawg@ietf.org'
Subject: new IETF draft - large flow load-balancing

 

All,

 

A new IETF draft on large flow load-balancing has been posted. We= have very good feedback so far from Shane Amante; your comments would be m= uch appreciated.

 

http://datatracker.ietf.org/doc/draft-krishnan-ops= awg-large-flow-load-balancing/

 

Thanks, = ram

= --_000_C7634EB63EFD984A978DFB46EA5174F2BF4F4581FCHQ1EXCH01corp_-- From ghanwani@gmail.com Thu Sep 27 13:16:43 2012 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 2D4A721F8666 for ; Thu, 27 Sep 2012 13:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdAa3gorIqul for ; Thu, 27 Sep 2012 13:16:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6285021F8658 for ; Thu, 27 Sep 2012 13:16:42 -0700 (PDT) Received: by vbbfc26 with SMTP id fc26so2677973vbb.31 for ; Thu, 27 Sep 2012 13:16:41 -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 :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Z5HzopCCRgFJq1YgDIARGidQHWuqmQIcZF1Fpe+evfQ=; b=iVN5dIJvchGLkyglA+L+uYYO8J6tvQeUfnriV3V4/9/+zpR792v75TIFQsvG2E9SgX YwMrBioT+U2QeHhADr0/MDK7CuFjh+0oPgE9L/9ICToo5Lt8nUp9nyUuOlfXxW2JyPoe UBZxScdKap06sIxlpGtT0Z0g2qdBV71Kf7e91YUYoTHBXINZZBcQVGXVzSZIIzjikCar TUEhtdP7H/4sXWeOG66mjGRFe8QFBfkNHfchX6+6Rj9H77deuOOuGBcUKoAN/MCcEF5G H2hudssfcdfgVPeI1G3LsNt0mp3AL+Z+RBEcljYJ3Z+XFrPraFRHc7j/JUndBSIvp+Ud J9vQ== MIME-Version: 1.0 Received: by 10.52.67.129 with SMTP id n1mr2352646vdt.28.1348777001856; Thu, 27 Sep 2012 13:16:41 -0700 (PDT) Sender: ghanwani@gmail.com Received: by 10.220.186.197 with HTTP; Thu, 27 Sep 2012 13:16:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Sep 2012 13:16:41 -0700 X-Google-Sender-Auth: Ws801Md9lE0q4zPmt1Y71HEv-pA Message-ID: From: Anoop Ghanwani To: ramki Krishnan Content-Type: text/plain; charset=ISO-8859-1 Cc: Sanjay Khanna , Chris Liljenstolpe , "opsawg@ietf.org" Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 27 Sep 2012 20:16:43 -0000 Ramki, Is there anything that needs to be standardized in order for someone to implement this? It sounds like this is purely an implementation issue. Anoop On Tue, Sep 25, 2012 at 10:10 AM, ramki Krishnan wrote: > All, > > > > A new IETF draft on large flow load-balancing has been posted. We have very > good feedback so far from Shane Amante; your comments would be much > appreciated. > > > > http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balancing/ > > > > Thanks, ram > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From ramk@Brocade.com Thu Sep 27 14:20:26 2012 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 73C6821F8602 for ; Thu, 27 Sep 2012 14:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhUSwI9sNCsI for ; Thu, 27 Sep 2012 14:20:25 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id A30C621F85F7 for ; Thu, 27 Sep 2012 14:20:25 -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 q8RLK2Ms011066; Thu, 27 Sep 2012 14:20:21 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 17mbqg8mm4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 27 Sep 2012 14:20:21 -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.2.309.2; Thu, 27 Sep 2012 14:20:26 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 27 Sep 2012 14:20:20 -0700 From: ramki Krishnan To: Anoop Ghanwani Date: Thu, 27 Sep 2012 14:20:14 -0700 Thread-Topic: [OPSAWG] new IETF draft - large flow load-balancing Thread-Index: Ac2c7c2rGXGmnf7xQm+vYrxPAXc0yAABhURw Message-ID: References: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.431, 0.0.0000 definitions=2012-09-27_07:2012-09-27, 2012-09-27, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1209270269 Cc: Sanjay Khanna , Chris Liljenstolpe , "opsawg@ietf.org" Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing 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, 27 Sep 2012 21:20:26 -0000 Hi Anoop, This is a best practices draft which lists various techniques and their tra= deoffs; this helps operators choose the right technique based on deployment= scenarios/applications.=20 There are also some aspects worth considering for standardization; IETF cou= ld potentially consider a standards-based activity around, say, a data-mode= l used to move long-lived large flow information from the router to a centr= al management entity. Thanks, ramki -----Original Message----- From: ghanwani@gmail.com [mailto:ghanwani@gmail.com] On Behalf Of Anoop Gha= nwani Sent: Thursday, September 27, 2012 1:17 PM To: ramki Krishnan Cc: Scott Bradner; Chris Liljenstolpe; Melinda Shore; Sanjay Khanna; opsawg= @ietf.org Subject: Re: [OPSAWG] new IETF draft - large flow load-balancing Ramki, Is there anything that needs to be standardized in order for someone to imp= lement this? It sounds like this is purely an implementation issue. Anoop On Tue, Sep 25, 2012 at 10:10 AM, ramki Krishnan wrote: > All, > > > > A new IETF draft on large flow load-balancing has been posted. We have=20 > very good feedback so far from Shane Amante; your comments would be=20 > much appreciated. > > > > http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load- > balancing/ > > > > Thanks, ram > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >