From ops-area-bounces@ietf.org Sun Dec 02 14:21:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuNX-0007zA-Lw; Sun, 02 Dec 2007 14:21:23 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IyuNW-0007yV-Js for ops-area-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 14:21:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyuNW-0007yM-8h for ops-area@ietf.org; Sun, 02 Dec 2007 14:21:22 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyuNV-0001s8-UO for ops-area@ietf.org; Sun, 02 Dec 2007 14:21:22 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="82872147" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 02 Dec 2007 14:21:21 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="130042798" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Dec 2007 14:21:16 -0500 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, 2 Dec 2007 20:21:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (maybe) final agenda for the OPSAREA meeting Thread-Index: Acg1GH+twQClTOxWTs2rec/OKWsN8A== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [OPS-AREA] (maybe) final agenda for the OPSAREA meeting X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org The agenda for the OPSAREA meeting tomorrow was just loaded. It now has time allocation.=20 We expect this to be final, unless there are any last minute changes people would require.=20 Presenters are kindly required to send us their materials prior to the meeting, so that people attending remotely have the slides in front of them while the meeting is ongoing.=20 Ron and Dan ---------------- OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica MONDAY, December 3, 2007 1740-1950 Afternoon Session III SALON A 1. Note well, agenda bashing, note takers, blue sheets - 4 min 2. Call for volunteers - IESG scribe - Dan - 1 min 2. Report from the NMRG workshop in the Netherlands (November 8-9) with the topic of SNMP trace analysis - Dan Romascanu on behalf of Juergen Schoenwaelder - 5 min 3. Reorganization and extension of the OPS Directorate - Ron Bonica - 10 min 4. Status of MIB2RDML work - Bob Natale http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt - 20 min 5. XML Schema Usage for NETCONF - Sharon Chisholm http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-07.txt - 20 min 6. Technical Discussion on the YANG data modeling language - David Partain http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt - 40 min 7. Open microphone - 30 min =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Dec 02 15:31:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyvTI-0008RJ-0c; Sun, 02 Dec 2007 15:31:24 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IyVYY-00081t-7T for ops-area-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 11:51:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyVYX-00081j-Sg; Sat, 01 Dec 2007 11:51:05 -0500 Received: from mx2.compuware.com ([12.107.188.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyVYX-00011E-Eb; Sat, 01 Dec 2007 11:51:05 -0500 Received: from nasa-dtw-ex009.nasa.cpwr.corp (unknown [10.10.0.230]) by mx2.compuware.com (Postfix) with ESMTP id 37AE42C0AD8; Sat, 1 Dec 2007 11:50:53 -0500 (EST) Importance: normal Priority: normal Received: from nasa-dtw-ex002.nasa.cpwr.corp ([10.10.1.103]) by nasa-dtw-ex009.nasa.cpwr.corp with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 11:50:53 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Dec 2007 11:50:50 -0500 Message-ID: <1169931D029E8740A3807079B0DB1F1C08A94C10@nasa-dtw-ex002.nasa.cpwr.corp> In-Reply-To: <1169931D029E8740A3807079B0DB1F1C038F8B54@nasa-dtw-ex002.nasa.cpwr.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB2RDML relevance to Eclipse COSMOS data collection Thread-Index: AcgzrEcq1MfL5vxMSzSPhzxzt3jHiwAjaPPA References: <1169931D029E8740A3807079B0DB1F1C038F8B54@nasa-dtw-ex002.nasa.cpwr.corp> From: "Ebright, Don" To: X-OriginalArrivalTime: 01 Dec 2007 16:50:53.0143 (UTC) FILETIME=[55BFA670:01C8343A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Sun, 02 Dec 2007 15:31:22 -0500 Cc: Cosmos Dev , ops-area@ietf.org Subject: [OPS-AREA] RE: MIB2RDML relevance to Eclipse COSMOS data collection X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org As the component lead of the COSMOS data collection component, I would like to express an interest in the MIB2RDML work and attempt to give a brief overview of the relevance of this work to our project. =20 COSMOS is an open source project of the Eclipse Foundation whose mission is building management tools for computer systems and networks. One of the project deliverables is a data collection component which is based on web services standards, with a specific focus on exploiting the OASIS WSDM standard and its open source implementation in the Apache Muse project. A significant project requirement which has not been addressed thus far is the need to interoperate with SNMP-based infrastructure. =20 COSMOS would find considerable value in a standard way for XML applications to access SNMP MIBs. There is a potential for even greater value in a runtime bridge between the SNMP and XML infrastructure. Eventually, we expect to support full closed loop management of SNMP devices via WSDM interfaces, but our first step in the near term is the ability to observe SNMP traps. It would be very useful if this could be accomplished without the need to implement extensive new SNMP-specific components (e.g. ASN.1 support) in our Java applications. I am cross-posting this message to ops-area as suggested by Bob Natale. Don Ebright The contents of this e-mail are intended for the named addressee only. = It contains information that may be confidential. Unless you are the = named addressee or an authorized designee, you may not copy or use it, = or disclose it to anyone else. If you received it in error please notify = us immediately and then destroy it. _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Dec 02 21:41:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Ek-0001f3-UB; Sun, 02 Dec 2007 21:40:46 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iz1Ej-0001eu-Hd for ops-area-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 21:40:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Ej-0001ek-7R for ops-area@ietf.org; Sun, 02 Dec 2007 21:40:45 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz1Ei-0005T9-UE for ops-area@ietf.org; Sun, 02 Dec 2007 21:40:45 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="82918766" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 02 Dec 2007 21:40:44 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="136123504" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Dec 2007 21:40:43 -0500 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: Mon, 3 Dec 2007 03:40:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Another Update of the Agenda Thread-Index: Acg1VeRa6tRvwgQTRPqkPDKryTKmMg== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [OPS-AREA] Another Update of the Agenda X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica MONDAY, December 3, 2007 1740-1950 Afternoon Session III SALON A 1. Note well, agenda bashing, note takers, blue sheets - 4 min 2. Call for volunteers - IESG scribe - Dan - 1 min 3. Report from the NMRG workshop in the Netherlands (November 8-9) with the topic of SNMP trace analysis - Dan Romascanu on behalf of Juergen Schoenwaelder - 5 min 4. T-MPLS Design Team - Deborah Bungard - 10 min 5. Reorganization and extension of the OPS Directorate - Ron Bonica - 10 min 6. Status of MIB2RDML work - Bob Natale http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt - 20 min 7. XML Schema Usage for NETCONF - Sharon Chisholm http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-07.txt - 20 min 8. Technical Discussion on the YANG data modeling language - David Partain http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt - 40 min 9. Mailing Lists Status - Dan - 5 min 10. Open microphone - 30 min =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Dec 02 21:50:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Nw-0004Q8-IE; Sun, 02 Dec 2007 21:50:16 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iz1Nu-0004Pk-NU for ops-area-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 21:50:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz1Nu-0004P9-CR for ops-area@ietf.org; Sun, 02 Dec 2007 21:50:14 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz1Nu-0006Rn-2q for ops-area@ietf.org; Sun, 02 Dec 2007 21:50:14 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="77374107" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Dec 2007 21:50:12 -0500 X-IronPort-AV: E=Sophos;i="4.23,241,1194238800"; d="scan'208";a="136124755" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Dec 2007 21:49:31 -0500 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: Mon, 3 Dec 2007 03:49:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Room for OPS Area Office Hours - Capilano Thread-Index: Acg1VyBomoTLSHpCS/iGXL6kvAIYRg== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [OPS-AREA] Room for OPS Area Office Hours - Capilano X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org The name of the room for where we shall hold the OPS Area open hours is Capilano.=20 We are waiting for you there Tuesday 9 to 11:30AM and Thursday 3:15 to 5PM.=20 Dan and Ron=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 10 15:40:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pQB-0008I0-KN; Mon, 10 Dec 2007 15:40:11 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J1pQA-0008Ea-4v for ops-area-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 15:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pQ9-0008ES-6G for ops-area@ietf.org; Mon, 10 Dec 2007 15:40:09 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pQ5-0003cE-Ie for ops-area@ietf.org; Mon, 10 Dec 2007 15:40:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Mon, 10 Dec 2007 12:40:04 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Dec 2007 12:39:03 -0800 Received: from [172.23.1.197] ([172.23.1.197] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Dec 2007 15:39:01 -0500 Message-ID: <475DA3E0.6020003@juniper.net> Date: Mon, 10 Dec 2007 15:38:56 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ops-area@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/mixed; boundary="------------020601020504070401010508" X-OriginalArrivalTime: 10 Dec 2007 20:39:01.0460 (UTC) FILETIME=[B256D140:01C83B6C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c Subject: [OPS-AREA] minutes X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --------------020601020504070401010508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, The attached are propsed minutes from the OPS AREA meeting. Please send corrections to this list by Friday, Dec 14. Thanks to Benoit Claise for taking such good notes! Ron and Dan --------------020601020504070401010508 Content-Type: text/plain; name="ops-meeting-minutes-ietf70-2.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="ops-meeting-minutes-ietf70-2.txt" OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica MONDAY, December 3, 2007 1740-1950 Afternoon Session III SALON A 1. Note well, agenda bashing, note takers, blue sheets - 4 min 2. Call for volunteers - IESG scribe - Dan - 1 min Goal: IESG transparency Advantage: direct view of what’s happening in the IESG 3. T-MPLS Design Team - Stewart Bryant - 10 min Team between the IETF and ITU-T At IETF69, concerns were raisd that by redefining many aspects of the IETF MPLS and PWE3 design, TMPLS would be harmful to the internet. IAB and ISG sent a joint liasion to the ITU-T, available on the liaison page The liaison: MPLS ethertypes MUST only point to a label defined by the MPLS RFCs. ITU claim disjoin networks but about interoperability Options presented: work together different technology ITU action and liaison statement: sent the liaison to 4 Stugy Groups Each group has got its own reply to the liaison See the slides for the details The IETF and ITU-T should ensure MPLS/T-MPLS compatibility, consistency, and coherence. Proposal for the joint working team: highlight inconsistency 2. advanced the IETF MPLS spec. if necessary 4. Report from the NMRG workshop in the Netherlands (November 8-9) with the topic of SNMP trace analysis - Dan Romascanu on behalf of Juergen Schoenwaelder - 5 min - NMRG Meeting 08-09 November 2007 Hosted by the University of Twente, Netherlands Seven participants from five different organizations Meeting information and slides: http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2007/enschede/ Minutes: http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-023.txt - SNMP traces analysis (common vocabulary for example) and vizualation - Traces analysis: packet arrival times, packet size distributions, message size distributions, message arrival times, message versions, operation distribution, parameter distributions, data type distributions, managed object distribution, data types, notification type distribution, walk arrival times, etc… - Need for common definitions: It would be nice to have common definitions so that we can (i) share some of the tools, (ii) exchange aggregated data for further analysis, and (iii) know precisely what we mean when we use a specific term. Need to define flows, slices, slice types, slice sets, walk, walk types Will be posted as an internet draft - SNMP Trace visualization to show a hiearchy - Conclusions: Meeting was successful in moving work forward Internet-Draft with common definitions is being worked on Expect to see some research papers coming out in 2008 Future work on suitable visualizations needed Additional traces are always welcome. . . Feedback: Sharon: provided feedback at the last IETF about a draft about trace collecting SNMP. However the draft is expired now. Bert: asked to re-sheperd the draft. So ping Juergen a few times Juergen is still developping the document while gaining experience. 5. Reorganization and extension of the OPS Directorate - Ron Bonica Reorganized and retasked The team will received emails on regular basis: the goal is to review draft from an OPS impact point of view Over time, will review what the OPS requirements Dave Harrington has got a manageability draft. 6. Status of MIB2RDML work - Bob Natale http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd-00.txt Network Working Group Y. Li, Ed. Internet-Draft Huawei Technologies Intended status: Standards Track B. Natale, Ed. Expires: May 31, 2008 MITRE November 28, 2007 Expressing SNMP SMI Datatypes in XML Schema Definition Language draft-li-natale-smi-datatypes-in-xsd-00.txt Abstract This memo defines the IETF standard expression of Simple Network Management Protocol (SNMP) Structure of Management Information (SMI) datatypes in eXtensible Markup Language (XML) Schema Definition (XSD) language. - The problem space: Existing and future SNMP MIBs represent a tremendous source of network management value, both as data models and (when realized via SNMP agents) -- as instrumented management capabilities. So, development of an IETF Standard Methodology for Converting SNMP MIBs to XML Documents via XSD, for XML based application. - During last IETF, Bob was challenged to show the advantages of this method. After some thoughts: Expected Beneficiaries & Benefits * Network Operators: * More unified management solutions from the service layer * Fewer distinct management tools to purchase, integrate, operate, and maintain * Fewer distinct data sources to correlate and validate * Result = More timely, complete, accurate network information enables improved service delivery at reduced cost * Network Users: * Improved service performance at (possibly) lower cost due to benefits realized by Network Operators. * XML-based Management Solution Providers: * More appealing products to offer * No need to reinvent the wheel with respect to SNMP MIB data models or instrumentation * SNMP Managed Equipment Providers: * Broader market for existing products w/o code changes * SNMP Management Solution Providers: * Supply MIB to XML conversion/validation tools * Supply XML/SNMP proxy solution * Eventually supply XML-based instrumentation in existing SNMP-managed equipment Background: * IETF-68/Prague - MIB2RMDL (Natale): * Addressed the full conversion problem: * MIB to XML via XSD * XML to “Resource Model” (e.g., SML, RMD, etc.) * Gateway to SNMP-based instrumentation * IETF-69/Chicago – XSDMI (Harrington/Li): * Focused on MIB to XML via XSD * Leveraged pre-existing IETF work * MIB2RMDL effort aligned with XSDMI * IETF-70/Vancouver (combined team): * draft-li-natale-smi-datatypes-in-xsd-00.txt * XML-oriented “consumer” groups asking for alignment in the March 2008 time frame * MIB to XML via XSD Deliverables: * Documents: * SNMP SMI Datatypes in XSD * RFC 2578 and RFC 1155 * SNMP Textual Conventions in XSD * RFC 2579 and select (TBD) other IETF TCs * Optional: Follow-on additional document(s) to cover select (TBD) non-core TCs * SNMP MIB Structure in XSD * Working from libsmi as a starting point * Tools (Optional): * Downloadable/online MIB to XML conversion utilities * Similar to XML2RFC * Reference implementations * MIB to XML * XML to SNMP Gateway Requirements for SMI to XSD Mapping (Objectives: Fidelity and Parsimon Note: the requirements on which we must have agreement. * R1. All SMI datatypes MUST have a corresponding XSD datatype. * R2. In case of conflicting requirements between SMIv1 and SMIv2, SMIv2 MUST take precedence. * R3. The XSD datatype specified for a given SMI datatype MUST be able to represent all valid values for that SMI datatype, and only those values * R4. The XSD datatype specified for a given SMI datatype MUST represent any special encoding rules associated with that SMI datatype. * R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype. * R6. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. * R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most direct from the perspective of readability by humans. Proposed SMI Datatypes to XSD Mapping - Recommendations for simpler patterns for “IpAddress” and “ObjectIdentifier” which are consistent with the mapping requirements will be enthusiastically welcomed. - Note that the SMIv2 “BITS” construct remains to be mapped. Feedback: Sharon: division between the SNMP, SMI, and MIB. integer32 and integer64. SNMP could not do 64bits initially. Do we need to have fidelity or can we just say: integer. Bob: looking for fidelity here Dan: what are the next steps? Bob: * Achieve consensus on SMI datatypes to XSD mapping draft: * draft-li-natale-smi-datatypes-in-xsd-00.txt * -01 update to be posted following Vancouver * Identify core set of TCs and publish Core TC to XSD mapping draft: * draft-romascanu-netconf-datatypes-02.txt is a primary source * Define IETF-standard MIB to XML structure and publish mapping draft: * libsmi/smidump XML output tool is a primary source: * draft-li-mib-convert-00.txt * Output from XML option of http://www.ibr.cs.tu-bs.de/projects/libsmi/smidump.html * Refine and publish all drafts as Proposed Standard RFCs Don, as individual contributor: not data model guru. SMI was not expressive enough for configuration. So any mapping will be lacking any configuration. What guarantee that what we will do (relax NG, yang) will still be compliant Bob: not sure yet. Don: After this next generation is done, will have to tune it Dave Harrington: to answer Ron. If take SMI and add extra things to it (things in YANG that don’t exist in SMI), there is no guarantee … Yang is done for configuration specifically. For example: state. SNMP doesn’t care For example: Netconf needs to know whether this is the startup or running config. SNMP doesn’t care SMI has not proved to be very good for configuration. Andy Bierman: limited in scope enough now that it’s useful (even if Andy was opposed to it in the past). Andy agrees that fidelity is important. David Harrington: fidelity is an interesting one. “truth” TC values has the value of 1 and 2. Normally, we use 0 and 1. Yang proposes to use 0 and 1. If a new protocol, don’t recommand that the truth value from SMI… depending on what’s need to be accomplished. ?: while browsing the draft, don’t see anything about Ipv6 address. Andy: XML encoding is the key, not XSD. Whether this is XSD or not is irrelevant. Note: draft not posted. http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd-00.txt 7. XML Schema Usage for NETCONF - Sharon Chisholm http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-07.txt Network Working Group S. Chisholm, Ed. Internet-Draft Nortel Intended status: Standards Track November 18, 2007 Expires: May 21, 2008 Using XML Schema to define NETCONF Content draft-chisholm-netconf-model-07.txt Abstract This memo defines a framework for defining content for NETCONF using XML Schema. It defines requirements to enable interoperability, extensibility, easy parsing, usability and predictable modelling. Solution to define content to be exchanged between NETCONF client and NETCONF server, similar to MIB for SNMP. Use XML schema, plus defines appInfo tags (such as minAccess, maxAccess, status, appErrors, eventClass, dataType) to fill in gaps Note that now, relaxNG has got a lot of tools. This was not the case when this job was started. This could be done with relaxNG Modeling Considerations: modularity, data types, elements and attributes, naming implications of using XPATH, proper tag names, granularity of data model, avoid mixed content. Updates in 07: - explain the benefits of the approach - updated notification definition to align with notification ID - clean up examples - delected the section which outlined specific NETCONF operations against the data model - added an appendix talking about the potential for a mapping to Yang Based on the feedback from this morning, started to compare the XSD, relaxNG ,Yang. 8. Technical Discussion on the YANG data modeling language - David Partain http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt Network Working Group M. Bjorklund, Ed. Internet-Draft Tail-f Systems Intended status: Standards Track November 7, 2007 Expires: May 10, 2008 YANG - A data modeling language for NETCONF draft-bjorklund-netconf-yang-00 Abstract YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. Technical presentation of Yang. Yang is a SMI for NETCONF: config data, state data, RPCs, and notification Based on SMIng syntax Text based Preserves investment in SNMP MIBs Libsmi translates MIBs to YANG Directly maps to XML content (on the wire) Extensible Add new content to existing data models Add new statement to YANG Very limited scope Based on three proprietary DMLs Running code (www.yang-central.org) Reuse the concept of modules in SMI, but add the notion of submodule Different types in YANG: Leaf: one value, no children, one instance Leaf-list: one value, no children, multiple instances The order is important Container: no value, holds related children, one instance Must: constrain nodes by XPATH expression Has to be fulfilled to be valid List: uniquely identifed by keys, holds children Etc… See the slides. YANG gives the syntax, but that’s not all: unique, must, keyref, config, default, error-app-tag/error-message, mandatory, presence, ordered-by, notion of derived types, notion of grouping 9. Mailing Lists Status - Dan - 5 min - The metalanguage mailing (modelling language for more complex structure with a set of tools) would be closed due to no activities - Mib2rd mailing list would be kept open for some time - Yang mailing list is just started - ngo (NETCONF goes on) mailing list. Now that NETCONF is rechartered, … Sharon would like to keep it, for the people. Dave is worried about the 8 copies of the same messages. Will be discussed again. 10. Open microphone - 30 min Dave Pertain: How many read the YANG draft? A lot more than this morning in the aps area. --------------020601020504070401010508 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area --------------020601020504070401010508-- From ops-area-bounces@ietf.org Tue Dec 11 12:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J297L-0002rR-Fs; Tue, 11 Dec 2007 12:42:03 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J297J-0002rB-UM for ops-area-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:42:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J297J-0002r2-Ja; Tue, 11 Dec 2007 12:42:01 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J297J-0003Bc-9C; Tue, 11 Dec 2007 12:42:01 -0500 X-IronPort-AV: E=Sophos;i="4.24,153,1196658000"; d="scan'208";a="90564747" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 11 Dec 2007 12:41:59 -0500 X-IronPort-AV: E=Sophos;i="4.24,153,1196658000"; d="scan'208";a="139961913" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Dec 2007 12:41:18 -0500 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: Tue, 11 Dec 2007 18:41:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to close the meta-model mail list Thread-Index: Acg8HQf9UgrCQKL0Rbuka5EMk/9n4w== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ops-area@ietf.org Subject: [OPS-AREA] Proposal to close the meta-model mail list X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Following the discussions hold in the OPSAREA meeting in Vancouver I am proposing to close the meta-model list. This list was open after the March mini-BOF in Prague in order to provide a media for debate on meta models for network management. Unfortunately the initial enthusiasm was not followed by any debate or concrete steps, no submissions or proposals were made for further IETF work, and the traffic on the list was practically zero for the last few months.=20 If you believe that we should not close the list, please present your arguments to the list or to the ADs until 12/18 the latest.=20 Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 07:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4F7d-0004xl-Ku; Mon, 17 Dec 2007 07:31:01 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4F7c-0004xf-7K for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 07:31:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4F7b-0004xN-OG for ops-area@ietf.org; Mon, 17 Dec 2007 07:30:59 -0500 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4F7b-00053N-4X for ops-area@ietf.org; Mon, 17 Dec 2007 07:30:59 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id lBHCUukW001858 for ; Mon, 17 Dec 2007 14:30:56 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id lBHCUtnK001855 for ; Mon, 17 Dec 2007 14:30:56 +0200 Date: Mon, 17 Dec 2007 14:30:55 +0200 (EET) From: Pekka Savola To: ops-area@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5152/Mon Dec 17 02:37:06 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [OPS-AREA] A better version of TimeTicks? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100). TimeTicks is used in various things, among others, reporting uptimes. Has there been work to consider redefining or extending TimeTicks-like objects which would not wrap after 497 days? We have gear whose internal uptime representation allows the uptimes in the order of decades but unfortunately such uptimes cannot be managed within the current SNMP framework as far as I can see. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 08:30:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4G2q-000180-1A; Mon, 17 Dec 2007 08:30:08 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4G2n-00017g-B8 for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 08:30:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4G2m-00017Y-UZ for ops-area@ietf.org; Mon, 17 Dec 2007 08:30:05 -0500 Received: from rs40.luxsci.com ([65.61.166.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4G2m-0006an-6P for ops-area@ietf.org; Mon, 17 Dec 2007 08:30:04 -0500 Received: from [192.168.20.198] (c-24-91-195-79.hsd1.ma.comcast.net [24.91.195.79]) (authenticated bits=0) by rs40.luxsci.com (8.13.1/8.13.7) with ESMTP id lBHDTvHd016019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 17 Dec 2007 07:30:00 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <28A7803B-D774-49F8-95B3-ADE88C6007D5@jdscons.com> From: Jon Saperia Subject: Re: [OPS-AREA] A better version of TimeTicks? Date: Mon, 17 Dec 2007 08:29:55 -0500 To: Pekka Savola X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024509823==" Errors-To: ops-area-bounces@ietf.org --===============1024509823== Content-Type: multipart/alternative; boundary=Apple-Mail-2-547663759 --Apple-Mail-2-547663759 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Peter, The drill usually is that the management application polls for information on some periodic basis, for interface and other information. It is as this point that a wrap in uptime would be detected. Also depending on the deployment model of your customers, some may choose to have a cold-start or other notification message sent when the management system is reinitialized (which will be the case on a reboot). Between these two, you should be OK Note is you are really keeping track of uptime of the system, you should distinguish it from management system up time. In some systems I have worked on, the distinction is important and we implemented a different object than sysUptime. Thanks /jon ------------ Jon Saperia (mobil) 617-201-2655 (office) 978-461-0249 saperia@jdscons.com On Dec 17, 2007, at 7:30 AM, Pekka Savola wrote: > Hi, > > SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. > > TimeTicks is limited to 497 days before it wraps over > (2^32/3600/24/100). > > TimeTicks is used in various things, among others, reporting uptimes. > > Has there been work to consider redefining or extending TimeTicks- > like objects which would not wrap after 497 days? > > We have gear whose internal uptime representation allows the > uptimes in the order of decades but unfortunately such uptimes > cannot be managed within the current SNMP framework as far as I can > see. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > --Apple-Mail-2-547663759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Peter,

The drill = usually is that the management application polls for information on some = periodic basis, for interface and other information. It is as this point = that a wrap in uptime would be detected. =A0Also depending on the = deployment model of your customers, some may choose to have a cold-start = or other notification message sent when the management system is = reinitialized (which will be the case on a reboot). =A0Between these = two, you should be OK

Note is you are really keeping = track of uptime of the system, you should distinguish it from management = system up time. =A0In some systems I have worked on, the distinction is = important and we implemented a different object than = sysUptime.
Thanks
/jon

------------
Jo= n Saperia
(mobil) 617-201-2655
(office) = 978-461-0249

On Dec = 17, 2007, at 7:30 AM, Pekka Savola wrote:

Hi,

SNMPv2 SMI (RFC2578, STD 58) = defines, among other things, TimeTicks.

TimeTicks is = limited to 497 days before it wraps over (2^32/3600/24/100).


Has there been work to consider redefining or = extending TimeTicks-like objects which would not wrap after 497 = days?

We have gear whose internal uptime representation = allows the uptimes in the order of decades but unfortunately such = uptimes cannot be managed within the current SNMP framework as far as I = can see.

--=A0
Pekka = Savola =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 "You each name yourselves king, yet the
Netcore Oy=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: = A Clash of Kings


OPS-AREA mailing list


= --Apple-Mail-2-547663759-- --===============1024509823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area --===============1024509823==-- From ops-area-bounces@ietf.org Mon Dec 17 08:43:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GFn-0003gJ-9K; Mon, 17 Dec 2007 08:43:31 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4GFm-0003gD-4Y for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 08:43:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4GFl-0003g4-Pr for ops-area@ietf.org; Mon, 17 Dec 2007 08:43:29 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4GFl-0007sE-CK for ops-area@ietf.org; Mon, 17 Dec 2007 08:43:29 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50BC38A320; Mon, 17 Dec 2007 14:43:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07624-02-64; Mon, 17 Dec 2007 14:43:22 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7581A8A33B; Mon, 17 Dec 2007 14:26:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2D07742B1D1; Mon, 17 Dec 2007 14:26:27 +0100 (CET) Date: Mon, 17 Dec 2007 14:26:27 +0100 From: Juergen Schoenwaelder To: Pekka Savola Subject: Re: [OPS-AREA] A better version of TimeTicks? Message-ID: <20071217132627.GA989@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Mon, Dec 17, 2007 at 02:30:55PM +0200, Pekka Savola wrote: > SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. > > TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100). > > TimeTicks is used in various things, among others, reporting uptimes. > > Has there been work to consider redefining or extending TimeTicks-like > objects which would not wrap after 497 days? > > We have gear whose internal uptime representation allows the uptimes in the > order of decades but unfortunately such uptimes cannot be managed within > the current SNMP framework as far as I can see. When we did the SMIng experiment, we defined a TimeTicks64 type, a 64-bit version of TimeTicks (which is 32-bit). Once you move to 64-bit numbers (which I think is pretty much reasonable these days), it is possible to also change the time base form hundredths of a second to something more granular (e.g. microseconds) while still allowing long time intervals to be expressed without wrap arounds. That said, I am not aware of any standards-track action in this space. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 14:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LIS-0005b2-Nn; Mon, 17 Dec 2007 14:06:36 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LIR-0005aw-Qh for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LIR-0005am-GA for ops-area@ietf.org; Mon, 17 Dec 2007 14:06:35 -0500 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4LIO-0005GA-Nw for ops-area@ietf.org; Mon, 17 Dec 2007 14:06:35 -0500 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Mon, 17 Dec 2007 11:02:00 PST Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Dec 2007 11:03:59 -0800 Received: from [172.23.1.231] ([172.23.1.231] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Dec 2007 14:03:56 -0500 Message-ID: <4766C818.5040509@juniper.net> Date: Mon, 17 Dec 2007 14:03:52 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [OPS-AREA] A better version of TimeTicks? References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2007 19:03:56.0837 (UTC) FILETIME=[9302AD50:01C840DF] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Pekka, I have also seen devices stay up for two years. So, how would you handle this? One possibility is to create a new type with range 0-2^32 and a granularity of seconds. Another is to create a new type with range 0-2^64 and granularity of centiseconds? Ron Pekka Savola wrote: > Hi, > > SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. > > TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100). > > TimeTicks is used in various things, among others, reporting uptimes. > > Has there been work to consider redefining or extending TimeTicks-like > objects which would not wrap after 497 days? > > We have gear whose internal uptime representation allows the uptimes in > the order of decades but unfortunately such uptimes cannot be managed > within the current SNMP framework as far as I can see. > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 14:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LVf-0005vy-IG; Mon, 17 Dec 2007 14:20:15 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LVe-0005vr-Ly for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:20:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LVe-0005vh-BW for ops-area@ietf.org; Mon, 17 Dec 2007 14:20:14 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LVd-0004SG-Ua for ops-area@ietf.org; Mon, 17 Dec 2007 14:20:14 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4CCF2864B9; Mon, 17 Dec 2007 20:20:13 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11719-03; Mon, 17 Dec 2007 20:20:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACC3984AE7; Mon, 17 Dec 2007 20:20:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8FB1342B9B4; Mon, 17 Dec 2007 20:20:04 +0100 (CET) Date: Mon, 17 Dec 2007 20:20:04 +0100 From: Juergen Schoenwaelder To: Ron Bonica Subject: Re: [OPS-AREA] A better version of TimeTicks? Message-ID: <20071217192004.GB1798@elstar.local> References: <4766C818.5040509@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4766C818.5040509@juniper.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Mon, Dec 17, 2007 at 02:03:52PM -0500, Ron Bonica wrote: > Pekka, > > I have also seen devices stay up for two years. > > So, how would you handle this? One possibility is to create a new type > with range 0-2^32 and a granularity of seconds. Another is to create a > new type with range 0-2^64 and granularity of centiseconds? If you go to 64-bit, you can safely go down to microseconds and achieve a rather long lifetime without a rollover. Lets do the calculation with microseconds = 10^6 ticks per second: This means approximately 18446744073709 seconds which is in the order of 584942 years until rollover. Of course, the lower 32 bits would rollover almost every hour. NTP timestamps are 64 bits where 32 bits are in the resolution of seconds (rollover in ~136 years) and the other 32 bits give you a resolution in pico-seconds. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 14:21:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LWj-0001q2-0Q; Mon, 17 Dec 2007 14:21:21 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LWh-0001pw-UV for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:21:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LWh-0001po-KC for ops-area@ietf.org; Mon, 17 Dec 2007 14:21:19 -0500 Received: from netcore.fi ([193.94.160.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LWg-0004Ub-UR for ops-area@ietf.org; Mon, 17 Dec 2007 14:21:19 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id lBHJLB4N013022; Mon, 17 Dec 2007 21:21:11 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id lBHJLBst013019; Mon, 17 Dec 2007 21:21:11 +0200 Date: Mon, 17 Dec 2007 21:21:11 +0200 (EET) From: Pekka Savola To: Joel Jaeggli Subject: Re: [OPS-AREA] A better version of TimeTicks? In-Reply-To: <4766CA51.9020109@bogus.com> Message-ID: References: <4766C818.5040509@juniper.net> <4766CA51.9020109@bogus.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5152/Mon Dec 17 02:37:06 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on otso.netcore.fi X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Mon, 17 Dec 2007, Joel Jaeggli wrote: > Ron Bonica wrote: >> Pekka, >> >> I have also seen devices stay up for two years. >> >> So, how would you handle this? One possibility is to create a new type >> with range 0-2^32 and a granularity of seconds. Another is to create a >> new type with range 0-2^64 and granularity of centiseconds? > > low-enough sample interval should given you high confidence that you've > detected a counter rollover rather than a reboot. This presumes a system where this information is polled regularly (and then synthethized and presented, in some postprocessed form, e.g. adjusting for overflows, to the user). In our case, when the user goes to a web page, CGI scripts fire up a couple of SNMP queries -- there no stored state about the results of previous runs. We could easily add such stored data for each of our (self-developed) systems that do similar on-demand tasks, but I'm not sure how feasible approach that is in the general case or how that would work with closed-source products. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 15:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ML9-0002GY-Gi; Mon, 17 Dec 2007 15:13:27 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4ML7-00029Y-3C for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 15:13:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4ML6-00029D-Mi for ops-area@ietf.org; Mon, 17 Dec 2007 15:13:24 -0500 Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4ML5-0007TN-TM for ops-area@ietf.org; Mon, 17 Dec 2007 15:13:24 -0500 Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA03.westchester.pa.mail.comcast.net with comcast id Rvwh1Y0010mv7h00501f00; Mon, 17 Dec 2007 20:13:23 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA11.westchester.pa.mail.comcast.net with comcast id RwDK1Y00H4HwxpC3X00000; Mon, 17 Dec 2007 20:13:23 +0000 X-Authority-Analysis: v=1.0 c=1 a=g6VtRZShjLMA:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=lptxUpgoDyeg7dz3BskA:9 a=MfB0tsoha7lfohIWGigA:7 a=xn40NQ2n7wcYca4RLEYKWE0zYhYA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=hefTiKavWeMA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Ron Bonica'" References: <4766C818.5040509@juniper.net> <20071217192004.GB1798@elstar.local> Subject: RE: [OPS-AREA] A better version of TimeTicks? Date: Mon, 17 Dec 2007 15:13:04 -0500 Message-ID: <05d201c840e9$3ba11830$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071217192004.GB1798@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AchA4d7P3Ag+Fv0xScG2i8w+I1AhQQAA0/SA X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, Wouldn't an alternative be to define a sysUptimeRollovers to count the number of times the maximum value was reached? Except that you would need to poll two objects, this is the same as defining a new sysUpTime object to be 64 bits, where the upper bits would count the rollovers. sysUptimeRollovers would need to be cleared on reboot, just as sysUptime is cleared. All existing applications would continue to work just fine with the existing lower-32-bit counter. If you define a new TimeTicks64 and wanted to apply it to existing counters, such as sysUptime, you would need to define a new managed object of the 64bit type, and agents and managers would probably need to support both the timeticks32 and the timeticks64 objects. Using a rollover counter does not require any changes to existing sysUptime support, just an additional object where rollovers might matter. If a system does not support the rollover counter then you are no worse off than you are today. If it does, it provides additonal information to better interpret sysUptime. This could be done as a textual convention, so timeticks objects other than sysuptime could be extended to count their rollovers. Descriptions would need to be clear about when the rollover count was cleared. Combining the normal 32-bit counter with a rollover counter is equivalent to using a 64-bit counter, assuming access to both the lower-32-bits and the upper-32-bits are handled simultaneously, and SNMP GETs are supposed to be as0if-simultaneous, so if both are requested in the same PDU, they chould be consistent. (And implementations of course could actually use a 64-bit counter so they could access instrumentation once, and then report it as two 32-bit objects.) Of course for new objects where there is no 32-bit counter already, simply using a 64-bit counter might be preferable. Before you invent a new object to track, say, seconds since reboot, you might take a look at the SNMP-FRAMEWORK-MIB which contains a Boots counter and a seconds-since-last-boot counter. This is not tied to sysUptime explicitly, and may or may not be appropriate to your desired usage. While designed for SNMPv3 support, SNMP-FRAMEWORK-MIB can be implemented in any SNMP engine, regardless of which versions of SNMP are supported. Note that with all of these objects, you need to be careful about a re-initialization of the SNMP agent independent of re-initialization of the hardware or software that is being managed. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, December 17, 2007 2:20 PM > To: Ron Bonica > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] A better version of TimeTicks? > > On Mon, Dec 17, 2007 at 02:03:52PM -0500, Ron Bonica wrote: > > Pekka, > > > > I have also seen devices stay up for two years. > > > > So, how would you handle this? One possibility is to create > a new type > > with range 0-2^32 and a granularity of seconds. Another is > to create a > > new type with range 0-2^64 and granularity of centiseconds? > > If you go to 64-bit, you can safely go down to microseconds and > achieve a rather long lifetime without a rollover. Lets do the > calculation with microseconds = 10^6 ticks per second: This means > approximately 18446744073709 seconds which is in the order of 584942 > years until rollover. Of course, the lower 32 bits would rollover > almost every hour. > > NTP timestamps are 64 bits where 32 bits are in the resolution of > seconds (rollover in ~136 years) and the other 32 bits give you a > resolution in pico-seconds. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 17 15:21:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MSb-0003tc-Vi; Mon, 17 Dec 2007 15:21:09 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4MSa-0003tO-VH for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 15:21:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4MSa-0003tF-LR for ops-area@ietf.org; Mon, 17 Dec 2007 15:21:08 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4MSY-0007ry-Uv for ops-area@ietf.org; Mon, 17 Dec 2007 15:21:08 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id D337A8A102; Mon, 17 Dec 2007 21:21:05 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 17469-03; Mon, 17 Dec 2007 21:21:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 087C85AD5F; Mon, 17 Dec 2007 21:21:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E552242BC1A; Mon, 17 Dec 2007 21:20:59 +0100 (CET) Date: Mon, 17 Dec 2007 21:20:59 +0100 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [OPS-AREA] A better version of TimeTicks? Message-ID: <20071217202059.GA1907@elstar.local> References: <20071217192004.GB1798@elstar.local> <05d201c840e9$3ba11830$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <05d201c840e9$3ba11830$6502a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Mon, Dec 17, 2007 at 03:13:04PM -0500, David Harrington wrote: > If you define a new TimeTicks64 and wanted to apply it to existing > counters, such as sysUptime, you would need to define a new managed > object of the 64bit type, and agents and managers would probably need > to support both the timeticks32 and the timeticks64 objects. > > Using a rollover counter does not require any changes to existing > sysUptime support, just an additional object where rollovers might > matter. If a system does not support the rollover counter then you are > no worse off than you are today. If it does, it provides additonal > information to better interpret sysUptime. Both solutions require a new object and so I do not understand what the difference there is implementation wise. > Before you invent a new object to track, say, seconds since reboot, > you might take a look at the SNMP-FRAMEWORK-MIB which contains a Boots > counter and a seconds-since-last-boot counter. This is not tied to > sysUptime explicitly, and may or may not be appropriate to your > desired usage. While designed for SNMPv3 support, SNMP-FRAMEWORK-MIB > can be implemented in any SNMP engine, regardless of which versions of > SNMP are supported. I believe most people want HOST-RESOURCES-MIB::hrSystemUptime or something with equivalent semantics and with less rollovers. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Dec 18 08:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cdx-0007Ig-4U; Tue, 18 Dec 2007 08:37:57 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4cdw-0007Ib-GL for ops-area-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 08:37:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4cdw-0007IS-4y for ops-area@ietf.org; Tue, 18 Dec 2007 08:37:56 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4cdv-0002j9-OR for ops-area@ietf.org; Tue, 18 Dec 2007 08:37:56 -0500 X-IronPort-AV: E=Sophos;i="4.24,180,1196658000"; d="scan'208";a="92160497" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 18 Dec 2007 08:37:54 -0500 X-IronPort-AV: E=Sophos;i="4.24,180,1196658000"; d="scan'208";a="134914148" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 18 Dec 2007 08:37:14 -0500 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 Subject: RE: [OPS-AREA] A better version of TimeTicks? Date: Tue, 18 Dec 2007 14:37:07 +0100 Message-ID: In-Reply-To: <20071217202059.GA1907@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] A better version of TimeTicks? Thread-Index: AchA6miW++N7mzkHSmijiT0n4bhwtQAj/9lA References: <20071217192004.GB1798@elstar.local><05d201c840e9$3ba11830$6502a8c0@china.huawei.com> <20071217202059.GA1907@elstar.local> From: "Romascanu, Dan (Dan)" To: , "David Harrington" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Monday, December 17, 2007 10:21 PM > To: David Harrington > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] A better version of TimeTicks? >=20 > On Mon, Dec 17, 2007 at 03:13:04PM -0500, David Harrington wrote: > =20 > > If you define a new TimeTicks64 and wanted to apply it to existing=20 > > counters, such as sysUptime, you would need to define a new managed=20 > > object of the 64bit type, and agents and managers would=20 > probably need=20 > > to support both the timeticks32 and the timeticks64 objects. > >=20 > > Using a rollover counter does not require any changes to existing=20 > > sysUptime support, just an additional object where rollovers might=20 > > matter. If a system does not support the rollover counter=20 > then you are=20 > > no worse off than you are today. If it does, it provides additonal=20 > > information to better interpret sysUptime. >=20 > Both solutions require a new object and so I do not=20 > understand what the difference there is implementation wise. > =20 Would not the introduction of a newTimeTicks64 be a new basic type, so a modification to SMIv2, something that we did not do since RFC 2578?=20 Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Dec 18 09:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d2e-0007wn-04; Tue, 18 Dec 2007 09:03:28 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4d2c-0007vz-CV for ops-area-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 09:03:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4d2c-0007vr-1V for ops-area@ietf.org; Tue, 18 Dec 2007 09:03:26 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4d2Z-0007CQ-OI for ops-area@ietf.org; Tue, 18 Dec 2007 09:03:26 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 84B938A1EF; Tue, 18 Dec 2007 15:03:22 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09316-01-2; Tue, 18 Dec 2007 15:03:18 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D1088A17D; Tue, 18 Dec 2007 15:03:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0263E42C957; Tue, 18 Dec 2007 15:03:12 +0100 (CET) Date: Tue, 18 Dec 2007 15:03:12 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] A better version of TimeTicks? Message-ID: <20071218140312.GA3206@elstar.local> References: <20071217202059.GA1907@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Tue, Dec 18, 2007 at 02:37:07PM +0100, Romascanu, Dan (Dan) wrote: > Would not the introduction of a newTimeTicks64 be a new basic type, so a > modification to SMIv2, something that we did not do since RFC 2578? Oh, TimeTicks64 is just a Counter64 counting ticks. ;-) And we like with ZeroBasedCounter64 or Unsigned64TC, we can just "overwrite" the rule that you can't derive a TC from a Counter64... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Dec 18 15:51:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jPb-0005Dn-Fo; Tue, 18 Dec 2007 15:51:35 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4jPa-0005A8-9T for ops-area-confirm+ok@megatron.ietf.org; Tue, 18 Dec 2007 15:51:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4jPZ-00059C-Un for ops-area@ietf.org; Tue, 18 Dec 2007 15:51:33 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4jPZ-0005pc-LE for ops-area@ietf.org; Tue, 18 Dec 2007 15:51:33 -0500 X-IronPort-AV: E=Sophos;i="4.24,182,1196658000"; d="scan'208";a="80793497" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Dec 2007 15:51:30 -0500 X-IronPort-AV: E=Sophos;i="4.24,182,1196658000"; d="scan'208";a="142299292" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Dec 2007 15:50:49 -0500 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: Tue, 18 Dec 2007 21:50:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Recruiting minutes takers (scribes) for IESG calls and meetings Thread-Index: AchBt6o/N2qIvGdAQ+eam3I6NtBebw== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [OPS-AREA] Recruiting minutes takers (scribes) for IESG calls and meetings X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org I am renewing a call made in the OPS (and other areas) meeting in Vancouver. The IETF needs more volunteers to take minutes in the IESG telechats (conference calls) and meetings at the IETF meetings. Folks who are interested to volunteer a few hours every few weeks and a couple of morning sessions at the IETF meetings will be rewarded with the opportunity to have a fist hand exposure to the IESG work. Any interested folks please contact me or any other IESG member before this Thursday.=20 Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Dec 19 08:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zPQ-0005pg-OA; Wed, 19 Dec 2007 08:56:28 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LZT-0004Qx-8E for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LZS-0004Qk-Cb for ops-area@ietf.org; Mon, 17 Dec 2007 14:24:10 -0500 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4LZR-0005sF-9i for ops-area@ietf.org; Mon, 17 Dec 2007 14:24:10 -0500 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBHJO5h0063772; Mon, 17 Dec 2007 19:24:06 GMT (envelope-from joelja@bogus.com) Message-ID: <4766CCC0.6010609@bogus.com> Date: Mon, 17 Dec 2007 11:23:44 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [OPS-AREA] A better version of TimeTicks? References: <4766C818.5040509@juniper.net> <4766CA51.9020109@bogus.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5160/Mon Dec 17 16:46:31 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 19 Dec 2007 08:56:27 -0500 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Pekka Savola wrote: > On Mon, 17 Dec 2007, Joel Jaeggli wrote: >> Ron Bonica wrote: >>> Pekka, >>> >>> I have also seen devices stay up for two years. >>> >>> So, how would you handle this? One possibility is to create a new type >>> with range 0-2^32 and a granularity of seconds. Another is to create a >>> new type with range 0-2^64 and granularity of centiseconds? >> >> low-enough sample interval should given you high confidence that you've >> detected a counter rollover rather than a reboot. > > This presumes a system where this information is polled regularly (and > then synthethized and presented, in some postprocessed form, e.g. > adjusting for overflows, to the user). It does, yeah. larger counter is I agree the general purpose solution... joelja > In our case, when the user goes to a web page, CGI scripts fire up a > couple of SNMP queries -- there no stored state about the results of > previous runs. We could easily add such stored data for each of our > (self-developed) systems that do similar on-demand tasks, but I'm not > sure how feasible approach that is in the general case or how that would > work with closed-source products. > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Dec 19 08:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zPQ-0005pb-KW; Wed, 19 Dec 2007 08:56:28 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LPH-0005Ht-I1 for ops-area-confirm+ok@megatron.ietf.orFrom ops-area-bounces@ietf.org Wed Dec 19 08:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zPQ-0005pg-OA; Wed, 19 Dec 2007 08:56:28 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LZT-0004Qx-8E for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LZS-0004Qk-Cb for ops-area@ietf.org; Mon, 17 Dec 2007 14:24:10 -0500 Received: from [2001:418:1::81] (helo=nagasaki.bogus.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4LZR-0005sF-9i for ops-area@ietf.org; Mon, 17 Dec 2007 14:24:10 -0500 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBHJO5h0063772; Mon, 17 Dec 2007 19:24:06 GMT (envelope-from joelja@bogus.com) Message-ID: <4766CCC0.6010609@bogus.com> Date: Mon, 17 Dec 2007 11:23:44 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [OPS-AREA] A better version of TimeTicks? References: <4766C818.5040509@juniper.net> <4766CA51.9020109@bogus.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5160/Mon Dec 17 16:46:31 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 19 Dec 2007 08:56:27 -0500 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Pekka Savola wrote: > On Mon, 17 Dec 2007, Joel Jaeggli wrote: >> Ron Bonica wrote: >>> Pekka, >>> >>> I have also seen devices stay up for two years. >>> >>> So, how would you handle this? One possibility is to create a new type >>> with range 0-2^32 and a granularity of seconds. Another is to create a >>> new type with range 0-2^64 and granularity of centiseconds? >> >> low-enough sample interval should given you high confidence that you've >> detected a counter rollover rather than a reboot. > > This presumes a system where this information is polled regularly (and > then synthethized and presented, in some postprocessed form, e.g. > adjusting for overflows, to the user). It does, yeah. larger counter is I agree the general purpose solution... joelja > In our case, when the user goes to a web page, CGI scripts fire up a > couple of SNMP queries -- there no stored state about the results of > previous runs. We could easily add such stored data for each of our > (self-developed) systems that do similar on-demand tasks, but I'm not > sure how feasible approach that is in the general case or how that would > work with closed-source products. > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Dec 19 08:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4zPQ-0005pb-KW; Wed, 19 Dec 2007 08:56:28 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J4LPH-0005Ht-I1 for ops-area-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 14:13:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LPG-0005HF-Oj for ops-area@ietf.org; Mon, 17 Dec 2007 14:13:38 -0500 Received: from nagasaki.bogus.com ([147.28.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LPF-0004CC-Rj for ops-area@ietf.org; Mon, 17 Dec 2007 14:13:38 -0500 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBHJDaRL063299; Mon, 17 Dec 2007 19:13:36 GMT (envelope-from joelja@bogus.com) Message-ID: <4766CA51.9020109@bogus.com> Date: Mon, 17 Dec 2007 11:13:21 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPS-AREA] A better version of TimeTicks? References: <4766C818.5040509@juniper.net> In-Reply-To: <4766C818.5040509@juniper.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5160/Mon Dec 17 16:46:31 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 19 Dec 2007 08:56:27 -0500 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron Bonica wrote: > Pekka, > > I have also seen devices stay up for two years. > > So, how would you handle this? One possibility is to create a new type > with range 0-2^32 and a granularity of seconds. Another is to create a > new type with range 0-2^64 and granularity of centiseconds? low-enough sample interval should given you high confidence that you've detected a counter rollover rather than a reboot. > Ron > > > Pekka Savola wrote: >> Hi, >> >> SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. >> >> TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100). >> >> TimeTicks is used in various things, among others, reporting uptimes. >> >> Has there been work to consider redefining or extending TimeTicks-like >> objects which would not wrap after 497 days? >> >> We have gear whose internal uptime representation allows the uptimes in >> the order of decades but unfortunately such uptimes cannot be managed >> within the current SNMP framework as far as I can see. >> > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area g; Mon, 17 Dec 2007 14:13:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4LPG-0005HF-Oj for ops-area@ietf.org; Mon, 17 Dec 2007 14:13:38 -0500 Received: from nagasaki.bogus.com ([147.28.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4LPF-0004CC-Rj for ops-area@ietf.org; Mon, 17 Dec 2007 14:13:38 -0500 Received: from [192.103.16.81] ([192.103.16.81]) (authenticated bits=0) by nagasaki.bogus.com (8.14.1/8.13.8) with ESMTP id lBHJDaRL063299; Mon, 17 Dec 2007 19:13:36 GMT (envelope-from joelja@bogus.com) Message-ID: <4766CA51.9020109@bogus.com> Date: Mon, 17 Dec 2007 11:13:21 -0800 From: Joel Jaeggli User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Ron Bonica Subject: Re: [OPS-AREA] A better version of TimeTicks? References: <4766C818.5040509@juniper.net> In-Reply-To: <4766C818.5040509@juniper.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.1/5160/Mon Dec 17 16:46:31 2007 on nagasaki.bogus.com X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Wed, 19 Dec 2007 08:56:27 -0500 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron Bonica wrote: > Pekka, > > I have also seen devices stay up for two years. > > So, how would you handle this? One possibility is to create a new type > with range 0-2^32 and a granularity of seconds. Another is to create a > new type with range 0-2^64 and granularity of centiseconds? low-enough sample interval should given you high confidence that you've detected a counter rollover rather than a reboot. > Ron > > > Pekka Savola wrote: >> Hi, >> >> SNMPv2 SMI (RFC2578, STD 58) defines, among other things, TimeTicks. >> >> TimeTicks is limited to 497 days before it wraps over (2^32/3600/24/100). >> >> TimeTicks is used in various things, among others, reporting uptimes. >> >> Has there been work to consider redefining or extending TimeTicks-like >> objects which would not wrap after 497 days? >> >> We have gear whose internal uptime representation allows the uptimes in >> the order of decades but unfortunately such uptimes cannot be managed >> within the current SNMP framework as far as I can see. >> > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Dec 30 04:13:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8uEo-0004n0-Mu; Sun, 30 Dec 2007 04:13:42 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J8uEn-0004j7-3j for ops-area-confirm+ok@megatron.ietf.org; Sun, 30 Dec 2007 04:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8uEm-0004gR-P2 for ops-area@ietf.org; Sun, 30 Dec 2007 04:13:40 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8uEm-0002MV-A2 for ops-area@ietf.org; Sun, 30 Dec 2007 04:13:40 -0500 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="89311188" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 30 Dec 2007 04:13:39 -0500 X-IronPort-AV: E=Sophos;i="4.24,222,1196658000"; d="scan'208";a="145273286" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Dec 2007 04:13:39 -0500 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, 30 Dec 2007 10:13:37 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] IPv6 provisioning on broadband Thread-Index: AchI2DHtEVYRBbcgR6G7mc5lYgYWeQB6/s6w From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [OPS-AREA] FW: [Int-area] IPv6 provisioning on broadband X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org This is a discussion folks in opsarea may be interested about.=20 Dan =20 -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 Sent: Friday, December 28, 2007 12:31 AM To: Internet Area Subject: [Int-area] IPv6 provisioning on broadband Hi, After our nice DHCP auth discussions on the list I had occasion to discuss this issue and a few related ones in person with a few people in Vancouver. Obviously this involved the question of how to provision customers with their IPv6 addresses on broadband networks. I think I now have an idea for that that could work well. I'm interested in hearing your comments. The (old) idea is that if customers deploy their own IPv6 routers, they get to request a prefix through DHCPv6 prefix delegation. =20 (Whether the first router gets a prefix and internally redelegates if there are more routers or multiple routers can request prefixes is an open question.) However, if the customer doesn't connect a router, it's good if they still receive IPv6 address configuration. (My apologies for my lack of knowledge of broadband lingo.) I think a good way to do that is for the first device under the control of the ISP, or at least a device very low in the aggregation hierarchy, to intercept router advertisements from the ISP's IPv6 router and slightly modify them: =20 basically inject some bits that are particular to the customer/line, so that every customer sees RAs with a prefix unique to them. For instance, if an IPv6 router sits on top of two layers of layer 2 aggregation devices, the IPv6 router sends out router advertisements with prefix 2001:db8:31::/64. The lowest layer of aggregation devices then insert a 16-bit customer or line ID in bits 48 - 63 so that customer 9 sees 2001:db8:31:9::/64 and customer 10 2001:db8:31:a::/64 and so on. (The router advertisements can also be generated by the layer 2 device itself, but there probably needs to be some centrally configured info in there, too.) Customers do normal IPv6 stateless autoconfig so the lower 64 bits of the addresses are random, but the ISP only sees packets with the customer ID number somewhere in the higher bits so they know which packets come from which customer. The layer 2 infrastructure can safely impose the restriction that all customer traffic goes to the IPv6 router and not to other customers, because customers don't know their neighbor's prefix is on-link so they'll send those packets to the router anyway. And the router doesn't need an address in all those prefixes, the users only need to know its link local address. (Of course add ingress filtering as required.) The router is simply told that all of 2001:db8:31::/48 is on-link so it will do ND for all customer machines, but it doesn't send redirects. (I would probably implement a per-customer ND cache LRU algorithm to prevent one user from DoSing a whole town by generating large amounts of addresses that the router must do neighbor discovery for. There is no reason why a user wouldn't be able to connect a large number of machines using a switch but this may not be altogether desirable from the ISP's perspective.) _______________________________________________ Int-area mailing list Int-area@lists.ietf.org https://www1.ietf.org/mailman/listinfo/int-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Dec 31 06:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9JDT-0001qU-7C; Mon, 31 Dec 2007 06:53:59 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1J9JDS-0001qC-Cu for ops-area-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 06:53:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9JDR-0001oP-GU for ops-area@ietf.org; Mon, 31 Dec 2007 06:53:57 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9JDQ-0001tJ-0R for ops-area@ietf.org; Mon, 31 Dec 2007 06:53:57 -0500 X-IronPort-AV: E=Sophos;i="4.24,225,1196658000"; d="scan'208";a="95294545" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 31 Dec 2007 06:53:53 -0500 X-IronPort-AV: E=Sophos;i="4.24,225,1196658000"; d="scan'208";a="145463901" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Dec 2007 06:53:12 -0500 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: Mon, 31 Dec 2007 12:53:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area meeting minutes - correction and additions Thread-Index: AchLo7eKU/RNz9K3RXSiiVgM3r71zw== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Subject: [OPS-AREA] OPS Area meeting minutes - correction and additions X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Here are some updated OPSAREA meeting minutes with corrections and additions. Beyond what was previously sent which was based on Benoit's notes, I included now also content from the notes from Balazs. Thanks to both Benoit and Balazs for making our lives easier by taking notes from the discussions in Vancouver.=20 Dan OPSAREA Open Meeting Area Directors: Dan Romascanu and Ron Bonica MONDAY, December 3, 2007 1740-1950 Afternoon Session III SALON A 1. Note well, agenda bashing, note takers, blue sheets - 4 min 2. Call for volunteers - IESG scribe - Dan - 1 min Goal: IESG transparency=20 Advantage: direct view of what's happening in the IESG 3. T-MPLS Design Team - Stewart Bryant - 10 min Team between the IETF and ITU-T At IETF69, concerns were raised that by redefining many aspects of the IETF MPLS and PWE3 design, TMPLS would be harmful to the internet. IAB and ISG sent a joint liaison to the ITU-T, available on the liaison page The liaison: MPLS Ethertypes MUST only point to a label defined by the MPLS RFCs. ITU claim disjoin networks but about interoperability Options presented - ITU/IETF work together - completely separate technologies ITU=20 Option 2 code point separation rejected ITU action and liaison statement: sent the liaison to 4 Study Groups Each group has got its own reply to the liaison See the slides for the details The IETF and ITU-T should ensure MPLS/T-MPLS compatibility, consistency, and coherence. Proposal for the joint working team: highlight inconsistency 2. advanced the IETF MPLS spec. if necessary=09 Agreed: IETF spec is the normative reference. OAM is problematic 4. Report from the NMRG workshop in the Netherlands (November 8-9) with the topic of SNMP trace analysis - Dan Romascanu on behalf of Juergen Schoenwaelder - 5 min - NMRG Meeting 08-09 November 2007 Hosted by the University of Twente, Netherlands Seven participants from five different organizations Meeting information and slides: http://www.ibr.cs.tu-bs.de/projects/nmrg/meetings/2007/enschede/ Minutes: http://www.ibr.cs.tu-bs.de/projects/nmrg/minutes/minutes-023.txt - SNMP traces analysis (common vocabulary for example) and vizualation - Traces analysis: packet arrival times, packet size distributions, message size distributions, message arrival times, message versions, operation distribution, parameter distributions, data type distributions, managed object distribution, data types, notification type distribution, walk arrival times, etc? - Need for common definitions: It would be nice to have common definitions so that we can (i) share some of the tools, (ii) exchange aggregated data for further analysis, and=20 (iii) know precisely what we mean when we use a specific term. Need to define flows, slices, slice types, slice sets, walk, walk types Will be posted as an internet draft=09 - SNMP Trace visualization to show a hierarchy - Conclusions: Meeting was successful in moving work forward Internet-Draft with common definitions is being worked on Expect to see some research papers coming out in 2008 Future work on suitable visualizations needed Additional traces are always welcome. . . Feedback: Sharon: provided feedback at the last IETF about a draft about trace collecting SNMP. However the draft is expired now. Bert: asked to re-shepherd the draft. So ping Juergen a few times Juergen is still developing the document while gaining experience. 5. Reorganization and extension of the OPS Directorate - Ron Bonica Reorganized and retasked The team will receive emails on regular basis: the goal is to review draft from an OPS impact point of view Over time, will review what the OPS requirements=20 Dave Harrington has got a manageability draft. 6. Status of MIB2RDML work - Bob Natale http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt - The problem space: Existing and future SNMP MIBs represent a tremendous source of network management value, both as data models and (when realized via SNMP agents) -- as instrumented management capabilities. So, development of an IETF Standard Methodology for Converting SNMP MIBs to XML Documents via XSD, for XML based application. - During last IETF, Bob was challenged to show the advantages of this method. After some thoughts:=20 Expected Beneficiaries & Benefits * Network Operators: * More unified management solutions from the service layer * Fewer distinct management tools to purchase, integrate, operate, and maintain * Fewer distinct data sources to correlate and validate * Result =3D More timely, complete, accurate network information enables improved service delivery at reduced cost * Network Users: * Improved service performance at (possibly) lower cost due to benefits realized by Network Operators. * XML-based Management Solution Providers: * More appealing products to offer * No need to reinvent the wheel with respect to SNMP MIB data=20 models or instrumentation * SNMP Managed Equipment Providers: * Broader market for existing products w/o code changes * SNMP Management Solution Providers: * Supply MIB to XML conversion/validation tools * Supply XML/SNMP proxy solution * Eventually supply XML-based instrumentation in existing SNMP-managed equipment Background: * IETF-68/Prague - MIB2RMDL (Natale): * Addressed the full conversion problem: * MIB to XML via XSD * XML to ?Resource Model? (e.g., SML, RMD, etc.) * Gateway to SNMP-based instrumentation * IETF-69/Chicago ? XSDMI (Harrington/Li): * Focused on MIB to XML via XSD * Leveraged pre-existing IETF work * MIB2RMDL effort aligned with XSDMI * IETF-70/Vancouver (combined team): * draft-li-natale-smi-datatypes-in-xsd-00.txt * XML-oriented ?consumer? groups asking for alignment in the March 2008 time frame *=20 MIB to XML via XSD Deliverables: * Documents:=20 * SNMP SMI Datatypes in XSD * RFC 2578 and RFC 1155 * SNMP Textual Conventions in XSD * RFC 2579 and select (TBD) other IETF TCs * Optional: Follow-on additional document(s) to cover select (TBD) non-core TCs * SNMP MIB Structure in XSD * Working from libsmi as a starting point * Tools (Optional): * Downloadable/online MIB to XML conversion utilities * Similar to XML2RFC * Reference implementations * MIB to XML * XML to SNMP Gateway Requirements for SMI to XSD Mapping (Objectives: Fidelity and Parsimon Note: the requirements on which we must have agreement. * R1. All SMI datatypes MUST have a corresponding XSD datatype. * R2. In case of conflicting requirements between SMIv1 and SMIv2, SMIv2 MUST take precedence. * R3. The XSD datatype specified for a given SMI datatype MUST be able to represent all valid values for that SMI datatype, and only those values * R4. The XSD datatype specified for a given SMI datatype MUST represent any special encoding rules associated with that SMI datatype. * R5. The XSD datatype specified for a given SMI datatype MUST include any restrictions on values associated with the SMI datatype. * R6. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. * R7. The XML output produced as a result of meeting the foregoing requirements SHOULD be the most direct from the perspective of readability by humans. Proposed SMI Datatypes to XSD Mapping - Recommendations for simpler patterns for 'IpAddress' and 'ObjectIdentifier' which are consistent with the mapping requirements will be enthusiastically welcomed. - Note that the SMIv2 ?BITS? construct remains to be mapped. Feedback: Sharon: division between the SNMP, SMI, and MIB. integer32 and integer64. SNMP could not do 64bits initially. Do we need to have fidelity or can we just say: integer. Bob: looking for fidelity here Dan: what are the next steps? Bob: * Achieve consensus on SMI datatypes to XSD mapping draft: * draft-li-natale-smi-datatypes-in-xsd-00.txt * -01 update to be posted following Vancouver * Identify core set of TCs and publish Core TC to XSD mapping draft: * draft-romascanu-netconf-datatypes-02.txt is a primary source * Define IETF-standard MIB to XML structure and publish mapping draft: * libsmi/smidump XML output tool is a primary source: * draft-li-mib-convert-00.txt * Output from XML option of http://www.ibr.cs.tu-bs.de/projects/libsmi/smidump.html * Refine and publish all drafts as Proposed Standard RFCs Ron, as individual contributor: not data model guru. SMI was not expressive enough for configuration. So any mapping will be lacking any configuration. What guarantee that what we will do (relax NG, yang) will still be compliant Bob: not sure yet.=20 Ron: After this next generation is done, will have to tune it Dave Harrington: to answer Ron. If take SMI and add extra things to it (things in YANG that don't exist in SMI), there is no guarantee ? Yang is done for configuration specifically.=20 For example: state. SNMP doesn't care For example: Netconf needs to know whether this is the startup or running config. SNMP doesn't care SMI has not proved to be very good for configuration. Andy Bierman: limited in scope enough now that it's useful (even if Andy was opposed to it in the past). Andy agrees that fidelity is important. David Harrington: fidelity is an interesting one. TruthValue TC has the value of 1 and 2. Normally, we use 0 and 1. Yang proposes to use 0 and 1. If a new protocol, don't recommend that the truth value from SMI? depending on what needs to be accomplished. while browsing the draft, don't see anything about Ipv6 address. Andy: XML encoding is the key, not XSD. Whether this is XSD or not is irrelevant. Andy: XSD, RelaxNG, Yang has many way to describe the same thing. The XML encoding must be defined. That's critical. Note: draft not posted. http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd- 00.txt=09 7. XML Schema Usage for NETCONF - Sharon Chisholm http://www.ietf.org/internet-drafts/draft-chisholm-netconf-model-07.txt=20 Solution to define content to be exchanged between NETCONF client and NETCONF server, similar to MIB for SNMP. Use XML schema, plus defines appInfo tags (such as minAccess, maxAccess, status, appErrors, eventClass, dataType) to fill in gaps Note that now, relaxNG has got a lot of tools. This was not the case when this job was started. This could be done with relaxNG Modeling Considerations: modularity, data types, elements and attributes, naming implications of using XPATH, proper tag names, granularity of data model, avoid mixed content. Updates in 07:=20 - explain the benefits of the approach - updated notification definition to align with notification ID - clean up examples - deleted the section which outlined specific NETCONF operations against the data model - added an appendix talking about the potential for a mapping to Yang Based on the feedback from this morning, started to compare the XSD, RelaxNG ,Yang. 8. Technical Discussion on the YANG data modeling language - David Partain http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt=20 Technical presentation of Yang. Yang is a SMI for NETCONF: config data, state data, RPCs, and notification Based on SMIng syntax Text based Preserves investment in SNMP MIBs Libsmi translates MIBs to YANG Directly maps to XML content (on the wire) Extensible Add new content to existing data models Add new statement to YANG=20 Very limited scope Based on three proprietary DMLs Running code (www.yang-central.org) Reuse the concept of modules in SMI, but add the notion of submodule Different types in YANG: Leaf: one value, no children, one instance Leaf-list: one value, no children, multiple instances=20 The order is important Container: no value, holds related children, one instance Must: constrain nodes by XPATH expression Has to be fulfilled to be valid List: uniquely identified by keys, holds children Etc? See the slides. YANG gives the syntax, but that's not all: unique, must, keyref, config, default, error-app-tag/error-message, mandatory, presence, ordered-by, notion of derived types, notion of grouping=20 9. Mailing Lists Status - Dan - 5 min - The metalanguage mailing (modeling language for more complex structure with a set of tools) would be closed due to no activities - Mib2rd mailing list would be kept open for some time - Yang mailing list is just started - ngo (NETCONF goes on) mailing list. Now that NETCONF is rechartered? Sharon would like to keep it, for the people. Juergen Sch.: Thinks that there are to many lists. Dave is worried about the 8 copies of the same messages. Will be discussed again. 10. Open microphone - 30 min Dave Pertain: How many read the YANG draft? A lot more than this morning in the aps area. =20 Dan R.: Meet every IETF or every other IETF. Not many hands, a few more for every IETF. David P. Do if there is content. _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area