From hfrazier@broadcom.com Thu Aug 2 15:31:25 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582E821F8B21; Thu, 2 Aug 2012 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGI0dAoI0k0D; Thu, 2 Aug 2012 15:31:24 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0716221F8B20; Thu, 2 Aug 2012 15:31:24 -0700 (PDT) Received: from [10.9.208.55] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Thu, 02 Aug 2012 15:30:23 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from IRVEXCHMB15.corp.ad.broadcom.com ( [fe80::3c14:d213:d2c9:b75a]) by IRVEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Thu, 2 Aug 2012 15:31:11 -0700 From: "Howard Frazier" To: "David Harrington" , "Benoit Claise" , "adslmib mailing list" , "hubmib@ietf.org" Thread-Topic: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) Thread-Index: AQHNbE1void7VQPctk6DF8iY6c38DZc+lwEAgAiGIjA= Date: Thu, 2 Aug 2012 22:31:10 +0000 Message-ID: <1C8A67A466EC7347950EDA3508E95B8403E0F3@IRVEXCHMB15.corp.ad.broadcom.com> References: <5013208E.6020608@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7C0420F53MK16100329-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 02 Aug 2012 18:11:07 -0700 Cc: "Law, David" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:31:25 -0000 I will try to answer David's questions, and I appreciate him taking the time to voice them. >Is there a ***technical*** reason that forces a reassignment of OIDs per >SMIv2 rules, and obsolescence of the IETF MIB modules? In the course of writing IEEE Std 802.3.1, new objects were added to some of the MIB modules, obsolete and deprecated objects were removed from some of the MIB modules, and virtually every object was updated with the latest cross references to the managed object definitions in IEEE Std 802.3. In the current revision project on IEEE Std 802.3.1, many new objects have been added as the result of the many amendments that have been made to IEEE Std 802.3 over the last 4 years. Basically, the Ethernet MIB modules were 4 years out of date when we started this project, and if we hadn't taken on the work, they would be 8 years out of date today, unable to manage 10GBASE-T, Backplane Ethernet, 10GEPON, PoE+, Ethernet extensions to LLDP,=20 40G/100G, Energy Efficient Ethernet, Frame format extensions,=20 and other new developments. For all of these reasons, we felt that it was best to move the=20 modules under an IEEE 802.3 root OID, which is: org ieee(111) standards-association-numbers-series-standards(2)=20 lan-man-stds(802) ieee802dot3(3) ieee802dot3dot1mibs(1) >Have all the original authors been contacted and have they (and their >companies) agreed to grant IEEE these rights? All of the authors listed at the top of the RFCs have been contacted and agreed to grant the IEEE these rights. The IETF Trust has also granted the IEEE these rights with respect to their "boiler plate" material in the RFCs, although we didn't copy any of it to my knowledge. > Will IEEE make subsequent 802.3 MIB documents freely available in text > formats? Absolutely! Now and forever. This is part of the formal project authorizati= on process for this work, and we will continue to publish ASCII text machine=20 readable versions of the MIB modules and make them freely available at all = times. I use Framemaker as the source for both the .PDF and ASCII .txt versions of the MIB modules, so there should be a perfect 1:1 correspondence between the modules published in .PDF and .txt. >If the IEEE will extend the existing MIB modules, within the 1.3.6.1 >branch, I believe they will need to have the new OIDs assigned by IANA. See above. I believe that IEEE 802.3 can act as the registration authority for the new branch and leaf assignments below our OID, as I believe is intended. We do go to IANA for maintenance of the IANA-MAU-MIB, which we import into the IEEE8023-MAU-MIB. I hope that this information is helpful. Please let me know if I have goofed somewhere, or if you have additional concerns. Howard Frazier Chair, IEEE 802.3 Ethernet MIB modules Task Force -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Friday, July 27, 2012 9:55 PM To: Benoit Claise; adslmib mailing list; hubmib@ietf.org Cc: Howard Frazier; ops-area@ietf.org Subject: Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specific MIB Mod= ules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt) Hi, I think there are many implementations of these mib modules. Applications know where to find these data objects by the existing OIDs. In the Bridge MIB case, the IETF standards remained standards, so existing implementations were still compliant to the IETF standard. The IETF Bridge mib modules were widely deployed and used in Enterprise bridging. The structure of the IEEE Bridge modules were modified for technical reasons - the indexing needed to be changed to accommodate per-provider bridging. So the IEEE developed a mib module that used the new indexing, which was a superset of the old IETF MIB design. This change required reassignment of OIDs, per SMIv2 rules. This is described in RFC4663 section 3.2. So the IETF Bridge MIB(s) and IEEE Bridge MIB(s) are actually different MIB modules, both are existing valid standards, and they can coexist. You don't discuss the justifications for changing the names and OID assignments for existing objects. Expecting all devices and NMS applications to do a forklift upgrade just to declare these objects to be in the IEEE tree would make little sense. Many legacy device implementations will never be upgraded, so NMS applications will need to continue to support the IETF MIB modules. Obsoleting these existing standards should have a strong justification. Is there a ***technical*** reason that forces a reassignment of OIDs per SMIv2 rules, and obsolescence of the IETF MIB modules? RFC4663 does not actually transfer the Bridge MIBs to IEEE; it merely describes the process that was followed to transfer the Bridge MIBs to IEEE. Copyright for existing MIB module documents are held by the original authors (not by the IETF). The authors typically have granted the IETF the right to publish, copy, translate, etc. for IETF standardization purposes. The exact rights depend on the state of the IPR policy at time of document publication. The IETF does not have the authority to transfer these rights to the IEEE. As described in RFC4663 3.1, the authors must agree to allow the IEEE to copy and make derivative works from the original documents. If the authors have assigned all intellectual property to their employers, then the companies must agree. Have all the original authors been contacted and have they (and their companies) agreed to grant IEEE these rights? Many NMS tools import text versions of MIB documents; they typically cannot extract and import MIB modules from PDFs. Will IEEE make subsequent 802.3 MIB documents freely available in text formats? This was done for the 802.1 MIB modules. If the IEEE will extend the existing MIB modules, within the 1.3.6.1 branch, I believe they will need to have the new OIDs assigned by IANA. There are quite a few issues with doing this type of transfer, and I recommend documenting the process and the constraints on future development, so future contributors understand the issues and how to deal with them. -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 7/27/12 7:13 PM, "Benoit Claise" wrote: > > =20 > > =20 > =20 > =20 > Dear all, > =20 > While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the > IESG, an issue was brought up. Let me explain. > =20 > The IETF is no longer developing any Ethernet-related MIB modules > and has transferred the responsibility of these development of MIB > modules for Ethernet to the IEEE 802.3 WG. This process has already > started a few years ago, when the HUBMIB WG was shut down. This > process also covers the last RFC produced by the HUBMIG WG, RFC > 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB >. > =20 > =20 > This RFC5066 contains two MIB modules > 1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper), > clearly Ethernet-specific > 2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic > For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to > this MIB module. > =20 > However, according to the agreement, it is within the IEEE > competence to develop the IEEE8023-IF-CAP-STACK-MIB in 802.3.1 > rather than refer RFC 5066. > The issue was raised that it didn't make sense to refer to the > IEEE8023-IF-CAP-STACK-MIB when this cross-connect functionality is > not used for Ethernet, and that the reference RFC5056 was actually > preferred. > =20 > This week, we had an IEEE/IESG meeting where this issue was > discussed between Dan Romascanu (as the IEEE liaison), Howard > Frazier (802.3.1) and myself. > The following has been agreed upon: the EFM-CU-MIB MIB module should > be maintained by IEEE, while the IF-CAP-STACK-MIB should be > maintained by the IETF. > Practically, it means: > 1. Obsoleting RFC 5066 > 2. Creating RFC 5066bis. Extracting IF-CAP-STACK-MIB from RFC5056, > with some wording emphasizing the generic nature of this module, and > clearly mentioning that the IEEE 802.3.1 is responsible for > EFM-CU-MIB. > Ed Beili agreed to take the lead on this document. > 3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain > the following text > =20 > 4.4 Relationship with the IEEE 802.3 MIB modules > >The IEEE 802.3 working group chartered a task force [IEEE802.3.1] which >continues the development of standard MIB modules based on the initial >work done in the IETF. Future projects resulting from the work of this >Task Force may include and possibly extend the work done in the IETF, >such as [RFC5066]. > >------------- > >To Informative References add: > >[IEEE802.3.1] IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 (IEEE >802.3.1a) Ethernet MIBs Task Force, >http://grouper.ieee.org/groups/802/3/1/index.html > =20 > > =20 > Thanks to Howard Frazier. Edward Beili, Menachem Dodge, Dan > Romascanu, and Moti Morgenstern for helping with this issue. This > shows an inter-SDO success story IMHO. > =20 > =20 > A second document has also been discussed. > It would be a good idea to have an informational RFC, similar to RFC > 4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ... >, > with the following content. > 1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 > =20 > RFC 2108 Ethernet Repeater Devices > RFC 3621 - Power Ethernet MIB > RFC 3635 - Ethernet-like Interface Types > RFC 3637 - Ethernet WAN Interface Sublayer > RFC 4836 - Ethernet Medium Attachment Units (MAUs) > RFC 4837 - Ethernet Passive Optical Networks (EPON) > RFC 4878 - Operations, Administration, and Maintenance (OAM) > Functions on Ethernet-Like Interfaces > RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces > MIB > =20 > > 2. A table mapping the old IETF MIB names with the corresponding new > IEEE ones > 3. Clarifications/rules on the IETF-IEEE interactions, mailing > lists, reviews > 4. Clarifications on the intellectual property considerations > =20 > Next to Dan and Ed, Howard agrees to co-author this document. And > that sends a strong positive signal. > =20 > There is one open issue though with this second document: should we > send to historic all the MIB modules mentioned above? What would be > the impact for the equipment vendors and NMS applications? > Dan Romascanu will present this issue at the OPS-AREA meeting. > =20 > Finally, regarding the future cooperation between the IEEE and IETF > regarding the development of the 802.3.1-2011, Howard Frazier > mentioned that any feedback could be sent directly to him, and that > he would insert it into the ballot. > =20 > =20 > Regards, Benoit (OPS A.D.) > =20 > =20 > =20 > =20 > =20 > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From j.schoenwaelder@jacobs-university.de Thu Aug 2 22:10:50 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBA721F8CBB for ; Thu, 2 Aug 2012 22:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXW66g-snXZj for ; Thu, 2 Aug 2012 22:10:49 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A862721F8CB8 for ; Thu, 2 Aug 2012 22:10:47 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3794F20C07; Fri, 3 Aug 2012 07:10:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id O9F2AKH3FZPU; Fri, 3 Aug 2012 07:10:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CEA3420C02; Fri, 3 Aug 2012 07:10:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6B703210349D; Fri, 3 Aug 2012 07:10:42 +0200 (CEST) Date: Fri, 3 Aug 2012 07:10:42 +0200 From: Juergen Schoenwaelder To: ops-area@ietf.org Message-ID: <20120803051042.GA88050@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OPS-AREA] data models and translations / mappings X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 05:10:50 -0000 Hi, During the OPS-AREA meeting today, the topic came up how we plan to deal with the fact that we now have NETCONF and SNMP. One point made was that consistency of the data models is key. I fully agree with that statement. Some people asked during the meeting and after the meeting whether automated translations can not help us solve the problem. Since not everyone might be familiar with the history of similar ideas in the IETF, I thought I write down a few things that might help to understand what we have today and how we got where we are. Back in the late 1990s, policy based management was a big hype. (To a large extend, some of today's brand new ideas resemble ideas that were floating around back then, but lets not get side tracked.) With the policy work, we got the protocols COPS [RFC 2748] and in particular COPS-PR [RFC 3084]. Some believed these new protocols will be the solution to all management problems, but others, of course, did not think that way. One of the questions that came up back then was how we can make things work if we now have both SNMP and COPS-PR. People agreed that we need at least consistency on the data models. (Did I hear this today again?) For those who have not been around back then or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as its data modeling language, a variant of SMIv2 [RFC 2578] . In those days, I thought it should be possible to come up with a new data modeling language that allows to define data models that can work with both SNMP and COPS-PR. The idea was to separate the core data model from the protocol specific bindings. We called this new language SMIng (and yes, by choosing 'ng', this was doomed to failure - but I did not realize that until it was too late ;-). SMIng was first developed in the NMRG of the IRTF and then brought to the IETF. The resulting SMIng working group was tasked to produce first a requirements document. The WG delivered the SMIng objectives in [RFC3216], published in 2001. Subsequently, the working group failed to achieve agreement on the SMIng language itself and it was finally shut down without producing any further results. The SMIng proposal produced by the NMRG was later published in 2004 as [RFC 3780] together with the SNMP binding [RFC 3781]. A few years later, I wrote down some thoughts about the lessons learned from the SMIng project [http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an early version of the paper in case someone is interested why protocol independence is hard to achieve. Just ask. When NETCONF needed a data modeling language, the design team started with the idea that the data modeling language should be as clean and general as possible but we accepted to include support for protocol specifics where they were needed to make things work well. YANG [RFC 6020], published in 2010, resembles in part SMIng but goes much further in expressiveness. Contrary to SMIng, we allowed protocol specifics again to be part of the language (most obvious perhaps with error handling statements that directly relate to how NETCONF signals errors). One thing that has proven valuable is YANG's insensibility. (Some implementations use language extensions to drive the generation of various interfaces out of a YANG specification.) Since YANG is much less constrained than SMIv2, I started to develop a translation algorithm that turns SMIv2 data models into YANG data models. (I started coding this during the first YANG design team meeting I attended back in 2007.) The resulting specification got published recently as [RFC 6643]. While the translation is relatively straightforward, the translation is read-only since the persistence models of SNMP and NETCONF differ widely. With the SMIv2 to YANG mapping in place, you get a read-only YANG data model for any SMIv2 MIB data model (aka MIB) today by simply running a translator. There are open source tools to do that. Are people happy with this? Well, not everybody. While the resulting data model is usable (in my biased view ;-), the result of the translation is of course not as good as a handcrafted translation. Some people seem to also dislike that there is not an authoritative source where translated modules can be found (which may be a fixable problem). In the NETMOD working group, we received very recently some requests to add more handcrafted translations to the YANG modules being developed. Bottom line: People who believe we can move towards generic data models that can be machine translated to produce usable data models for different management protocols may want to study some of the prior work the IETF/IRTF did in this space. All we know for sure is that such translations are not easy, if meaningfully possible at all. /js PS: And let us not forget that IPFIX lives a life of its own with a growing number of "information elements" while SYSLOG is rather loosely structured. It is not just SNMP and NETCONF. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From rbonica@juniper.net Tue Aug 7 12:31:28 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7321F86C5 for ; Tue, 7 Aug 2012 12:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEzXM-wwu9TS for ; Tue, 7 Aug 2012 12:31:27 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id 24FAD21F858A for ; Tue, 7 Aug 2012 12:31:21 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKUCFtCIv/mIMLCl0EvDK2XS/Kf5SJDhzV@postini.com; Tue, 07 Aug 2012 12:31:26 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 7 Aug 2012 12:29:59 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 7 Aug 2012 12:29:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 7 Aug 2012 15:29:53 -0400 From: Ronald Bonica To: "ops-area@ietf.org" Date: Tue, 7 Aug 2012 15:29:52 -0400 Thread-Topic: Management Requirements Thread-Index: Ac1xNl0Sdk0GL8HtQS6jIJpOy/Qt+QCGfaew Message-ID: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> References: <20120803051042.GA88050@elstar.local> In-Reply-To: <20120803051042.GA88050@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" Subject: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 19:31:28 -0000 Folks, The BEHAVE WG brings us a concrete example of a problem that we discussed i= n Vancouver. According to their charter, the BEHAVE WG "creates documents t= o enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fas= hion as possible." Also, according to their charter, the BEHAVE WG "will up= date the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and = specify IPFIX information elements to meet logging requirements, reusing ex= isting elements, if possible." Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETC= ONF is the right tool for configuration? Maybe SNMP is right for fault moni= toring? Maybe syslog is right for maintaining a record of address mappings?= Who knows? My best guess follows...... - The BEHAVE WG knows what information needs to be configured/monitored/pre= served. They MUST specify that. - The BEHAVE WG and the OPS Area have an equal stake in determining which t= ool is recommended to manage each type of data. They should work together t= o make a recommendation. In the best of all possible worlds, that decision = would be informed by a well-documented guideline. However, in the world tha= t we inhabit, that decision may need to be facilitated by a conversation. - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for = the recommended protocols - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for t= he non-recommended protocols Comments? Ron From scott.brim@gmail.com Tue Aug 7 13:01:57 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1BE21F86D0 for ; Tue, 7 Aug 2012 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.593 X-Spam-Level: X-Spam-Status: No, score=-103.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YXfK21RH1gj for ; Tue, 7 Aug 2012 13:01:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C42C121F8619 for ; Tue, 7 Aug 2012 13:01:54 -0700 (PDT) Received: by yhq56 with SMTP id 56so4070yhq.31 for ; Tue, 07 Aug 2012 13:01:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NOyLF9kLvVoC91ecpozcEXnZXwekzT+5fHaCABhT7gA=; b=MSJZVY1vSExvN84icklKP63MY/Egvbl3E6B4ZPYVGstStotRwTay3sdFr5FYrbX5P0 Qm3YVrs3dfCYRUgCrHMb4OyN/BUeBeIZTuAjXazwTp5ds2ZRM7tT4iJGAOiPiqd5OA2S INLcnVSWUBG2EuKxBxNRXnk+g1xW7KjTGwPKH7nxTprJm2E70BXFG9ef5WKC8eGg3ofO HfQYulxMti0/AQ6YDRfyW8wse+Omd5jolh7dSnZ3wrD4TlrnZnc3iXY0W2hhKa4QZuk+ mQosc+BshXk/WFMtaet1NRw3HVY7RKGGOlA8GGjqA8xjRlt0rB+R2iBquCeNNj2i/QNJ S4Gw== MIME-Version: 1.0 Received: by 10.68.231.170 with SMTP id th10mr30342373pbc.104.1344369713918; Tue, 07 Aug 2012 13:01:53 -0700 (PDT) Received: by 10.68.48.231 with HTTP; Tue, 7 Aug 2012 13:01:53 -0700 (PDT) Received: by 10.68.48.231 with HTTP; Tue, 7 Aug 2012 13:01:53 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> Date: Tue, 7 Aug 2012 16:01:53 -0400 Message-ID: From: Scott Brim To: Ronald Bonica Content-Type: multipart/alternative; boundary=047d7b339cbd3eb3f404c6b2770f Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:01:57 -0000 --047d7b339cbd3eb3f404c6b2770f Content-Type: text/plain; charset=ISO-8859-1 On Aug 7, 2012 3:31 PM, "Ronald Bonica" wrote: > - The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation. ... > Comments? Yup... but I hesitate to install rules. This is not a situation where the responsibilities and powers need to be nailed down. We're better off with general statements about how we work and the relationships we strive for than with detailed procedures. --047d7b339cbd3eb3f404c6b2770f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Aug 7, 2012 3:31 PM, "Ronald Bonica" <rbonica@juniper.net> wrote:
> - The BEHAVE WG and the OPS Area have an equal stake in determining wh= ich tool is recommended to manage each type of data. They should work toget= her to make a recommendation. In the best of all possible worlds, that deci= sion would be informed by a well-documented guideline. However, in the worl= d that we inhabit, that decision may need to be facilitated by a conversati= on.
...
> Comments?

Yup...=A0 but I hesitate to install rules. This is not a sit= uation where the responsibilities and powers need to be nailed down.=A0 We&= #39;re better off with general statements about how we work and the relatio= nships we strive for than with detailed procedures.=A0

--047d7b339cbd3eb3f404c6b2770f-- From j.schoenwaelder@jacobs-university.de Tue Aug 7 13:54:55 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297EF21F8559 for ; Tue, 7 Aug 2012 13:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onq7P7XJ+m4k for ; Tue, 7 Aug 2012 13:54:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4277221F8550 for ; Tue, 7 Aug 2012 13:54:54 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38CBD20BF9; Tue, 7 Aug 2012 22:54:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bvjg4BWT9VfH; Tue, 7 Aug 2012 22:54:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAC0D20BF8; Tue, 7 Aug 2012 22:54:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BD17C21084AF; Tue, 7 Aug 2012 22:54:52 +0200 (CEST) Date: Tue, 7 Aug 2012 22:54:52 +0200 From: Juergen Schoenwaelder To: Ronald Bonica Message-ID: <20120807205452.GA95595@elstar.local> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:54:55 -0000 On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote: > Folks, > > The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible." > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows? > For configuration, NETCONF/YANG is the right choice. There is nothing that really competes for configuration. For event notifications, you have at least SYSLOG, SNMP notifications, IPFIX, NETCONF notifications. I think the last one is likely not a main target. SNMP notifications means one SNMP message per event and the same holds true for SYSLOG; IPFIX allows to send a collection of events in one IPFIX message and hence it might be more scalable, which might be important for some NAT deployments. For retrieving operational state and debugging, both SNMP and NETCONF can work. If the data structures tend to be more complex and/or the data instances are of larger volume, NETCONF has some advances (more efficient bulk transfer). If data needs to travel over shaky links (e.g. high levels of packet loss), SNMP _can_ have an advantage. Perhaps these thoughts help to make a suitable decision. One could of course also ask what the contributors prefer to implement, e.g. what they expect to ease integration into management systems relevant for the protocol domain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Tue Aug 7 14:02:06 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5E311E80AE for ; Tue, 7 Aug 2012 14:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU9rUJIOaQln for ; Tue, 7 Aug 2012 14:02:05 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A4A8011E80A6 for ; Tue, 7 Aug 2012 14:02:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPWBIVDGmAcF/2dsb2JhbABFuWaBB4IgAQEBAQIBEh4KPwUHBAIBCA0BAwQBAQEKBgwLAQYBRQkIAQEEAQkJCBMHh2UGnjadZosPhgBgA5tFig+CYQ X-IronPort-AV: E=Sophos;i="4.77,728,1336363200"; d="scan'208";a="360788127" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Aug 2012 16:57:32 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Aug 2012 16:56:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2012 23:01:37 +0200 Message-ID: In-Reply-To: <20120807205452.GA95595@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Management Requirements Thread-Index: Ac103umBJsgmwhP0Ro2pEzoAjD/82gAAGhwg References: <20120803051042.GA88050@elstar.local><13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Ronald Bonica" Cc: tsv-ads@tools.ietf.org, behave-chairs@tools.ietf.org, ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:02:06 -0000 > -----Original Message----- > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, August 07, 2012 11:55 PM > To: Ronald Bonica > Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; ops- > area@ietf.org > Subject: Re: [OPS-AREA] Management Requirements >=20 > On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote: > > Folks, > > > > The BEHAVE WG brings us a concrete example of a problem that we > > discussed in Vancouver. According to their charter, the BEHAVE WG > "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in > as deterministic a fashion as possible." Also, according to their > charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible." > > > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe > NETCONF is the right tool for configuration? Maybe SNMP is right for > fault monitoring? Maybe syslog is right for maintaining a record of > address mappings? Who knows? > > >=20 > For configuration, NETCONF/YANG is the right choice. There is nothing > that really competes for configuration. >=20 > For event notifications, you have at least SYSLOG, SNMP notifications, > IPFIX, NETCONF notifications. I think the last one is likely not a main > target. SNMP notifications means one SNMP message per event and the same > holds true for SYSLOG; IPFIX allows to send a collection of events in > one IPFIX message and hence it might be more scalable, which might be > important for some NAT deployments. >=20 > For retrieving operational state and debugging, both SNMP and NETCONF > can work. If the data structures tend to be more complex and/or the data > instances are of larger volume, NETCONF has some advances (more > efficient bulk transfer). If data needs to travel over shaky links (e.g. > high levels of packet loss), SNMP _can_ have an advantage. >=20 > Perhaps these thoughts help to make a suitable decision. One could of > course also ask what the contributors prefer to implement, e.g. what > they expect to ease integration into management systems relevant for the > protocol domain. >=20 > /js [[DR]] I agree with all the analysis made by Juergen, maybe with one reservation:=20 > SNMP notifications means one SNMP message per event and the same > holds true for SYSLOG; IPFIX allows to send a collection of events in > one IPFIX message and hence it might be more scalable, which might be > important for some NAT deployments. You can actually send more than one SNMP message per event if you define the notifications accordingly, so I say that this really depends upon modeling. On the other hand if 'real-time'-liness is a requirement - a.k.a as soon as certain events happen you _may_ have an advantage with SNMP notifications.=20 Regards, Dan From mrm@vmware.com Tue Aug 7 14:17:03 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88C111E80AE for ; Tue, 7 Aug 2012 14:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUsJak0JSTNY for ; Tue, 7 Aug 2012 14:17:03 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 337D511E809B for ; Tue, 7 Aug 2012 14:17:03 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id C5EA02822C; Tue, 7 Aug 2012 14:17:01 -0700 (PDT) Received: from zimbra-prod-mta-2.vmware.com (zimbra-prod-mta-2.vmware.com [10.113.160.174]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id C0E13B052D; Tue, 7 Aug 2012 14:17:01 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-2.vmware.com (Postfix) with ESMTP id B9FD822793; Tue, 7 Aug 2012 14:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-2.vmware.com Received: from zimbra-prod-mta-2.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-2.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fak8jAwXcszJ; Tue, 7 Aug 2012 14:17:01 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zimbra-prod-mta-2.vmware.com (Postfix) with ESMTP id 9DB6022791; Tue, 7 Aug 2012 14:17:01 -0700 (PDT) Date: Tue, 7 Aug 2012 14:17:01 -0700 (PDT) From: Michael MacFaden To: Ronald Bonica Message-ID: <324090431.8439135.1344374221530.JavaMail.root@vmware.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: tsv-ads@tools.ietf.org, behave-chairs@tools.ietf.org, ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:17:03 -0000 rbonica writes: > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. > Maybe NETCONF is the right tool for configuration? Maybe SNMP is > right for fault monitoring? Maybe syslog is right for maintaining a > record of address mappings? Who knows? Right implementers have to make many choices which are predisposed by their personal experience and company leanings. A given implementation might have the following: an SNMP agent with particular mib modules and notifications to monitor one or more instances of this service. IPFIX agent might report complimentary information elements and not necessarily match 1:1 what one would monitor via SNMP. If configuration is more complex than can be described in SMIv2 then using YANG to express configuration makes sense even if NETCONF is never deployed. I find it will end up in the proprietary CLI/API. And yes syslog gets used for detailed reporting diagnostics but have not seen any standard ever need to go that far (yet). So while not all of these might be used by an operator, having all available in a given product vastly improves its fit into diverse operational environments. (Vendor speak for less time to get to full deployment & getting paid). My advice to product teams has always been to consider the data model in the MIB module for IETF protocols (or whatever the related mgmt spec for non-IETF technology standards). I find that the strings for mgmt terms in these specs get propagated into products doc/interfaces/etc even if the product doesn't implement an SNMP agent. SMIv2 syntax MIB modules, especially when written with decent REFERENCE clauses to the underlying spec, really help to frame which operations and data should be considered by the implementer using whatever mgmt protocols they choose. HTH, Mike MacFaden From j.schoenwaelder@jacobs-university.de Tue Aug 7 14:47:22 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7B21F86C5 for ; Tue, 7 Aug 2012 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFn5+AkzwWvV for ; Tue, 7 Aug 2012 14:47:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 221FF21F861B for ; Tue, 7 Aug 2012 14:47:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38BCA20BF5; Tue, 7 Aug 2012 23:47:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id EXugWe3HE5dv; Tue, 7 Aug 2012 23:47:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 140BC20BE2; Tue, 7 Aug 2012 23:47:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1196C21085AC; Tue, 7 Aug 2012 23:47:17 +0200 (CEST) Date: Tue, 7 Aug 2012 23:47:17 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20120807214716.GA95663@elstar.local> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ops-area@ietf.org, behave-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:47:22 -0000 On Tue, Aug 07, 2012 at 11:01:37PM +0200, Romascanu, Dan (Dan) wrote: > > [[DR]] I agree with all the analysis made by Juergen, maybe with one > reservation: > > > SNMP notifications means one SNMP message per event and the same > > holds true for SYSLOG; IPFIX allows to send a collection of events in > > one IPFIX message and hence it might be more scalable, which might be > > important for some NAT deployments. > > You can actually send more than one SNMP message per event if you define > the notifications accordingly, so I say that this really depends upon > modeling. On the other hand if 'real-time'-liness is a requirement - > a.k.a as soon as certain events happen you _may_ have an advantage with > SNMP notifications. I have not been considering the case of M>1 messages per event. I was writing about the case of E>1 events per message. SNMP limits things to at best to one event per message. IPFIX seems to be able to batch several events into a single IPFIX message. Of course, there are other considerations here, the congestion control of the underlying transport and whether a high-level of event notifications are needed in the first place. Since this comes up in BEHAVE context, there might be legal requirements (in some legislations) to do full session logging of so called carrier grade NATs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dthaler@microsoft.com Tue Aug 7 14:52:00 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2763F11E80A4 for ; Tue, 7 Aug 2012 14:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.683 X-Spam-Level: X-Spam-Status: No, score=-103.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN1Du--raqXX for ; Tue, 7 Aug 2012 14:51:54 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4C18511E809B for ; Tue, 7 Aug 2012 14:51:54 -0700 (PDT) Received: from mail52-am1-R.bigfish.com (10.3.201.252) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 21:51:52 +0000 Received: from mail52-am1 (localhost [127.0.0.1]) by mail52-am1-R.bigfish.com (Postfix) with ESMTP id 8FE7B1A0113; Tue, 7 Aug 2012 21:51:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail52-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail52-am1 (localhost.localdomain [127.0.0.1]) by mail52-am1 (MessageSwitch) id 1344376310601794_26958; Tue, 7 Aug 2012 21:51:50 +0000 (UTC) Received: from AM1EHSMHS018.bigfish.com (unknown [10.3.201.250]) by mail52-am1.bigfish.com (Postfix) with ESMTP id 90B262A0049; Tue, 7 Aug 2012 21:51:50 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS018.bigfish.com (10.3.207.156) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 21:51:50 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 7 Aug 2012 21:51:45 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Tue, 7 Aug 2012 14:51:45 -0700 From: Dave Thaler To: Juergen Schoenwaelder , Ronald Bonica Thread-Topic: [OPS-AREA] Management Requirements Thread-Index: AQHNdNNCJ+/UV9YI+kO7kJ1VwbfOz5dPSXoA//+YvdA= Date: Tue, 7 Aug 2012 21:51:44 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> In-Reply-To: <20120807205452.GA95595@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%2%microsoft.com%True%True%0$ X-OriginatorOrg: microsoft.com Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 21:52:00 -0000 > -----Original Message----- > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Tuesday, August 07, 2012 1:55 PM > To: Ronald Bonica > Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; ops-area@ietf.o= rg > Subject: Re: [OPS-AREA] Management Requirements >=20 > On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote: > > Folks, > > > > The BEHAVE WG brings us a concrete example of a problem that we > > discussed in Vancouver. According to their charter, the BEHAVE WG > "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in = as > deterministic a fashion as possible." Also, according to their charter, t= he > BEHAVE WG "will update the NAT MIB (RFC 4008) to be consistent with the > management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX > information elements to meet logging requirements, reusing existing > elements, if possible." > > > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe > NETCONF is the right tool for configuration? Maybe SNMP is right for faul= t > monitoring? Maybe syslog is right for maintaining a record of address > mappings? Who knows? > > >=20 > For configuration, NETCONF/YANG is the right choice. There is nothing tha= t > really competes for configuration. Currently the Behave WG isn't looking at configuration, only monitoring and eventing. And my understanding is that presently it's not a=20 requirement that WG's have a configuration solution, it's up to the WG. =20 > For event notifications, you have at least SYSLOG, SNMP notifications, IP= FIX, > NETCONF notifications. I think the last one is likely not a main target. = SNMP > notifications means one SNMP message per event and the same holds true > for SYSLOG; IPFIX allows to send a collection of events in one IPFIX mess= age > and hence it might be more scalable, which might be important for some NA= T > deployments. I've heard it said that IPFIX is for packet sampling not for metadata event= ing, but this isn't an area I know enough about myself to say. I would like to= say that the Behave WG shouldn't do multiple solutions for the same thing. I'd like the OPS area folks to help us decide which one is the most appropr= iate one. Currently we have a small number of individuals each advocating a different protocol, and a large number of individuals (myself included) that have no preference and want the OPS area experts to give guidance. =20 > For retrieving operational state and debugging, both SNMP and NETCONF > can work. If the data structures tend to be more complex and/or the data > instances are of larger volume, NETCONF has some advances (more efficient > bulk transfer). If data needs to travel over shaky links (e.g. high level= s of > packet loss), SNMP _can_ have an advantage. The data instances can have a larger volume and may need to travel over shaky links. Also there's an existing MIB that is outdated and we want to obsolete. So the WG is currently using SNMP for retrieving=20 operational state and debugging, by doing an update that is intended to obsolete the existing MIB RFC. =20 > Perhaps these thoughts help to make a suitable decision. One could of > course also ask what the contributors prefer to implement, e.g. what they > expect to ease integration into management systems relevant for the > protocol domain. Answered above. Looking to OPS for clear guidance on what eventing protocol to use (or what criteria we should use to decide). I don't want multiple ones. -Dave=20 From mgia0477@motorola.com Tue Aug 7 14:36:24 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17521F8668 for ; Tue, 7 Aug 2012 14:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZDik4ArbYtp for ; Tue, 7 Aug 2012 14:36:23 -0700 (PDT) Received: from exprod5og110.obsmtp.com (exprod5og110.obsmtp.com [64.18.0.20]) by ietfa.amsl.com (Postfix) with ESMTP id F25E321F8667 for ; Tue, 7 Aug 2012 14:36:22 -0700 (PDT) Received: from il93mgrg01.am.mot-mobility.com ([144.188.21.13]) (using TLSv1) by exprod5ob110.postini.com ([64.18.4.12]) with SMTP ID DSNKUCGKVjcmlABTZF5Bfa4fEEcpll+3Hw90@postini.com; Tue, 07 Aug 2012 14:36:23 PDT Received: from il93mgrg01.am.mot-mobility.com ([10.176.130.20]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id q77LRsh9008676 for ; Tue, 7 Aug 2012 17:27:54 -0400 (EDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id q77LG8Ht023199 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 7 Aug 2012 17:16:08 -0400 (EDT) Received: by pbbrr13 with SMTP id rr13so271857pbb.5 for ; Tue, 07 Aug 2012 14:24:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=2UQ+ve0R70O3U9rIEt1P1B5RZkLe2f6hgxiSydYYC+Y=; b=Wonzc6hL39+JFf4Rd99hMCP9f1BG6QX05ljPfhbY8w97GvvuEVYnI+ZmarfpNnzh1X 4RcRgBJyliq+R+VslCzInW2DcJrrh9RdsPkkmU4w2w2xfY5dNnLMhSQmTu/CzjyTaiY8 hlUlsOeV+IiU2CIcLbMmb0ph0+W9MBVA+t5+h5L3kSBkSO/aLckVQ0HpLf3MNy5BPKsQ UzyOeRs5OD43cniiSw6d8rvOE0fqZ+LaaJGZ/igD7Slb9eK8clSYtiPYaC55rF++sJxb fwj4kvwSFDnPjDOy+EoKuU8M6HnFblEIK7e8FNdrNvQePTLL2iOp8sKjiMkmheqiIKaA HH5Q== MIME-Version: 1.0 Received: by 10.68.193.137 with SMTP id ho9mr1529201pbc.93.1344374675635; Tue, 07 Aug 2012 14:24:35 -0700 (PDT) Received: by 10.68.6.135 with HTTP; Tue, 7 Aug 2012 14:24:35 -0700 (PDT) In-Reply-To: References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> Date: Tue, 7 Aug 2012 17:24:35 -0400 Message-ID: From: Andrew Donati To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=047d7b15af45fc7da604c6b39e1b X-Gm-Message-State: ALoCoQlx8fbEXhf7gXDwSgO53/JQ+iVbAwxjaNw36tmOu6TfylD0SO43JCcyr4PRSUXSkieHUgXX X-CFilter-Loop: Reflected Cc: ops-area@ietf.org, behave-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:00:55 -0000 --047d7b15af45fc7da604c6b39e1b Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 7, 2012 at 5:01 PM, Romascanu, Dan (Dan) wrote: > > > > > > -----Original Message----- > > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Tuesday, August 07, 2012 11:55 PM > > To: Ronald Bonica > > Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; ops- > > area@ietf.org > > Subject: Re: [OPS-AREA] Management Requirements > > > > On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote: > > > Folks, > > > > > > The BEHAVE WG brings us a concrete example of a problem that we > > > discussed in Vancouver. According to their charter, the BEHAVE WG > > "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function > in > > as deterministic a fashion as possible." Also, according to their > > charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > > consistent with the management aspects of its IPv6/IPv4 NAT solutions, > > and specify IPFIX information elements to meet logging requirements, > > reusing existing elements, if possible." > > > > > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. > Maybe > > NETCONF is the right tool for configuration? Maybe SNMP is right for > > fault monitoring? Maybe syslog is right for maintaining a record of > > address mappings? Who knows? > > > > > > > For configuration, NETCONF/YANG is the right choice. There is nothing > > that really competes for configuration. > > > > For event notifications, you have at least SYSLOG, SNMP notifications, > > IPFIX, NETCONF notifications. I think the last one is likely not a > main > > target. SNMP notifications means one SNMP message per event and the > same > > holds true for SYSLOG; IPFIX allows to send a collection of events in > > one IPFIX message and hence it might be more scalable, which might be > > important for some NAT deployments. > > > > For retrieving operational state and debugging, both SNMP and NETCONF > > can work. If the data structures tend to be more complex and/or the > data > > instances are of larger volume, NETCONF has some advances (more > > efficient bulk transfer). If data needs to travel over shaky links > (e.g. > > high levels of packet loss), SNMP _can_ have an advantage. > > > > Perhaps these thoughts help to make a suitable decision. One could of > > course also ask what the contributors prefer to implement, e.g. what > > they expect to ease integration into management systems relevant for > the > > protocol domain. > > > > /js > > [[DR]] I agree with all the analysis made by Juergen, maybe with one > reservation: > > > SNMP notifications means one SNMP message per event and the same > > holds true for SYSLOG; IPFIX allows to send a collection of events in > > one IPFIX message and hence it might be more scalable, which might be > > important for some NAT deployments. > > You can actually send more than one SNMP message per event if you define > the notifications accordingly, so I say that this really depends upon > modeling. On the other hand if 'real-time'-liness is a requirement - > a.k.a as soon as certain events happen you _may_ have an advantage with > SNMP notifications. > > Regards, > > Dan > > [AD] Adding another item to what Juergen listed on the task of monitoring: > For retrieving operational state and debugging, both SNMP and NETCONF > can work. If the data structures tend to be more complex and/or the data > instances are of larger volume, NETCONF has some advances (more > efficient bulk transfer). If data needs to travel over shaky links > (e.g. > high levels of packet loss), SNMP _can_ have an advantage. For retrieving operational state and debugging on more than one or a few devices, SNMP can have the advantage. SNMP works well when monitoring numerous devices at once. - Andy --047d7b15af45fc7da604c6b39e1b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 7, 2012 at 5:01 PM, Romascan= u, Dan (Dan) <dromasca@avaya.com> wrote:




> -----Original Message-----
> From: ops-area-bounces@ie= tf.org [mailto:ops-area-bo= unces@ietf.org] On
> Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, August 07, 2012 11:55 PM
> To: Ronald Bonica
> Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.iet= f.org; ops-
> area@ietf.org
> Subject: Re: [OPS-AREA] Management Requirements
>
> On Tue, Aug 07, 2012 at 03:29:52PM -0400, Ronald Bonica wrote:
> > Folks,
> >
> > The BEHAVE WG brings us a concrete example of a problem that we > > discussed in Vancouver. According to their charter, the BEHAVE WG=
> "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to func= tion
in
> as deterministic a fashion as possible." Also, according to their=
> charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be<= br> > consistent with the management aspects of its IPv6/IPv4 NAT solutions,=
> and specify IPFIX information elements to meet logging requirements, > reusing existing elements, if possible."
> >
> > Now BEHAVE is asking whether SNMP and IPFIX are the right tools.<= br> Maybe
> NETCONF is the right tool for configuration? Maybe SNMP is right for > fault monitoring? Maybe syslog is right for maintaining a record of > address mappings? Who knows?
> >
>
> For configuration, NETCONF/YANG is the right choice. There is nothing<= br> > that really competes for configuration.
>
> For event notifications, you have at least SYSLOG, SNMP notifications,=
> IPFIX, NETCONF notifications. I think the last one is likely not a
main
> target. SNMP notifications means one SNMP message per event and the same
> holds true for SYSLOG; IPFIX allows to send a collection of events in<= br> > one IPFIX message and hence it might be more scalable, which might be<= br> > important for some NAT deployments.
>
> For retrieving operational state and debugging, both SNMP and NETCONF<= br> > can work. If the data structures tend to be more complex and/or the data
> instances are of larger volume, NETCONF has some advances (more
> efficient bulk transfer). If data needs to travel over shaky links
(e.g.
> high levels of packet loss), SNMP _can_ have an advantage.
>
> Perhaps these thoughts help to make a suitable decision. One could of<= br> > course also ask what the contributors prefer to implement, e.g. what > they expect to ease integration into management systems relevant for the
> protocol domain.
>
> /js

[[DR]] I agree with all the analysis made by Juergen, maybe with one
reservation:

> SNMP notifications means one SNMP message per event and the same
> holds true for SYSLOG; IPFIX allows to send a collection of events in<= br> > one IPFIX message and hence it might be more scalable, which might be<= br> > important for some NAT deployments.

You can actually send more than one SNMP message per event if you define the notifications accordingly, so I say that this really depends upon
modeling. On the other hand if 'real-time'-liness is a requirement = -
a.k.a as soon as certain events happen you _may_ have an advantage with
SNMP notifications.

Regards,

Dan

[AD]=A0 Adding another item to w= hat Juergen listed on the task of monitoring:

> For retrieving op= erational state and debugging, both SNMP and NETCONF
> can work. If the data structures tend to be more complex and/or the da= ta
> instances are of larger volume, NETCONF has some advances (more
> efficient bulk transfer). If data needs to travel over shaky links
> (e.g.
> high levels of packet loss), SNMP _can_ have an advantage.

For = retrieving operational state and debugging on more than one or a few devic= es,
SNMP can have the advantage.=A0 SNMP works well when monitoring
numerous devices at once.

- Andy




--047d7b15af45fc7da604c6b39e1b-- From mrm@vmware.com Tue Aug 7 15:38:35 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A4121F86EC for ; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POsuEd1B3r7k for ; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76021F86EB for ; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 30D8128257; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Received: from zimbra-prod-mta-1.vmware.com (zimbra-prod-mta-1.vmware.com [10.113.160.173]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 2D398B053E; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id 26457618A5; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra-prod-mta-1.vmware.com Received: from zimbra-prod-mta-1.vmware.com ([127.0.0.1]) by localhost (zimbra-prod-mta-1.vmware.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJm8UirpYyvL; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Received: from zimbra-prod-mbox-2.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zimbra-prod-mta-1.vmware.com (Postfix) with ESMTP id 06F4D61839; Tue, 7 Aug 2012 15:38:35 -0700 (PDT) Date: Tue, 7 Aug 2012 15:38:34 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder , "Dan Romascanu (Dan)" Message-ID: <216855245.8502314.1344379114937.JavaMail.root@vmware.com> In-Reply-To: <20120807214716.GA95663@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.60.13] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - GC20 (Mac)/7.2.0_GA_2669) Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:38:35 -0000 > I have not been considering the case of M>1 messages per event. > > I was writing about the case of E>1 events per message. SNMP limits > things to at best to one event per message. IPFIX seems to be able to > batch several events into a single IPFIX message. Of course, there > are other considerations here, the congestion control of the underlying > transport and whether a high-level of event notifications are needed > in the first place. Since this comes up in BEHAVE context, there I agree with Juergen on mechanics but think its not entirely an apples to apples comparison. IPFIX transmits all its state periodically in one go whereas SNMP uses notifications to indicate state *has* changed and may not provide the entire context of what changed for a reason : that mgmt apps using trap a directed polling model will then poll the agent for updated state based on the type/content of such notifications. Hence my comment to Ron about the two being more complimentary technologies than one might think as we've begun to see IPFIX attempt to do more of what SNMP has done though imo not without solving the problems that trap directed polling had previously solved. I'd also note that we provided the following advice to mib module authors in RFC 3512: No matter which threshold is chosen to govern the actual transmission of NOTIFICATION-TYPEs, the idea is to describe an aggregated event or related set of events in as few PDUs as possible. http://tools.ietf.org/html/rfc3512#section-3.10.2 Mike From j.schoenwaelder@jacobs-university.de Tue Aug 7 15:43:11 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872921F86F4 for ; Tue, 7 Aug 2012 15:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkqFes5Sj3pR for ; Tue, 7 Aug 2012 15:43:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 128B421F86E5 for ; Tue, 7 Aug 2012 15:43:10 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69DBA20BF8; Wed, 8 Aug 2012 00:43:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IhRVmSQ5XKwB; Wed, 8 Aug 2012 00:43:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 071CB20BF3; Wed, 8 Aug 2012 00:43:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 423BC21086E4; Wed, 8 Aug 2012 00:43:08 +0200 (CEST) Date: Wed, 8 Aug 2012 00:43:07 +0200 From: Juergen Schoenwaelder To: Dave Thaler Message-ID: <20120807224306.GA95745@elstar.local> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ops-area@ietf.org" , "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 22:43:11 -0000 On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote: > > The data instances can have a larger volume and may need to travel over > shaky links. Also there's an existing MIB that is outdated and we want > to obsolete. So the WG is currently using SNMP for retrieving > operational state and debugging, by doing an update that is intended > to obsolete the existing MIB RFC. Out of curiosity, is there meanwhile a clear description you can point to explaining why the old NAT-MIB is broken? > > Perhaps these thoughts help to make a suitable decision. One could of > > course also ask what the contributors prefer to implement, e.g. what they > > expect to ease integration into management systems relevant for the > > protocol domain. > > Answered above. Looking to OPS for clear guidance on what eventing > protocol to use (or what criteria we should use to decide). I don't want > multiple ones. What are the events considered? How frequent will they occur? How stringent are the requirements to deliver them (almost) all or is the even source designed to throttle notifications? How much data is needed to describe the events? If all that is rather "standard" (in terms of notification volume and individual notification size), then SNMP might just do fine. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dthaler@microsoft.com Tue Aug 7 16:23:03 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3002511E80F7 for ; Tue, 7 Aug 2012 16:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.181 X-Spam-Level: X-Spam-Status: No, score=-105.181 tagged_above=-999 required=5 tests=[AWL=1.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlEJpCtYFxXQ for ; Tue, 7 Aug 2012 16:23:01 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8111E80F3 for ; Tue, 7 Aug 2012 16:23:01 -0700 (PDT) Received: from mail194-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.23; Tue, 7 Aug 2012 23:23:00 +0000 Received: from mail194-tx2 (localhost [127.0.0.1]) by mail194-tx2-R.bigfish.com (Postfix) with ESMTP id CB57E3A0115; Tue, 7 Aug 2012 23:23:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VS-28(zz98dI9371I542M1432Izz1202hzz1033IL8275dhz2fh2a8h668h839h944hd25hf0ah107ah) Received-SPF: pass (mail194-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail194-tx2 (localhost.localdomain [127.0.0.1]) by mail194-tx2 (MessageSwitch) id 1344381779388141_30867; Tue, 7 Aug 2012 23:22:59 +0000 (UTC) Received: from TX2EHSMHS037.bigfish.com (unknown [10.9.14.243]) by mail194-tx2.bigfish.com (Postfix) with ESMTP id 5999838007F; Tue, 7 Aug 2012 23:22:59 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS037.bigfish.com (10.9.99.137) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 7 Aug 2012 23:22:59 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 7 Aug 2012 23:22:57 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 7 Aug 2012 16:22:57 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Tue, 7 Aug 2012 16:22:57 -0700 From: Dave Thaler To: Juergen Schoenwaelder Thread-Topic: [OPS-AREA] Management Requirements Thread-Index: AQHNdNNCJ+/UV9YI+kO7kJ1VwbfOz5dPSXoA//+YvdCAAIWBgP//lHRw Date: Tue, 7 Aug 2012 23:22:56 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B745C6A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <20120807224306.GA95745@elstar.local> In-Reply-To: <20120807224306.GA95745@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%2%microsoft.com%True%True%0$ X-OriginatorOrg: microsoft.com Cc: "ops-area@ietf.org" , "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 23:23:03 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, August 07, 2012 3:43 PM > To: Dave Thaler > Cc: Ronald Bonica; tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; = ops- > area@ietf.org > Subject: Re: [OPS-AREA] Management Requirements >=20 > On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote: > > > > The data instances can have a larger volume and may need to travel over > > shaky links. Also there's an existing MIB that is outdated and we wan= t > > to obsolete. So the WG is currently using SNMP for retrieving > > operational state and debugging, by doing an update that is intended > > to obsolete the existing MIB RFC. >=20 > Out of curiosity, is there meanwhile a clear description you can point to > explaining why the old NAT-MIB is broken? The current text by the authors of the update is at http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1 =20 > > > Perhaps these thoughts help to make a suitable decision. One could > > > of course also ask what the contributors prefer to implement, e.g. > > > what they expect to ease integration into management systems > > > relevant for the protocol domain. > > > > Answered above. Looking to OPS for clear guidance on what eventing > > protocol to use (or what criteria we should use to decide). I don't w= ant > > multiple ones. >=20 > What are the events considered? How frequent will they occur? How > stringent are the requirements to deliver them (almost) all or is the eve= n > source designed to throttle notifications? How much data is needed to > describe the events?=20 One example would be creation/deletion of a mapping table entry. Depending on the exact techniques used by the instrumented implementation it may range from extremely frequent and large volume, to infrequent and small volume. There is no discussion of throttling, only of techniques that one could use to reduce the volume (independent of the protocol used to report events). How much data? Probably tens of bytes per event= . > If all that is rather "standard" (in terms of notification > volume and individual notification size), then SNMP might just do fine. Looking not for what "might do fine" per se, as that might be a large numbe= r of protocols, but rather for what single protocol is recommended or alternativ= ely, a set of guidance on how a WG should choose among various protocols. -Dave From ietfdbh@comcast.net Tue Aug 7 17:17:07 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7987321F86D6 for ; Tue, 7 Aug 2012 17:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUCtEanAL0mf for ; Tue, 7 Aug 2012 17:17:06 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB2721F86D4 for ; Tue, 7 Aug 2012 17:17:05 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id jnjj1j0071ap0As530H8Q3; Wed, 08 Aug 2012 00:17:08 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta22.westchester.pa.mail.comcast.net with comcast id k0HJ1j00J3Ecudz3i0HKAm; Wed, 08 Aug 2012 00:17:24 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Tue, 07 Aug 2012 20:16:58 -0400 From: David Harrington To: Ronald Bonica , "ops-area@ietf.org" Message-ID: Thread-Topic: [OPS-AREA] Management Requirements In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 00:17:07 -0000 Hi, Comments inline ... On 8/7/12 3:29 PM, "Ronald Bonica" wrote: >Folks, > >The BEHAVE WG brings us a concrete example of a problem that we discussed >in Vancouver. According to their charter, the BEHAVE WG "creates >documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as >deterministic a fashion as possible." Also, according to their charter, >the BEHAVE WG "will update the NAT MIB (RFC 4008) to be >consistent with the management aspects of its IPv6/IPv4 NAT solutions, >and specify IPFIX information elements to meet logging requirements, >reusing existing elements, if possible." > >Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe >NETCONF is the right tool for configuration? Maybe SNMP is right for >fault monitoring? Maybe syslog is right for maintaining a record of >address mappings? Who knows? The operator should know, based on their operational/management environment. Since we don't know their operational/management environment, it is hard for us to decide which protocols are appropriate. What we can do is design our technologies to meet certain needs, and then to provide guidelines/applicability statements for our technologies. > >My best guess follows...... > >- The BEHAVE WG knows what information needs to be >configured/monitored/preserved. They MUST specify that. Agreed. An information model is a good place to start; it should describe what information we expect to be configured/monitored/preserved. Of course, in some environments other things might also need to be configured/monitored/preserved, and we can only really provide guidance on our standards. And we can provide guidance on how our management protocol standards could be used to configure/monitor/preserve. >- The BEHAVE WG and the OPS Area have an equal stake in determining which >tool is recommended to manage each type of data. They should work >together to make a recommendation. In the best of all possible worlds, >that decision would be informed by a well-documented guideline. However, >in the world that we inhabit, that decision may need to be facilitated by >a conversation. I would express this differently: We are talking about tasks to be performed, and the BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended for each task. The type of data, and the protocol to manipulate that data, is determined by the nature of the task. I believe there are already some guidelines published by the OPS area about NM protocol applicability, such as rfc5706 and RFC6632. We have four standard NM protocols because we have identified four major task-oriented aspects of management to be addressed: SNMP is good for monitoring (and emitting noritifations for) faults and performance, particularly for the overall system, and specific protocols (especially transmission protocols). SNMP is session-less, by design, which makes it applicable to broken networks and repetitive polling of small amounts of data. SNMP is supported by a wide range of devices. SNMP can be used to tweak system variables, but many agent implementations do not support SET commands. SNMP is typically constrained by a lack of MIB modules (especially standardized modules) for all features in a box. SNMP was designed to be NMS-application-friendly. SNMP is supported by a wide range of management applications that automate aspects such as congestion awareness, root-cause analysis and policy-based response systems. NMS applications with graphical user interfaces often integrate/correlate SNMP, Syslog, and command line tools such as ping and traceroute, and graphically identify network problems. (In my experience, advanced GUI tools typically support SNMP, while non-SNMP tools designed for other tasks tend to have less advanced GUIs.) 2) Whole-box configuration is addressed mainly by proprietary CLIs and shell scripts. 3) Standardized whole-box config is being addressed by netconf/yang (partial config can be supported as well). Netconf/YANG support is seriously constrained by a lack of standard YANG models. Netconf is often implemented with proprietary data modeling approaches (e.g., CLI commands with XML tags, not YANG). The IETF community is working on converting many MIB modules into YANG format to provide core data models. The IETF community is working on developing YANG models for technologies not well supported by SMIv2 modeling. Netconf was designed with eye toward operators logging in via SSH sessions to configure devices. This approach can be automated by shell scripts. I am not aware of much non-scripted application-support for netconf automation yet. 4) Syslog is the defacto standard for logging. The IETF syslog has a standard message header, and standardized security. Syslog messages deliberately include a non-standardized text portion so vendors can pass useful, human-readable, vendor-specific information in the message. The syslog community (mostly implementers) was adamant they do not want to standardize text portions of syslog messages, because that doesn't meet their needs. Syslog is a one-way protocol, often with no congestion control, with no ack to ensure delivery succeeded. This unacknowledged one-way approach of syslog/UDP may have legal ramifications. Syslog/TLS can help verify delivery and message integrity. "Signed syslog" can help verify the integrity of messages, both in transit and in subsequent storage (designed for legal use cases). 5) I know less about ipfix, but if I understand correctly: ipfix uses a template approach, so operators can choose what information they want delivered. ipfix was designed to generate messages quickly to address short-lived phenomena (e.g., ip sessions). Ipfix was designed to generate messages with potentially significant amounts of data per event. The template approach saves the overhead of sending naming and type information in the message; it sends only the data. Ipfix was designed to offload messages quickly to support devices with constrained resources. And I think ipfix was designed to support usage accounting, with support for reliability and integrity-checking. >- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) >for the recommended protocols >- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for >the non-recommended protocols > >Comments? > > Ron I think that we should recommend ALL of these IETF-standard protocols, using applicability statements (and the existing guidelines) to specify under what circumstances each use is recommended. We should develop one or two standard data models for BEHAVE-standardized NAT management to prove the BEHAVE WG information model is viable (and for interoperability, of course). Which one or two should be decided by asking the operator community which are most important to them in the near term (I.e. within 24 months). We can always develop other standard data models, possibly as non-WG drafts, based on market demand later. IMHO, as ex-AD, the BEHAVE WG should focus on making **the protocols standardized in the WG** manageable (e.g., DNS64, v6v4 stateful and stateless translation, ftp64, bih, turn, stun, etc.). When and if lsn-requirements is approved as an IETF standard, then the WG should develop management support needed for interoperability. I think NATs are still too vendor-specific and deployment-specific to standardize configuration data models; we need more field experience and convergence of the NAT configuration information model. Given my understanding of what operators are saying they need for their deployments, the commonality/stability of information that needs to be modeled, and my understanding of the strengths and weaknesses of the four protocols, my personal recommendation for near-term usage is to develop a MIB module for monitoring/alerting, and syslog/TLS for logging, with signed-syslog support encouraged to support legal requirements. Your mileage may vary. Dbh -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 > > > >_______________________________________________ >OPS-AREA mailing list >OPS-AREA@ietf.org >https://www.ietf.org/mailman/listinfo/ops-area From j.schoenwaelder@jacobs-university.de Wed Aug 8 01:20:02 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F343721F8699 for ; Wed, 8 Aug 2012 01:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h35QHlSs6C9P for ; Wed, 8 Aug 2012 01:20:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8326721F8679 for ; Wed, 8 Aug 2012 01:19:59 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BCAC20BF5; Wed, 8 Aug 2012 10:19:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4N223HUCQe5P; Wed, 8 Aug 2012 10:19:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D508F20979; Wed, 8 Aug 2012 10:19:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D76BC2108D38; Wed, 8 Aug 2012 10:19:56 +0200 (CEST) Date: Wed, 8 Aug 2012 10:19:56 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20120808081956.GB96414@elstar.local> References: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 08:20:02 -0000 On Tue, Aug 07, 2012 at 08:16:58PM -0400, David Harrington wrote: > > 3) Standardized whole-box config is being addressed by netconf/yang > (partial config can be supported as well). > Netconf/YANG support is seriously constrained by a lack of standard YANG > models. This sounds a bit like "do not write standard YANG data models because there are no standard data models". Anyway, NETMOD has core data models in WG last call. We are getting there, slowly by surely. > Netconf is often implemented with proprietary data modeling approaches > (e.g., CLI commands with XML tags, not YANG). I can't let this "CLI commands with XML tags" pass uncommented. While some (IMHO broken) implementations might do this, there are router vendors who actually do ship implementations with structured data models. > The IETF community is working on converting many MIB modules into YANG > format to provide core data models. Again, this is not very accurate. The NETMOD WG is not just converting MIBs. The routing data model goes far beyond anything out there in MIB land related to routing by providing a routing model. The IP configuration model is the first time the IETF every comes up with a standards-track way to configure IP interfaces. > The IETF community is working on developing YANG models for technologies > not well supported by SMIv2 modeling. > Netconf was designed with eye toward operators logging in via SSH sessions > to configure devices. > This approach can be automated by shell scripts. > I am not aware of much non-scripted application-support for netconf > automation yet. This sounds a bit like NETCONF is designed for human operators messing around with devices. At least one big router vendor has reported to base its management system solely on NETCONF, providing adaptors for legacy interfaces where necessary. I think we should be careful not to place NETCONF/YANG into a certain corner at this point in time by drawing a picture that might not be adequate. YANG was published just in Octover 2010 and it is only since then that we are able to work on standard data models. Give the technology some more time before drawing conclusions like the above. /js (NETMOD co-chair) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Aug 8 02:02:06 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E887021F8679 for ; Wed, 8 Aug 2012 02:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.93 X-Spam-Level: X-Spam-Status: No, score=-102.93 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aowmOk-1UVBT for ; Wed, 8 Aug 2012 02:01:59 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B9F5921F8672 for ; Wed, 8 Aug 2012 02:01:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA4pIlDGmAcF/2dsb2JhbABFuWmBB4IgAQEBAQMSHgo/DAQCAQgNAQIBBAEBAQoGDAsBBgFFCQgCBAESCBMHh2sLnWWdQosPCYV3YAOWXIRpig+CYYFU X-IronPort-AV: E=Sophos;i="4.77,732,1336363200"; d="scan'208";a="21471615" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Aug 2012 04:56:02 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 08 Aug 2012 04:57:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Aug 2012 11:01:56 +0200 Message-ID: In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B745C6A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Management Requirements Thread-Index: AQHNdNNCJ+/UV9YI+kO7kJ1VwbfOz5dPSXoA//+YvdCAAIWBgP//lHRwgAChpPA= References: <20120803051042.GA88050@elstar.local><13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net><20120807205452.GA95595@elstar.local><9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><20120807224306.GA95745@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B745C6A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> From: "Romascanu, Dan (Dan)" To: "Dave Thaler" , "Juergen Schoenwaelder" Cc: tsv-ads@tools.ietf.org, behave-chairs@tools.ietf.org, ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 09:02:06 -0000 > -----Original Message----- > From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On > Behalf Of Dave Thaler > Sent: Wednesday, August 08, 2012 2:23 AM > To: Juergen Schoenwaelder > Cc: ops-area@ietf.org; behave-chairs@tools.ietf.org; tsv- > ads@tools.ietf.org > Subject: Re: [OPS-AREA] Management Requirements >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Tuesday, August 07, 2012 3:43 PM > > To: Dave Thaler > > Cc: Ronald Bonica; tsv-ads@tools.ietf.org; > > behave-chairs@tools.ietf.org; ops- area@ietf.org > > Subject: Re: [OPS-AREA] Management Requirements > > > > On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote: > > > > > > The data instances can have a larger volume and may need to travel > over > > > shaky links. Also there's an existing MIB that is outdated and we > want > > > to obsolete. So the WG is currently using SNMP for retrieving > > > operational state and debugging, by doing an update that is intended > > > to obsolete the existing MIB RFC. > > > > Out of curiosity, is there meanwhile a clear description you can point > > to explaining why the old NAT-MIB is broken? >=20 > The current text by the authors of the update is at > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1 >=20 > > > > Perhaps these thoughts help to make a suitable decision. One could > > > > of course also ask what the contributors prefer to implement, e.g. > > > > what they expect to ease integration into management systems > > > > relevant for the protocol domain. > > > > > > Answered above. Looking to OPS for clear guidance on what eventing > > > protocol to use (or what criteria we should use to decide). I > don't want > > > multiple ones. > > > > What are the events considered? How frequent will they occur? How > > stringent are the requirements to deliver them (almost) all or is the > > even source designed to throttle notifications? How much data is > > needed to describe the events? >=20 > One example would be creation/deletion of a mapping table entry. > Depending on the exact techniques used by the instrumented > implementation it may range from extremely frequent and large volume, to > infrequent and > small volume. There is no discussion of throttling, only of techniques > that one could use to reduce the volume (independent of the protocol > used to report events). How much data? Probably tens of bytes per > event. >=20 > > If all that is rather "standard" (in terms of notification volume and > > individual notification size), then SNMP might just do fine. >=20 > Looking not for what "might do fine" per se, as that might be a large > number of protocols, but rather for what single protocol is recommended > or alternatively, a set of guidance on how a WG should choose among > various protocols. >=20 > -Dave >=20 [[DR]] It looks like there are two levels in this discussion. One relates specifically to the domain currently managed by using the existing NAT MIB, with the analysis of the gaps (and brokenness) and solutions for the specific problems. The other is about ' a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols'. If my guess that BEHAVE would rather have the first specific level addressed without waiting for a generic solution to the later level, I suggest that we focus on the NAT management problem space first. We (in the OPS area) may learn some lessons about how to deal with the more general level as well.=20 Dan From ietfdbh@comcast.net Wed Aug 8 08:16:26 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCAF21F867A for ; Wed, 8 Aug 2012 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.096 X-Spam-Level: X-Spam-Status: No, score=-102.096 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YnaTkylTMR9 for ; Wed, 8 Aug 2012 08:16:25 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC6E21F8569 for ; Wed, 8 Aug 2012 08:16:25 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id kBgv1j0030Fqzac59FGUSw; Wed, 08 Aug 2012 15:16:28 +0000 Received: from [10.59.1.23] ([71.233.85.150]) by omta08.westchester.pa.mail.comcast.net with comcast id kFGJ1j00j3Ecudz3UFGKQx; Wed, 08 Aug 2012 15:16:23 +0000 User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Wed, 08 Aug 2012 11:16:19 -0400 From: David Harrington To: Juergen Schoenwaelder Message-ID: Thread-Topic: [OPS-AREA] Management Requirements In-Reply-To: <20120808081956.GB96414@elstar.local> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 15:16:26 -0000 Hi, Inline ... -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 8/8/12 4:19 AM, "Juergen Schoenwaelder" wrote: >On Tue, Aug 07, 2012 at 08:16:58PM -0400, David Harrington wrote: >> >> 3) Standardized whole-box config is being addressed by netconf/yang >> (partial config can be supported as well). >> Netconf/YANG support is seriously constrained by a lack of standard YANG >> models. > >This sounds a bit like "do not write standard YANG data models because >there >are no standard data models". Anyway, NETMOD has core data models in WG >last >call. We are getting there, slowly by surely. I'm sorry you saw this as being negative. The following sentences discuss the active efforts to mitigate the issue. And no where did I say standardized YANG data models shouldn't be written. I strongly support the development of core models consistent with the MIB information models (for consistency in management), PLUS the development of new YANG modeling that MIB modules cannot do well, such as routing technologies. The MIB problem (a whole box cannot be managed using SNMP, largely because there are not MIB modules representing everything in a box) is also a problem for Netconf - the lack of YANG modeling for everything in a box. Part of the MIB problem is that SMIv2 is not good for representing some aspects of a box, such as nested tables; Hopefully YANG will overcome that problem so more things in a box can be modeled reasonably. > >> Netconf is often implemented with proprietary data modeling approaches >> (e.g., CLI commands with XML tags, not YANG). > >I can't let this "CLI commands with XML tags" pass uncommented. While >some (IMHO broken) implementations might do this, there are router >vendors who actually do ship implementations with structured data >models. Some vendors have used a CLI with XML tags proprietary approach; others use structured data, such as proprietary XMLSchema models. My observation is that currently implementations often use proprietary data modeling approaches rather than YANG. I would much rather see standardized YANG models widely deployed. I just don't think that is the current state of deployment. > >> The IETF community is working on converting many MIB modules into YANG >> format to provide core data models. > >Again, this is not very accurate. The NETMOD WG is not just converting >MIBs. Where did I say they were JUST converting MIBs? Read the following sentence in my email. Please look at my whole comment; don't just react sentence by sentence. >The routing data model goes far beyond anything out there in >MIB land related to routing by providing a routing model. The IP >configuration model is the first time the IETF every comes up with a >standards-track way to configure IP interfaces. And what does my next sentence say? > >> The IETF community is working on developing YANG models for technologies >> not well supported by SMIv2 modeling. >> Netconf was designed with eye toward operators logging in via SSH >>sessions >> to configure devices. >> This approach can be automated by shell scripts. >> I am not aware of much non-scripted application-support for netconf >> automation yet. > >This sounds a bit like NETCONF is designed for human operators messing >around with devices. At least one big router vendor has reported to >base its management system solely on NETCONF, providing adaptors for >legacy interfaces where necessary. > >I think we should be careful not to place NETCONF/YANG into a certain >corner at this point in time by drawing a picture that might not be >adequate. YANG was published just in Octover 2010 and it is only since >then that we are able to work on standard data models. Give the >technology some more time before drawing conclusions like the above. That is exactly my point. The YANG standard database needs "some more time" to be expanded and to mature. However, BEHAVE needs to be able to develop usable standardized management NOW, In a few years, after YANG has had additional time for industry adoption and standardized YANG modules are abundant, then using YANG would be a good thing. But NATs interact with multiple parts of systems. There are standardized MIB modules for many of those core system parts available now, so MIB modules to support BEHAVE technologies will likely find MIB modules that support many of the core system features that NATs must interact with. OTOH, many of those same core technologies do not yet have a standardized YANG data module, so BEHAVE would need to either build support for those other things into their YANG data models (where they are not necessarily the experts) or wait for standardized YANG modules to be developed. I don't think standardized configuration is mature enough YET, or widely deployed enough YET, to justify BEHAVE allocating its scarce resources to modeling YANG configurations, and then trying to convince the industry to widely deploy Netconf and those data models. In the future, yes; now, no. I think the Netconf/YANG technology needs "some more time" to mature and for the Internet-industry's demand for cross-vendor standardized configuration to grow. In comparison, SNMP monitoring and Syslog logging are very mature, and already supported by wide deployment both at the device and application level. I think SNMP and Syslog make sense NOW to meet the BEHAVE current requirements for monitoring, eventing, and logging. Standardized configuration for BEHAVE can come later - which fits well with the time needed for core+other YANG models to be developed and deployed. Dbh (ex-NETMOD co-chair, ex Syslog co-chair, ex SNMPv3 co-chair, ex BEHAVE AD ) > >/js (NETMOD co-chair) > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Aug 8 22:47:05 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D52311E80E2 for ; Wed, 8 Aug 2012 22:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.208 X-Spam-Level: X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDcTQLYiyth7 for ; Wed, 8 Aug 2012 22:47:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 353C411E80DC for ; Wed, 8 Aug 2012 22:47:04 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DEB3120BF5; Thu, 9 Aug 2012 07:47:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Ys_QcZUyThw0; Thu, 9 Aug 2012 07:47:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8CEE20BEB; Thu, 9 Aug 2012 07:46:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C88612112B4A; Thu, 9 Aug 2012 07:46:57 +0200 (CEST) Date: Thu, 9 Aug 2012 07:46:57 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20120809054656.GA827@elstar.local> References: <20120808081956.GB96414@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 05:47:05 -0000 On Wed, Aug 08, 2012 at 11:16:19AM -0400, David Harrington wrote: > >> Netconf is often implemented with proprietary data modeling approaches > >> (e.g., CLI commands with XML tags, not YANG). > > > >I can't let this "CLI commands with XML tags" pass uncommented. While > >some (IMHO broken) implementations might do this, there are router > >vendors who actually do ship implementations with structured data > >models. > > Some vendors have used a CLI with XML tags proprietary approach; others > use structured data, such as proprietary XMLSchema models. > My observation is that currently implementations often use proprietary > data modeling approaches rather than YANG. I do not know which sample you take your observations from. Since NETCONF well predates YANG, it did not mandate YANG and hence data models specified in say XSD are not a surprise. What is broken is the notion of lots of proprietary unstructured cli and your text was somehow hinting at this being the state of that art. > >> The IETF community is working on converting many MIB modules into YANG > >> format to provide core data models. > > > >Again, this is not very accurate. The NETMOD WG is not just converting > >MIBs. > > Where did I say they were JUST converting MIBs? Read the following > sentence in my email. > Please look at my whole comment; don't just react sentence by sentence. Your sentence did make it sound like a format conversion exercise, which I have to object to. The NETMOD working group, in particular, is not "converting many MIB modules into YANG format to provide core data models". > That is exactly my point. The YANG standard database needs "some more > time" to be expanded and to mature. So then give it time and please do not draw a picture about NETCONF and YANG which I think is not fair. Thanks. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Thu Aug 9 01:56:46 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1321F873A for ; Thu, 9 Aug 2012 01:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JitzOo3JkKkx for ; Thu, 9 Aug 2012 01:56:45 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id C7E8621F869D for ; Thu, 9 Aug 2012 01:56:45 -0700 (PDT) Received: from mail193-co1-R.bigfish.com (10.243.78.253) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 9 Aug 2012 08:56:45 +0000 Received: from mail193-co1 (localhost [127.0.0.1]) by mail193-co1-R.bigfish.com (Postfix) with ESMTP id 1E182DC048B; Thu, 9 Aug 2012 08:56:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail193-co1 (localhost.localdomain [127.0.0.1]) by mail193-co1 (MessageSwitch) id 1344502603239308_30854; Thu, 9 Aug 2012 08:56:43 +0000 (UTC) Received: from CO1EHSMHS011.bigfish.com (unknown [10.243.78.254]) by mail193-co1.bigfish.com (Postfix) with ESMTP id 367D5A00044; Thu, 9 Aug 2012 08:56:43 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS011.bigfish.com (10.243.66.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 9 Aug 2012 08:56:42 +0000 Received: from AMSPRD0510HT001.eurprd05.prod.outlook.com (157.56.248.53) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.108.4; Thu, 9 Aug 2012 08:56:27 +0000 Message-ID: <017d01cd760c$3cf840c0$4001a8c0@gateway.2wire.net> From: t.petch To: Dave Thaler , Juergen Schoenwaelder References: <20120803051042.GA88050@elstar.local><13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net><20120807205452.GA95595@elstar.local><9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com><20120807224306.GA95745@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B745C6A@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 9 Aug 2012 09:51:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.53] X-OriginatorOrg: btconnect.com Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 08:56:46 -0000 ----- Original Message ----- From: "Dave Thaler" To: "Juergen Schoenwaelder" Sent: Wednesday, August 08, 2012 12:22 AM > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > > university.de] > > Sent: Tuesday, August 07, 2012 3:43 PM > > To: Dave Thaler > > On Tue, Aug 07, 2012 at 09:51:44PM +0000, Dave Thaler wrote: > > > > > > The data instances can have a larger volume and may need to travel over > > > shaky links. Also there's an existing MIB that is outdated and we want > > > to obsolete. So the WG is currently using SNMP for retrieving > > > operational state and debugging, by doing an update that is intended > > > to obsolete the existing MIB RFC. > > > > Out of curiosity, is there meanwhile a clear description you can point to > > explaining why the old NAT-MIB is broken? > > The current text by the authors of the update is at > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-02#section-2.1 Which worries me. Section 2 makes a very brief summary of all the new facilities that have been introduced, eliminates all the much more detailed description of what is there but is now deprecated. I did not at first see the new objects and tables since they have been placed in the I-D after the conformance clauses, not wrong but unusual. Since almost all of RFC4008 has been deprecated and much new introduced, to carry on using natMIB MODULE-IDENTITY ::= { mib-2 123 } seems inappropriate. More fundamentally, the considerable amount of detailed work on the OBJECT-TYPEs and the lack of an explanation in section 2 suggests that this work has embarked on detailed design before defining the requirements, an approach which does not always lead to a successful outcome. Tom Petch > > > > > Perhaps these thoughts help to make a suitable decision. One could > > > > of course also ask what the contributors prefer to implement, e.g. > > > > what they expect to ease integration into management systems > > > > relevant for the protocol domain. > > > > > > Answered above. Looking to OPS for clear guidance on what eventing > > > protocol to use (or what criteria we should use to decide). I don't want > > > multiple ones. > > > > What are the events considered? How frequent will they occur? How > > stringent are the requirements to deliver them (almost) all or is the even > > source designed to throttle notifications? How much data is needed to > > describe the events? > > One example would be creation/deletion of a mapping table entry. > Depending on the exact techniques used by the instrumented implementation > it may range from extremely frequent and large volume, to infrequent and > small volume. There is no discussion of throttling, only of techniques > that one could use to reduce the volume (independent of the protocol > used to report events). How much data? Probably tens of bytes per event. > > > If all that is rather "standard" (in terms of notification > > volume and individual notification size), then SNMP might just do fine. > > Looking not for what "might do fine" per se, as that might be a large number of > protocols, but rather for what single protocol is recommended or alternatively, > a set of guidance on how a WG should choose among various protocols. > > -Dave > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > From bclaise@cisco.com Thu Aug 9 03:20:54 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D214321F85D8 for ; Thu, 9 Aug 2012 03:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2EylSaOKjZQ for ; Thu, 9 Aug 2012 03:20:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 5490F21F83EF for ; Thu, 9 Aug 2012 03:20:52 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79AELIP011623; Thu, 9 Aug 2012 12:14:21 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79AELWk002117; Thu, 9 Aug 2012 12:14:21 +0200 (CEST) Message-ID: <50238D7D.70203@cisco.com> Date: Thu, 09 Aug 2012 12:14:21 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Juergen Schoenwaelder References: <20120803051042.GA88050@elstar.local> In-Reply-To: <20120803051042.GA88050@elstar.local> Content-Type: multipart/alternative; boundary="------------070901030901010208070607" Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] data models and translations / mappings X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 10:20:54 -0000 This is a multi-part message in MIME format. --------------070901030901010208070607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Good summary. This piece of history (about SMIng, amongst others things), could have been perfect for an appendix in RFC 6632. What I mentioned in the OPS-AREA is that we need a consistent information model. From RFC3444 (I guess that you know about that one ;-) IM --> conceptual/abstract model | for designers and operators +----------+---------+ | | | DM DM DM --> concrete/detailed model for implementors Maybe we don't need a protocol independent data modeling language? Maybe we don't need an automatic translation between data models? I understand that it would be ideal to have one of the two, but I agree with your conclusions: Bottom line: People who believe we can move towards generic data models that can be machine translated to produce usable data models for different management protocols may want to study some of the prior work the IETF/IRTF did in this space. All we know for sure is that such translations are not easy, if meaningfully possible at all. In EMAN, we stressed that, what was important, was the information model. Therefore, we used UML to define the information model. And in the same documents, we have the MIB module(s). See http://tools.ietf.org/html/draft-ietf-eman-framework-05 http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06 http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 Disclaimer: I guess the diagrams are not really UML compliant, but this could easily be fixed. So someone could take the UML and produce a YANG module out of it, as opposed to the MIB module Another example is http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, which contains UML diagrams, and the YANG module in the same document. My point is that someone could take the same UML diagrams and deduce another data models (YANG, MIB module, IPFIX) Granted, the UML doesn't provide all the information. Example: possible commands on objects, notifications, etc... Granted, the NMS would require some sort of proxy function between data models (the YANG module leaf X = the MIB OID Y = IPFIX Information Element Z). However, the consistent source (i.e. the UML) should help a lot. Let's take the following UML diagram from http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11 +------------------------------+ | SctpExporter | +------------------------------+ 0..1 +------------------------+ | ipfixVersion = 10 |<>-------| TransportLayerSecurity | | sourceIPAddress[0..*] | +------------------------+ | destinationIPAddress[1..*] | | destinationPort = 4739|4740 | 0..1 +------------------------+ | ifName/ifIndex[0..1] |<>-------| TransportSession | | sendBufferSize {opt.} | +------------------------+ | rateLimit[0..1] | | timedReliability = 0 | +------------------------------+ Figure 17: SctpExporter class If the object "IPFIX Version" would have the same "ipfixVersion" name in multiple data models (assuming that the naming convention in the different data models are respected), that would help already. Feedback? Btw, I like your article at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4511663 Regards, Benoit. > Hi, > > During the OPS-AREA meeting today, the topic came up how we plan to > deal with the fact that we now have NETCONF and SNMP. One point made > was that consistency of the data models is key. I fully agree with > that statement. Some people asked during the meeting and after the > meeting whether automated translations can not help us solve the > problem. Since not everyone might be familiar with the history of > similar ideas in the IETF, I thought I write down a few things that > might help to understand what we have today and how we got where we > are. > > Back in the late 1990s, policy based management was a big hype. (To a > large extend, some of today's brand new ideas resemble ideas that were > floating around back then, but lets not get side tracked.) With the > policy work, we got the protocols COPS [RFC 2748] and in particular > COPS-PR [RFC 3084]. Some believed these new protocols will be the > solution to all management problems, but others, of course, did not > think that way. One of the questions that came up back then was how we > can make things work if we now have both SNMP and COPS-PR. People > agreed that we need at least consistency on the data models. (Did I > hear this today again?) For those who have not been around back then > or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as > its data modeling language, a variant of SMIv2 [RFC 2578] . > > In those days, I thought it should be possible to come up with a new > data modeling language that allows to define data models that can work > with both SNMP and COPS-PR. The idea was to separate the core data > model from the protocol specific bindings. We called this new language > SMIng (and yes, by choosing 'ng', this was doomed to failure - but I > did not realize that until it was too late ;-). SMIng was first > developed in the NMRG of the IRTF and then brought to the IETF. The > resulting SMIng working group was tasked to produce first a > requirements document. The WG delivered the SMIng objectives in > [RFC3216], published in 2001. Subsequently, the working group failed > to achieve agreement on the SMIng language itself and it was finally > shut down without producing any further results. The SMIng proposal > produced by the NMRG was later published in 2004 as [RFC 3780] > together with the SNMP binding [RFC 3781]. A few years later, I wrote > down some thoughts about the lessons learned from the SMIng project > [http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an > early version of the paper in case someone is interested why protocol > independence is hard to achieve. Just ask. > > When NETCONF needed a data modeling language, the design team started > with the idea that the data modeling language should be as clean and > general as possible but we accepted to include support for protocol > specifics where they were needed to make things work well. YANG [RFC > 6020], published in 2010, resembles in part SMIng but goes much > further in expressiveness. Contrary to SMIng, we allowed protocol > specifics again to be part of the language (most obvious perhaps with > error handling statements that directly relate to how NETCONF signals > errors). One thing that has proven valuable is YANG's insensibility. > (Some implementations use language extensions to drive the generation > of various interfaces out of a YANG specification.) > > Since YANG is much less constrained than SMIv2, I started to develop a > translation algorithm that turns SMIv2 data models into YANG data > models. (I started coding this during the first YANG design team > meeting I attended back in 2007.) The resulting specification got > published recently as [RFC 6643]. While the translation is relatively > straightforward, the translation is read-only since the persistence > models of SNMP and NETCONF differ widely. > > With the SMIv2 to YANG mapping in place, you get a read-only YANG data > model for any SMIv2 MIB data model (aka MIB) today by simply running a > translator. There are open source tools to do that. Are people happy > with this? Well, not everybody. While the resulting data model is > usable (in my biased view ;-), the result of the translation is of > course not as good as a handcrafted translation. Some people seem to > also dislike that there is not an authoritative source where > translated modules can be found (which may be a fixable problem). In > the NETMOD working group, we received very recently some requests to > add more handcrafted translations to the YANG modules being developed. > > Bottom line: People who believe we can move towards generic data > models that can be machine translated to produce usable data models > for different management protocols may want to study some of the prior > work the IETF/IRTF did in this space. All we know for sure is that > such translations are not easy, if meaningfully possible at all. > > /js > > PS: And let us not forget that IPFIX lives a life of its own with a > growing number of "information elements" while SYSLOG is rather > loosely structured. It is not just SNMP and NETCONF. > --------------070901030901010208070607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Juergen,

Good summary. This piece of history (about SMIng, amongst others things), could have been perfect for an appendix in RFC 6632.

What I mentioned in the OPS-AREA is that we need a consistent information model.
From RFC3444 (I guess that you know about that one ;-) 
             IM                --> conceptual/abstract model
              |                    for designers and operators
   +----------+---------+
   |          |         |
   DM        DM         DM     --> concrete/detailed model
                                   for implementors
Maybe we don't need a protocol independent data modeling language?
Maybe we don't need an automatic translation between data models?
I understand that it would be ideal to have one of the two, but I agree with your conclusions:
Bottom line: People who believe we can move towards generic data
models that can be machine translated to produce usable data models
for different management protocols may want to study some of the prior
work the IETF/IRTF did in this space. All we know for sure is that
such translations are not easy, if meaningfully possible at all.

In EMAN, we stressed that, what was important, was the information model. Therefore, we used UML to define the information model. And in the same documents, we have the MIB module(s).
See
    http://tools.ietf.org/html/draft-ietf-eman-framework-05
    http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06
    http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03
Disclaimer: I guess the diagrams are not really UML compliant, but this could easily be fixed.
So someone could take the UML and produce a YANG module out of it, as opposed to the MIB module

Another example is http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, which contains UML diagrams, and the YANG module in the same document.

My point is that someone could take the same UML diagrams and deduce another data models (YANG, MIB module, IPFIX)

Granted, the UML doesn't provide all the information. Example: possible commands on objects, notifications, etc...
Granted, the NMS would require some sort of  proxy function between data models (the YANG module leaf X = the MIB OID Y = IPFIX Information Element Z).  However, the consistent source (i.e. the UML) should help a lot. Let's take the following UML diagram from http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11
    +------------------------------+
    | SctpExporter                 |
    +------------------------------+    0..1 +------------------------+
    | ipfixVersion = 10            |<>-------| TransportLayerSecurity |
    | sourceIPAddress[0..*]        |         +------------------------+
    | destinationIPAddress[1..*]   |
    | destinationPort = 4739|4740  |    0..1 +------------------------+
    | ifName/ifIndex[0..1]         |<>-------| TransportSession       |
    | sendBufferSize {opt.}        |         +------------------------+
    | rateLimit[0..1]              |
    | timedReliability = 0         |
    +------------------------------+

                       Figure 17: SctpExporter class
If the object "IPFIX Version" would have the same "ipfixVersion" name in multiple data models (assuming that the naming convention in the different data models are respected), that would help already.

Feedback?

Btw, I like your article at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4511663

Regards, Benoit.
Hi,

During the OPS-AREA meeting today, the topic came up how we plan to
deal with the fact that we now have NETCONF and SNMP. One point made
was that consistency of the data models is key. I fully agree with
that statement. Some people asked during the meeting and after the
meeting whether automated translations can not help us solve the
problem.  Since not everyone might be familiar with the history of
similar ideas in the IETF, I thought I write down a few things that
might help to understand what we have today and how we got where we
are.

Back in the late 1990s, policy based management was a big hype.  (To a
large extend, some of today's brand new ideas resemble ideas that were
floating around back then, but lets not get side tracked.) With the
policy work, we got the protocols COPS [RFC 2748] and in particular
COPS-PR [RFC 3084]. Some believed these new protocols will be the
solution to all management problems, but others, of course, did not
think that way. One of the questions that came up back then was how we
can make things work if we now have both SNMP and COPS-PR.  People
agreed that we need at least consistency on the data models. (Did I
hear this today again?) For those who have not been around back then
or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as
its data modeling language, a variant of SMIv2 [RFC 2578] .

In those days, I thought it should be possible to come up with a new
data modeling language that allows to define data models that can work
with both SNMP and COPS-PR. The idea was to separate the core data
model from the protocol specific bindings. We called this new language
SMIng (and yes, by choosing 'ng', this was doomed to failure - but I
did not realize that until it was too late ;-). SMIng was first
developed in the NMRG of the IRTF and then brought to the IETF. The
resulting SMIng working group was tasked to produce first a
requirements document. The WG delivered the SMIng objectives in
[RFC3216], published in 2001. Subsequently, the working group failed
to achieve agreement on the SMIng language itself and it was finally
shut down without producing any further results. The SMIng proposal
produced by the NMRG was later published in 2004 as [RFC 3780]
together with the SNMP binding [RFC 3781]. A few years later, I wrote
down some thoughts about the lessons learned from the SMIng project
[http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an
early version of the paper in case someone is interested why protocol
independence is hard to achieve. Just ask.

When NETCONF needed a data modeling language, the design team started
with the idea that the data modeling language should be as clean and
general as possible but we accepted to include support for protocol
specifics where they were needed to make things work well. YANG [RFC
6020], published in 2010, resembles in part SMIng but goes much
further in expressiveness.  Contrary to SMIng, we allowed protocol
specifics again to be part of the language (most obvious perhaps with
error handling statements that directly relate to how NETCONF signals
errors). One thing that has proven valuable is YANG's insensibility.
(Some implementations use language extensions to drive the generation
of various interfaces out of a YANG specification.)

Since YANG is much less constrained than SMIv2, I started to develop a
translation algorithm that turns SMIv2 data models into YANG data
models. (I started coding this during the first YANG design team
meeting I attended back in 2007.) The resulting specification got
published recently as [RFC 6643]. While the translation is relatively
straightforward, the translation is read-only since the persistence
models of SNMP and NETCONF differ widely.

With the SMIv2 to YANG mapping in place, you get a read-only YANG data
model for any SMIv2 MIB data model (aka MIB) today by simply running a
translator. There are open source tools to do that. Are people happy
with this?  Well, not everybody. While the resulting data model is
usable (in my biased view ;-), the result of the translation is of
course not as good as a handcrafted translation. Some people seem to
also dislike that there is not an authoritative source where
translated modules can be found (which may be a fixable problem). In
the NETMOD working group, we received very recently some requests to
add more handcrafted translations to the YANG modules being developed.

Bottom line: People who believe we can move towards generic data
models that can be machine translated to produce usable data models
for different management protocols may want to study some of the prior
work the IETF/IRTF did in this space. All we know for sure is that
such translations are not easy, if meaningfully possible at all.

/js

PS: And let us not forget that IPFIX lives a life of its own with a
    growing number of "information elements" while SYSLOG is rather
    loosely structured. It is not just SNMP and NETCONF.

--------------070901030901010208070607-- From bclaise@cisco.com Thu Aug 9 04:32:03 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F61721F868A for ; Thu, 9 Aug 2012 04:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR8k+hkcwoe7 for ; Thu, 9 Aug 2012 04:32:02 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7155A21F8687 for ; Thu, 9 Aug 2012 04:31:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79BUBJU020584; Thu, 9 Aug 2012 13:30:11 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79BU7in028742; Thu, 9 Aug 2012 13:30:07 +0200 (CEST) Message-ID: <50239F3F.6000404@cisco.com> Date: Thu, 09 Aug 2012 13:30:07 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dave Thaler References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <20120807205452.GA95595@elstar.local> <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B74577F@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "ops-area@ietf.org" , "behave-chairs@tools.ietf.org" , "tsv-ads@tools.ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 11:32:03 -0000 Dave, Answering a single point below (still reading the entire email thread) >> -----Original Message----- >> >> For event notifications, you have at least SYSLOG, SNMP notifications, IPFIX, >> NETCONF notifications. I think the last one is likely not a main target. SNMP >> notifications means one SNMP message per event and the same holds true >> for SYSLOG; IPFIX allows to send a collection of events in one IPFIX message >> and hence it might be more scalable, which might be important for some NAT >> deployments. > I've heard it said that IPFIX is for packet sampling not for metadata eventing, > but this isn't an area I know enough about myself to say. IPFIX is an push-based export protocol. This is not only for packet sampling. How data are produced is out of the scope of IPFIX (Full Flow, Sampled Flow, …). It's true that the PSAMP WG defined a Metering Process for packet sampling, and that the chosen export protocol is IPFIX, but that doesn't limit IPFIX to packet sampling only. Actually, IPFIX became a generic push mechanism these days, not only reporting flow information. Regards, Benoit. From tnadeau@lucidvision.com Thu Aug 9 05:44:20 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3221F8661 for ; Thu, 9 Aug 2012 05:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xINdr53s9tTp for ; Thu, 9 Aug 2012 05:44:18 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 0313C21F8659 for ; Thu, 9 Aug 2012 05:44:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id 72541223EBBF; Thu, 9 Aug 2012 08:44:17 -0400 (EDT) X-Virus-Scanned: amavisd-new at www.lucidvision.com Received: from lucidvision.com ([127.0.0.1]) by localhost (static-72-71-250-34.cncdnh.fios.verizon.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLw48CpCPNNf; Thu, 9 Aug 2012 08:44:17 -0400 (EDT) Received: from tnadeau-sslvpn-nc.jnpr.net (westford-nat.juniper.net [66.129.232.2]) by lucidvision.com (Postfix) with ESMTP id 783F9223EBB5; Thu, 9 Aug 2012 08:44:16 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1458F4B1-A5FA-4C17-BCF2-813F49E22F76" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Thomas Nadeau In-Reply-To: <50238D7D.70203@cisco.com> Date: Thu, 9 Aug 2012 08:44:15 -0400 Message-Id: <97E305BC-348C-4E50-A103-1EF5CF9A11F1@lucidvision.com> References: <20120803051042.GA88050@elstar.local> <50238D7D.70203@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1485) Cc: ops-area@ietf.org Subject: Re: [OPS-AREA] data models and translations / mappings X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 12:44:20 -0000 --Apple-Mail=_1458F4B1-A5FA-4C17-BCF2-813F49E22F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Maybe UML diagrams are all we need to guide the detailed = model/implementations as a "framework" document each WG would be = required to produce as a base charter item for any new protocol = definitions? This approach would then give the WG the flexibility = with which to define the actual management interfaces as it sees. Note, = I do understand the comments some WG chairs made at the OPS meeting in = this regard to cross-WG coordination, but that is something again, that = a common UML model would address as well as cross-WG "shepherding" from = the OPS AD or a designee to help keep things consistent. I agree that auto-generated stuff is difficult at best. The = other thing to keep in mind is that doing a lot of work in this regard = is going to only apply to new stuff going forward - its always a huge = challenge to do anything backwards-compatable. =20 --Tom On Aug 9, 2012:6:14 AM, at 6:14 AM, Benoit Claise = wrote: > Hi Juergen, >=20 > Good summary. This piece of history (about SMIng, amongst others = things), could have been perfect for an appendix in RFC 6632. >=20 > What I mentioned in the OPS-AREA is that we need a consistent = information model. > =46rom RFC3444 (I guess that you know about that one ;-)=20 > IM --> conceptual/abstract model > | for designers and operators > +----------+---------+ > | | | > DM DM DM --> concrete/detailed model > for implementors > Maybe we don't need a protocol independent data modeling language? > Maybe we don't need an automatic translation between data models? > I understand that it would be ideal to have one of the two, but I = agree with your conclusions: > Bottom line: People who believe we can move towards generic data > models that can be machine translated to produce usable data models > for different management protocols may want to study some of the prior > work the IETF/IRTF did in this space. All we know for sure is that > such translations are not easy, if meaningfully possible at all. >=20 > In EMAN, we stressed that, what was important, was the information = model. Therefore, we used UML to define the information model. And in = the same documents, we have the MIB module(s).=20 > See=20 > http://tools.ietf.org/html/draft-ietf-eman-framework-05 > http://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06 > = http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03 > Disclaimer: I guess the diagrams are not really UML compliant, but = this could easily be fixed. > So someone could take the UML and produce a YANG module out of it, as = opposed to the MIB module >=20 > Another example is = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, = which contains UML diagrams, and the YANG module in the same document.=20= >=20 > My point is that someone could take the same UML diagrams and deduce = another data models (YANG, MIB module, IPFIX) >=20 > Granted, the UML doesn't provide all the information. Example: = possible commands on objects, notifications, etc... > Granted, the NMS would require some sort of proxy function between = data models (the YANG module leaf X =3D the MIB OID Y =3D IPFIX = Information Element Z). However, the consistent source (i.e. the UML) = should help a lot. Let's take the following UML diagram from = http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11 > +------------------------------+ > | SctpExporter | > +------------------------------+ 0..1 = +------------------------+ > | ipfixVersion =3D 10 |<>-------| = TransportLayerSecurity | > | sourceIPAddress[0..*] | = +------------------------+ > | destinationIPAddress[1..*] | > | destinationPort =3D 4739|4740 | 0..1 = +------------------------+ > | ifName/ifIndex[0..1] |<>-------| TransportSession = | > | sendBufferSize {opt.} | = +------------------------+ > | rateLimit[0..1] | > | timedReliability =3D 0 | > +------------------------------+ >=20 > Figure 17: SctpExporter class > If the object "IPFIX Version" would have the same "ipfixVersion" name = in multiple data models (assuming that the naming convention in the = different data models are respected), that would help already. >=20 > Feedback? >=20 > Btw, I like your article at = http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4511663 >=20 > Regards, Benoit. >> Hi, >>=20 >> During the OPS-AREA meeting today, the topic came up how we plan to >> deal with the fact that we now have NETCONF and SNMP. One point made >> was that consistency of the data models is key. I fully agree with >> that statement. Some people asked during the meeting and after the >> meeting whether automated translations can not help us solve the >> problem. Since not everyone might be familiar with the history of >> similar ideas in the IETF, I thought I write down a few things that >> might help to understand what we have today and how we got where we >> are. >>=20 >> Back in the late 1990s, policy based management was a big hype. (To = a >> large extend, some of today's brand new ideas resemble ideas that = were >> floating around back then, but lets not get side tracked.) With the >> policy work, we got the protocols COPS [RFC 2748] and in particular >> COPS-PR [RFC 3084]. Some believed these new protocols will be the >> solution to all management problems, but others, of course, did not >> think that way. One of the questions that came up back then was how = we >> can make things work if we now have both SNMP and COPS-PR. People >> agreed that we need at least consistency on the data models. (Did I >> hear this today again?) For those who have not been around back then >> or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] = as >> its data modeling language, a variant of SMIv2 [RFC 2578] . >>=20 >> In those days, I thought it should be possible to come up with a new >> data modeling language that allows to define data models that can = work >> with both SNMP and COPS-PR. The idea was to separate the core data >> model from the protocol specific bindings. We called this new = language >> SMIng (and yes, by choosing 'ng', this was doomed to failure - but I >> did not realize that until it was too late ;-). SMIng was first >> developed in the NMRG of the IRTF and then brought to the IETF. The >> resulting SMIng working group was tasked to produce first a >> requirements document. The WG delivered the SMIng objectives in >> [RFC3216], published in 2001. Subsequently, the working group failed >> to achieve agreement on the SMIng language itself and it was finally >> shut down without producing any further results. The SMIng proposal >> produced by the NMRG was later published in 2004 as [RFC 3780] >> together with the SNMP binding [RFC 3781]. A few years later, I wrote >> down some thoughts about the lessons learned from the SMIng project >> [http://dx.doi.org/10.1109/MCOM.2008.4511663]. I am happy to share an >> early version of the paper in case someone is interested why protocol >> independence is hard to achieve. Just ask. >>=20 >> When NETCONF needed a data modeling language, the design team started >> with the idea that the data modeling language should be as clean and >> general as possible but we accepted to include support for protocol >> specifics where they were needed to make things work well. YANG [RFC >> 6020], published in 2010, resembles in part SMIng but goes much >> further in expressiveness. Contrary to SMIng, we allowed protocol >> specifics again to be part of the language (most obvious perhaps with >> error handling statements that directly relate to how NETCONF signals >> errors). One thing that has proven valuable is YANG's insensibility. >> (Some implementations use language extensions to drive the generation >> of various interfaces out of a YANG specification.) >>=20 >> Since YANG is much less constrained than SMIv2, I started to develop = a >> translation algorithm that turns SMIv2 data models into YANG data >> models. (I started coding this during the first YANG design team >> meeting I attended back in 2007.) The resulting specification got >> published recently as [RFC 6643]. While the translation is relatively >> straightforward, the translation is read-only since the persistence >> models of SNMP and NETCONF differ widely. >>=20 >> With the SMIv2 to YANG mapping in place, you get a read-only YANG = data >> model for any SMIv2 MIB data model (aka MIB) today by simply running = a >> translator. There are open source tools to do that. Are people happy >> with this? Well, not everybody. While the resulting data model is >> usable (in my biased view ;-), the result of the translation is of >> course not as good as a handcrafted translation. Some people seem to >> also dislike that there is not an authoritative source where >> translated modules can be found (which may be a fixable problem). In >> the NETMOD working group, we received very recently some requests to >> add more handcrafted translations to the YANG modules being = developed. >>=20 >> Bottom line: People who believe we can move towards generic data >> models that can be machine translated to produce usable data models >> for different management protocols may want to study some of the = prior >> work the IETF/IRTF did in this space. All we know for sure is that >> such translations are not easy, if meaningfully possible at all. >>=20 >> /js >>=20 >> PS: And let us not forget that IPFIX lives a life of its own with a >> growing number of "information elements" while SYSLOG is rather >> loosely structured. It is not just SNMP and NETCONF. >>=20 >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area --Apple-Mail=_1458F4B1-A5FA-4C17-BCF2-813F49E22F76 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 = Maybe UML diagrams are all we need to guide the detailed = model/implementations as a "framework" document each WG would be = required to produce as a base charter item for any new protocol = definitions?    This approach would then give the WG the = flexibility with which to define the actual management interfaces as it = sees. Note, I do understand the comments some WG chairs made at the OPS = meeting in this regard to cross-WG coordination, but that is something = again, that a common UML model would address as well as cross-WG = "shepherding" from the OPS AD or a designee to help keep things = consistent.

I agree that auto-generated stuff = is difficult at best. The other thing to keep in mind is that doing a = lot of work in this regard is going to only apply to new stuff going = forward - its always a huge challenge to do anything = backwards-compatable.   

= --Tom



On = Aug 9, 2012:6:14 AM, at 6:14 AM, Benoit Claise <bclaise@cisco.com> = wrote:

=20 =20
Hi Juergen,

Good summary. This piece of history (about SMIng, amongst others things), could have been perfect for an appendix in RFC 6632.

What I mentioned in the OPS-AREA is that we need a consistent information model.
=46rom RFC3444 (I guess that you know about that one ;-) 
             IM                --> conceptual/abstract model
              |                    for designers and operators
   +----------+---------+
   |          |         |
   DM        DM         DM     --> concrete/detailed model
                                   for implementors
Maybe we don't need a protocol independent data modeling = language?
Maybe we don't need an automatic translation between data = models?
I understand that it would be ideal to have one of the two, but I agree with your conclusions:
Bottom line: People who believe we can move towards =
generic data
models that can be machine translated to produce usable data models
for different management protocols may want to study some of the prior
work the IETF/IRTF did in this space. All we know for sure is that
such translations are not easy, if meaningfully possible at all.

In EMAN, we stressed that, what was important, was the information model. Therefore, we used UML to define the information model. And in the same documents, we have the MIB module(s).
See
    http://to= ols.ietf.org/html/draft-ietf-eman-framework-05
    ht= tp://tools.ietf.org/html/draft-ietf-eman-energy-aware-mib-06
    http://tools.ietf.org/html/draft-ietf-eman-energy-monitoring-mib-03=
Disclaimer: I guess the diagrams are not really UML compliant, but this could easily be fixed.
So someone could take the UML and produce a YANG module out of it, as opposed to the MIB module

Another example is http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11, which contains UML diagrams, and the YANG module in the same document.

My point is that someone could take the same UML diagrams and deduce another data models (YANG, MIB module, IPFIX)

Granted, the UML doesn't provide all the information. Example: possible commands on objects, notifications, etc...
Granted, the NMS would require some sort of  proxy function = between data models (the YANG module leaf X =3D the MIB OID Y =3D IPFIX Information Element Z).  However, the consistent source (i.e. = the UML) should help a lot. Let's take the following UML diagram from http://tools.ietf.org/html/draft-ietf-ipfix-configuration-model-11 
    +------------------------------+
    | SctpExporter                 |
    +------------------------------+    0..1 +------------------------+
    | ipfixVersion =3D 10            |<>-------| =
TransportLayerSecurity |
    | sourceIPAddress[0..*]        |         +------------------------+
    | destinationIPAddress[1..*]   |
    | destinationPort =3D 4739|4740  |    0..1 =
+------------------------+
    | ifName/ifIndex[0..1]         |<>-------| TransportSession    =
   |
    | sendBufferSize {opt.}        |         +------------------------+
    | rateLimit[0..1]              |
    | timedReliability =3D 0         |
    +------------------------------+

                       Figure 17: SctpExporter class
If the object "IPFIX Version" would have the same "ipfixVersion" name in multiple data models (assuming that the naming convention in the different data models are respected), that would help = already.

Feedback?

Btw, I like your article at http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D451= 1663

Regards, Benoit.
Hi,

During the OPS-AREA meeting today, the topic came up how we plan to
deal with the fact that we now have NETCONF and SNMP. One point made
was that consistency of the data models is key. I fully agree with
that statement. Some people asked during the meeting and after the
meeting whether automated translations can not help us solve the
problem.  Since not everyone might be familiar with the history of
similar ideas in the IETF, I thought I write down a few things that
might help to understand what we have today and how we got where we
are.

Back in the late 1990s, policy based management was a big hype.  (To a
large extend, some of today's brand new ideas resemble ideas that were
floating around back then, but lets not get side tracked.) With the
policy work, we got the protocols COPS [RFC 2748] and in particular
COPS-PR [RFC 3084]. Some believed these new protocols will be the
solution to all management problems, but others, of course, did not
think that way. One of the questions that came up back then was how we
can make things work if we now have both SNMP and COPS-PR.  People
agreed that we need at least consistency on the data models. (Did I
hear this today again?) For those who have not been around back then
or happily forgotten the details, COPS-PR was using SPPI [RFC 3159] as
its data modeling language, a variant of SMIv2 [RFC 2578] .

In those days, I thought it should be possible to come up with a new
data modeling language that allows to define data models that can work
with both SNMP and COPS-PR. The idea was to separate the core data
model from the protocol specific bindings. We called this new language
SMIng (and yes, by choosing 'ng', this was doomed to failure - but I
did not realize that until it was too late ;-). SMIng was first
developed in the NMRG of the IRTF and then brought to the IETF. The
resulting SMIng working group was tasked to produce first a
requirements document. The WG delivered the SMIng objectives in
[RFC3216], published in 2001. Subsequently, the working group failed
to achieve agreement on the SMIng language itself and it was finally
shut down without producing any further results. The SMIng proposal
produced by the NMRG was later published in 2004 as [RFC 3780]
together with the SNMP binding [RFC 3781]. A few years later, I wrote
down some thoughts about the lessons learned from the SMIng project
[http://dx.doi.org/10.=
1109/MCOM.2008.4511663]. I am happy to share an
early version of the paper in case someone is interested why protocol
independence is hard to achieve. Just ask.

When NETCONF needed a data modeling language, the design team started
with the idea that the data modeling language should be as clean and
general as possible but we accepted to include support for protocol
specifics where they were needed to make things work well. YANG [RFC
6020], published in 2010, resembles in part SMIng but goes much
further in expressiveness.  Contrary to SMIng, we allowed protocol
specifics again to be part of the language (most obvious perhaps with
error handling statements that directly relate to how NETCONF signals
errors). One thing that has proven valuable is YANG's insensibility.
(Some implementations use language extensions to drive the generation
of various interfaces out of a YANG specification.)

Since YANG is much less constrained than SMIv2, I started to develop a
translation algorithm that turns SMIv2 data models into YANG data
models. (I started coding this during the first YANG design team
meeting I attended back in 2007.) The resulting specification got
published recently as [RFC 6643]. While the translation is relatively
straightforward, the translation is read-only since the persistence
models of SNMP and NETCONF differ widely.

With the SMIv2 to YANG mapping in place, you get a read-only YANG data
model for any SMIv2 MIB data model (aka MIB) today by simply running a
translator. There are open source tools to do that. Are people happy
with this?  Well, not everybody. While the resulting data model is
usable (in my biased view ;-), the result of the translation is of
course not as good as a handcrafted translation. Some people seem to
also dislike that there is not an authoritative source where
translated modules can be found (which may be a fixable problem). In
the NETMOD working group, we received very recently some requests to
add more handcrafted translations to the YANG modules being developed.

Bottom line: People who believe we can move towards generic data
models that can be machine translated to produce usable data models
for different management protocols may want to study some of the prior
work the IETF/IRTF did in this space. All we know for sure is that
such translations are not easy, if meaningfully possible at all.

/js

PS: And let us not forget that IPFIX lives a life of its own with a
    growing number of "information elements" while SYSLOG is rather
    loosely structured. It is not just SNMP and NETCONF.

_______________________________________________
OPS-AREA mailing = list
OPS-AREA@ietf.org
https://www.iet= f.org/mailman/listinfo/ops-area

= --Apple-Mail=_1458F4B1-A5FA-4C17-BCF2-813F49E22F76-- From bclaise@cisco.com Thu Aug 9 07:39:30 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF9121F86C9 for ; Thu, 9 Aug 2012 07:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZP6XWxOs1NU for ; Thu, 9 Aug 2012 07:39:29 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC7021F85CD for ; Thu, 9 Aug 2012 07:39:28 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79Dt2DH008176; Thu, 9 Aug 2012 15:55:02 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q79Dsw9r025227; Thu, 9 Aug 2012 15:54:58 +0200 (CEST) Message-ID: <5023C132.7040504@cisco.com> Date: Thu, 09 Aug 2012 15:54:58 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ronald Bonica References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> Content-Type: multipart/alternative; boundary="------------020801080407060602020504" Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 14:39:30 -0000 This is a multi-part message in MIME format. --------------020801080407060602020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ron, I read the entire email thread. So let me reply to this email with information from different participants I agree with Dan that there are two problems. 1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols' 2. what to do specifically in the BEHAVE case Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting We should set the guidance for the entire community. The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go What we need is a flowchart type of things, to make it very easy for non-OPS group to follow As an _example _: - Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread) - Is there an existing data models you want to extend. If yes, extend it - Configuration? Use NETCONF/YANG no configuration now: do you plan on having configuration in the future? if "yes", investigate NETCONF/YANG if "maybe", use an information model language (see the previous thread) - Operational data? If there is a MIB, feel free to extend it? If there is no MIB module so far, insert the operational data in the YANG module - you want to push some data at a high rate ? Investigate IPFIX - you want some events if you have a MIB module, evaluate the SNMP notification if you have a YANG modue, evaluate the YANG notification if you want plain english text events, evaluate syslog if you want some structured events, evaluate syslog SDE - etc... Note: obviously, when comparing technologies, the pros/cons must be explained. It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures. This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion. Regards, Benoit. > Folks, > > The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible." > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows? > > My best guess follows...... > > - The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that. > - The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation. > - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols > - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols > > Comments? > > Ron > > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --------------020801080407060602020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ron,

I read the entire email thread. So let me reply to this email with information from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS group to follow
As an example :
- Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread)
- Is there an existing data models you want to extend. If yes, extend it
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread)
- Operational data?
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

Note: obviously, when comparing technologies, the pros/cons must be explained.

It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion.

Regards, Benoit.

Folks,

The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be
consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible."

Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows?

My best guess follows......

- The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that.
- The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation.
- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols
- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols

Comments?

                                              Ron



_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area

--------------020801080407060602020504-- From randy_presuhn@mindspring.com Thu Aug 9 12:30:45 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF1821F861D for ; Thu, 9 Aug 2012 12:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j90RTsF0QQ87 for ; Thu, 9 Aug 2012 12:30:44 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id A69AB21F8452 for ; Thu, 9 Aug 2012 12:30:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=jDCGmptRf6Bf5MZuQjb8wLEpFDEWdpKA6DZtH+iZogtOQRhfdk0De366jPAg0HA/; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.23.160.249] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SzYRP-0008Id-UO for ops-area@ietf.org; Thu, 09 Aug 2012 15:30:44 -0400 Message-ID: <00e201cd7666$426b9160$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20120803051042.GA88050@elstar.local> <50238D7D.70203@cisco.com> <97E305BC-348C-4E50-A103-1EF5CF9A11F1@lucidvision.com> Date: Thu, 9 Aug 2012 12:36:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f1a00cfc28a6bc9cd3647b89652df714dc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.249 Subject: Re: [OPS-AREA] data models and translations / mappings X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:30:45 -0000 Hi - > From: "Thomas Nadeau" > To: "Benoit Claise" > Cc: > Sent: Thursday, August 09, 2012 5:44 AM > Subject: Re: [OPS-AREA] data models and translations / mappings > > Maybe UML diagrams are all we need to guide the detailed model/implementations > as a "framework" document each WG would be required to produce as a > base charter item for any new protocol definitions? This approach would then > give the WG the flexibility with which to define the actual management interfaces > as it sees. Note, I do understand the comments some WG chairs made at the > OPS meeting in this regard to cross-WG coordination, but that is something > again, that a common UML model would address as well as cross-WG "shepherding" > from the OPS AD or a designee to help keep things consistent. > > I agree that auto-generated stuff is difficult at best. The other thing to keep in mind > is that doing a lot of work in this regard is going to only apply to new stuff going forward - > its always a huge challenge to do anything backwards-compatable. UML diagrams can be a great help in capturing requirements, and I'd like to see them used more for the really high level stuff. But sometimes the tools provided by a particular protocol / data modeling combination result in decisions beyond or at odds with what the UML might say. For example, the indexes in an SNMP table might be ordered so that a subset of the entries in a table will be clustered so that for certain use cases, management applications can avoid walking through the entire table. Or there may even be multiple tables to provide access to the same information, but with differing index structures to support different use cases. With other protocols, other data model tricks might be used to accomplish the same goal with more sophisticated query mechanisms. With "framework" models, UML or otherwise, we need to be wary of accidental over-specification. Randy From rbonica@juniper.net Thu Aug 9 17:57:03 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B18A11E809A for ; Thu, 9 Aug 2012 17:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M++JFmTu7i4S for ; Thu, 9 Aug 2012 17:57:02 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id F1C7011E808A for ; Thu, 9 Aug 2012 17:56:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUCRcWBVGsG20oxPFqSunyV7fRq3e4ZOt@postini.com; Thu, 09 Aug 2012 17:57:01 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 9 Aug 2012 17:53:42 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 9 Aug 2012 17:53:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 9 Aug 2012 20:53:41 -0400 From: Ronald Bonica To: Benoit Claise Date: Thu, 9 Aug 2012 20:53:40 -0400 Thread-Topic: [OPS-AREA] Management Requirements Thread-Index: Ac12NpWyR93WgRKNRsyKUqSDCNsUSAAWNx3g Message-ID: <13205C286662DE4387D9AF3AC30EF456D77198937A@EMBX01-WF.jnpr.net> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <5023C132.7040504@cisco.com> In-Reply-To: <5023C132.7040504@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_13205C286662DE4387D9AF3AC30EF456D77198937AEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 00:57:03 -0000 --_000_13205C286662DE4387D9AF3AC30EF456D77198937AEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, IMHO, our first priority should be to provide concrete guidance to BEHAVE. = The BEHAVE WG will become grumpy if we ask them to wait while OPS debates a= bstractions. Our second priority should be to issue general guidance to WGs. Guidance sh= ould answer the following questions: - Does the WG need model managed data? - Can managed data be divided into categories? If so, how? (Config= uration versus operational state? candidate versus current versus previous= state? Data that is sampled versus data that is retained completely? Data = that must be retained versus data that can be lost?) - What protocol does the IETF recommend for each category? - Does the IETF recommendation give implementers latitude to use a= protocol other than that which is recommended? How much latitude? - How should data be modeled? Using an abstract notation or a prot= ocol specific notation? Comments? Ron From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, August 09, 2012 9:55 AM To: Ronald Bonica Cc: ops-area@ietf.org; tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org Subject: Re: [OPS-AREA] Management Requirements Ron, I read the entire email thread. So let me reply to this email with informat= ion from different participants I agree with Dan that there are two problems. 1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose am= ong various protocols' 2. what to do specifically in the BEHAVE case Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained d= uring the OPS-AREA meeting We should set the guidance for the entire community. The fact that there are not many YANG modules today shouldn't play against = NETCONF/YANG. The guidance could still be: if you want to do configuration,= YANG/NETCONF is the way to go What we need is a flowchart type of things, to make it very easy for non-OP= S group to follow As an example : - Document the operational requirements, and what information needs to be c= onfigured/monitored/preserved. Ideally, use an information model language (= see the previous thread) - Is there an existing data models you want to extend. If yes, extend it - Configuration? Use NETCONF/YANG no configuration now: do you plan on having configuration in the fut= ure? if "yes", investigate NETCONF/YANG if "maybe", use an information model language (see the previous thre= ad) - Operational data? If there is a MIB, feel free to extend it? If there is no MIB module so far, insert the operational data in the YA= NG module - you want to push some data at a high rate ? Investigate IPFIX - you want some events if you have a MIB module, evaluate the SNMP notification if you have a YANG modue, evaluate the YANG notification if you want plain english text events, evaluate syslog if you want some structured events, evaluate syslog SDE - etc... Note: obviously, when comparing technologies, the pros/cons must be explain= ed. It's true that RFC 5706 and RFC 6632 will help, but we should really set so= me guidance between the different OPS architectures. This exercise will certainly require some discussions with the couple of fi= rst requests, to make sure we document everything. So that's maybe what we = should do in the BEHAVE case: have a live discussion. Regards, Benoit. Folks, The BEHAVE WG brings us a concrete example of a problem that we discussed i= n Vancouver. According to their charter, the BEHAVE WG "creates documents t= o enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fas= hion as possible." Also, according to their charter, the BEHAVE WG "will up= date the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and = specify IPFIX information elements to meet logging requirements, reusing ex= isting elements, if possible." Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETC= ONF is the right tool for configuration? Maybe SNMP is right for fault moni= toring? Maybe syslog is right for maintaining a record of address mappings?= Who knows? My best guess follows...... - The BEHAVE WG knows what information needs to be configured/monitored/pre= served. They MUST specify that. - The BEHAVE WG and the OPS Area have an equal stake in determining which t= ool is recommended to manage each type of data. They should work together t= o make a recommendation. In the best of all possible worlds, that decision = would be informed by a well-documented guideline. However, in the world tha= t we inhabit, that decision may need to be facilitated by a conversation. - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for = the recommended protocols - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for t= he non-recommended protocols Comments? Ron _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area --_000_13205C286662DE4387D9AF3AC30EF456D77198937AEMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit,

 =

IMHO, our first priority shoul= d be to provide concrete guidance to BEHAVE. The BEHAVE WG will become grum= py if we ask them to wait while OPS debates abstractions.=

 

Our second priority should be to issue general guidance to WGs= . Guidance should answer the following questions:

 

-          Does the WG need model managed data?

-    = ;      Can = managed data be divided into categories? If so, how? (Configuration versus = operational state?  candidate versus current versus previous state? Da= ta that is sampled versus data that is retained completely? Data that must = be retained versus data that can be lost?)

-        &= nbsp; What protocol does the IETF rec= ommend for each category?

= -          Does the IETF recommendation give implementers = latitude to use a protocol other than that which is recommended? How much l= atitude?

- &n= bsp;        How should data be modeled? Using an abstract notation or a proto= col specific notation?

 

Comments?

 

         &= nbsp;          Ron<= /span>

 

 

From: Benoit Claise [mailto:= bclaise@cisco.com]
Sent: Thursday, August 09, 2012 9:55 AM
To: Ronald Bonica
Cc: ops-area@ietf.org; tsv-ads@tools.ietf.= org; behave-chairs@tools.ietf.org
Subject: Re: [OPS-AREA] Managem= ent Requirements

 

Ron,

I read the entire em= ail thread. So let me reply to this email with information from different p= articipants

I agree with Dan that there are two problems.
1. a se= t of guidance on how a WG (any WG, not only BEHAVE) should choose among var= ious protocols'
2. what to do specifically in the BEHAVE case

Let= me focus on 1., it's time to update RFC1052, as Dan and Tom explained duri= ng the OPS-AREA meeting
We should set the guidance for the entire commun= ity.
The fact that there are not many YANG modules today shouldn't play = against NETCONF/YANG. The guidance could still be: if you want to do config= uration, YANG/NETCONF is the way to go
What we need is a flowchart type = of things, to make it very easy for non-OPS group to follow
As an exa= mple :

- Document the operational re= quirements, and what information needs to be configured/monitored/preserved= . Ideally, use an information model language (see the previous thread)
-= Is there an existing data models you want to extend. If yes, extend it - Configuration? Use NETCONF/YANG
       no co= nfiguration now: do you plan on having configuration in the future?
&nbs= p;      if "yes", investigate NETCONF/YANG       if "maybe", use an information m= odel language (see the previous thread)
- Operational data?
 &= nbsp;  If there is a MIB, feel free to extend it?
   = ; If there is no MIB module so far, insert the operational data in the YANG= module
- you want to push some data at a high rate ? Investigate IPFIX<= br>- you want some events
        if you h= ave a MIB module, evaluate the SNMP notification
    &nbs= p;   if you have a YANG modue, evaluate the YANG notification
=         if you want plain english text events= , evaluate syslog
        if you want some= structured events, evaluate syslog SDE
- etc...

Note: obviously,= when comparing technologies, the pros/cons must be explained.


It's true that RF= C 5706 and RFC 6632 will help, but we should really set some guidance betwe= en the different OPS architectures.

This exercise will certainly req= uire some discussions with the couple of first requests, to make sure we do= cument everything. So that's maybe what we should do in the BEHAVE case: ha= ve a live discussion.

Regards, Benoit.

Folks,
 
The BEHAVE WG brings us a concrete exam=
ple of a problem that we discussed in Vancouver. According to their charter=
, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 N=
ATs to function in as deterministic a fashion as possible." Also, acco=
rding to their charter, the BEHAVE WG "will update the NAT MIB (RFC 40=
08) to be
consistent with the management aspects of it=
s IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet l=
ogging requirements, reusing existing elements, if possible."
 
Now BEHAVE is asking whether SNMP =
and IPFIX are the right tools. Maybe NETCONF is the right tool for configur=
ation? Maybe SNMP is right for fault monitoring? Maybe syslog is right for =
maintaining a record of address mappings? Who knows?
<=
o:p> 
My best guess follows......
 
- The BEHAVE WG knows what information needs t=
o be configured/monitored/preserved. They MUST specify that.
- The BEHAVE WG and the OPS Area have an equal stake in determining =
which tool is recommended to manage each type of data. They should work tog=
ether to make a recommendation. In the best of all possible worlds, that de=
cision would be informed by a well-documented guideline. However, in the wo=
rld that we inhabit, that decision may need to be facilitated by a conversa=
tion.
- The BEHAVE WG MUST produce protocol-specific d=
ata models (SMI, YANG) for the recommended protocols
-=
 The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for th=
e non-recommended protocols
 
Comments?
 
   &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;     Ron
 <=
/pre>
 
 
_________=
______________________________________
OPS-AREA mailin=
g list
OPS-AREA@i=
etf.org
https://www.ietf.org/mailman/listinfo/ops-area
 
 
 
= --_000_13205C286662DE4387D9AF3AC30EF456D77198937AEMBX01WFjnprn_-- From adrian@olddog.co.uk Thu Aug 9 19:19:20 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1321F8620 for ; Thu, 9 Aug 2012 19:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTfWzksR19gQ for ; Thu, 9 Aug 2012 19:19:17 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1B621F861E for ; Thu, 9 Aug 2012 19:19:16 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7A2JDNK002545; Fri, 10 Aug 2012 03:19:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q7A2JBlX002530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Aug 2012 03:19:11 +0100 From: "Adrian Farrel" To: "'Benoit Claise'" , "'Ronald Bonica'" References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <5023C132.7040504@cisco.com> In-Reply-To: <5023C132.7040504@cisco.com> Date: Fri, 10 Aug 2012 03:19:09 +0100 Message-ID: <056301cd769e$870933d0$951b9b70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0564_01CD76A6.E8D3B650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJN44kL3HrK5gLdaQRnvHc74f7szAL1DplpAl33SMeWJtyv0A== Content-Language: en-gb Cc: tsv-ads@tools.ietf.org, behave-chairs@tools.ietf.org, ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 02:19:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0564_01CD76A6.E8D3B650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Benoit, This is a reasonable start, but does omit the whole "information model" thing. I confess to finding UML diagrams not very useful. I prefer an information model written in some form of semi-formal language. I am wondering whether YANG isn't exactly that language. (Yes, that gives the YANG module an unfair advantage). BTW, I really wish we didn't always write "NETCONF/YANG". They are separate entities and one could use one without the other. Cheers, Adrian From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Claise Sent: 09 August 2012 14:55 To: Ronald Bonica Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; ops-area@ietf.org Subject: Re: [OPS-AREA] Management Requirements Ron, I read the entire email thread. So let me reply to this email with information from different participants I agree with Dan that there are two problems. 1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols' 2. what to do specifically in the BEHAVE case Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting We should set the guidance for the entire community. The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go What we need is a flowchart type of things, to make it very easy for non-OPS group to follow As an example : - Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread) - Is there an existing data models you want to extend. If yes, extend it - Configuration? Use NETCONF/YANG no configuration now: do you plan on having configuration in the future? if "yes", investigate NETCONF/YANG if "maybe", use an information model language (see the previous thread) - Operational data? If there is a MIB, feel free to extend it? If there is no MIB module so far, insert the operational data in the YANG module - you want to push some data at a high rate ? Investigate IPFIX - you want some events if you have a MIB module, evaluate the SNMP notification if you have a YANG modue, evaluate the YANG notification if you want plain english text events, evaluate syslog if you want some structured events, evaluate syslog SDE - etc... Note: obviously, when comparing technologies, the pros/cons must be explained. It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures. This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion. Regards, Benoit. Folks, The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible." Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows? My best guess follows...... - The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that. - The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation. - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols Comments? Ron _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www.ietf.org/mailman/listinfo/ops-area ------=_NextPart_000_0564_01CD76A6.E8D3B650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Benoit, =

 

This is a reasonable start, = but does omit the whole "information model" = thing.

I confess to finding UML = diagrams not very useful. I prefer an information model written in some = form of semi-formal language. I am wondering whether YANG isn't exactly = that language. (Yes, that gives the YANG module an unfair = advantage).

 

BTW, I really wish we didn't = always write "NETCONF/YANG". They are separate entities and = one could use one without the other.

 

Cheers,

Adrian

 

From: = ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On = Behalf Of Benoit Claise
Sent: 09 August 2012 = 14:55
To: Ronald Bonica
Cc: tsv-ads@tools.ietf.org; = behave-chairs@tools.ietf.org; ops-area@ietf.org
Subject: Re: = [OPS-AREA] Management Requirements

 

Ron,

I read = the entire email thread. So let me reply to this email with information = from different participants

I agree with Dan that there are two = problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) = should choose among various protocols'
2. what to do specifically in = the BEHAVE case

Let me focus on 1., it's time to update RFC1052, = as Dan and Tom explained during the OPS-AREA meeting
We should set = the guidance for the entire community.
The fact that there are not = many YANG modules today shouldn't play against NETCONF/YANG. The = guidance could still be: if you want to do configuration, YANG/NETCONF = is the way to go
What we need is a flowchart type of things, to make = it very easy for non-OPS group to follow
As an example = :

- Document the = operational requirements, and what information needs to be = configured/monitored/preserved. Ideally, use an information model = language (see the previous thread)
- Is there an existing data models = you want to extend. If yes, extend it
- Configuration? Use = NETCONF/YANG
       no configuration now: do = you plan on having configuration in the future?
    =    if "yes", investigate = NETCONF/YANG
       if "maybe", = use an information model language (see the previous thread)
- = Operational data?
    If there is a MIB, feel free to = extend it?
    If there is no MIB module so far, = insert the operational data in the YANG module
- you want to push = some data at a high rate ? Investigate IPFIX
- you want some = events
        if you have a MIB = module, evaluate the SNMP notification
    =     if you have a YANG modue, evaluate the YANG = notification
        if you want plain = english text events, evaluate syslog
    =     if you want some structured events, evaluate syslog = SDE
- etc...

Note: obviously, when comparing technologies, the = pros/cons must be explained.


It's true that = RFC 5706 and RFC 6632 will help, but we should really set some guidance = between the different OPS architectures.

This exercise will = certainly require some discussions with the couple of first requests, to = make sure we document everything. So that's maybe what we should do in = the BEHAVE case: have a live discussion.

Regards, = Benoit.

Folks,
 
The BEHAVE WG brings us a concrete =
example of a problem that we discussed in Vancouver. According to their =
charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and =
IPv6/IPv4 NATs to function in as deterministic a fashion as =
possible." Also, according to their charter, the BEHAVE WG =
"will update the NAT MIB (RFC 4008) to =
be
consistent with the management aspects of its =
IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet =
logging requirements, reusing existing elements, if =
possible."
 
Now =
BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe =
NETCONF is the right tool for configuration? Maybe SNMP is right for =
fault monitoring? Maybe syslog is right for maintaining a record of =
address mappings? Who =
knows?
 
My best guess =
follows......
 
- The =
BEHAVE WG knows what information needs to be =
configured/monitored/preserved. They MUST specify =
that.
- The BEHAVE WG and the OPS Area have an =
equal stake in determining which tool is recommended to manage each type =
of data. They should work together to make a recommendation. In the best =
of all possible worlds, that decision would be informed by a =
well-documented guideline. However, in the world that we inhabit, that =
decision may need to be facilitated by a =
conversation.
- The BEHAVE WG MUST produce =
protocol-specific data models (SMI, YANG) for the recommended =
protocols
- The BEHAVE WG MAY produce =
protocol-specific data models (SMI, YANG) for the non-recommended =
protocols
 
Comments?=

 
       &nbs=
p;            =
;            =
            &=
nbsp; =
Ron
 
 
 
______________________________=
_________________
OPS-AREA mailing =
list
OPS-AREA@ietf.org
<=
pre>https://www.ietf.=
org/mailman/listinfo/ops-area
 <=
/pre>
 

 

------=_NextPart_000_0564_01CD76A6.E8D3B650-- From bclaise@cisco.com Fri Aug 10 06:04:36 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5421F85C4 for ; Fri, 10 Aug 2012 06:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.49 X-Spam-Level: X-Spam-Status: No, score=-10.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMOMiKuve6bi for ; Fri, 10 Aug 2012 06:04:35 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1782D21F857D for ; Fri, 10 Aug 2012 06:04:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7AD4XMJ001639; Fri, 10 Aug 2012 15:04:34 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7AD4XWJ005871; Fri, 10 Aug 2012 15:04:33 +0200 (CEST) Message-ID: <502506E1.8090103@cisco.com> Date: Fri, 10 Aug 2012 15:04:33 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ronald Bonica References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <5023C132.7040504@cisco.com> <13205C286662DE4387D9AF3AC30EF456D77198937A@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77198937A@EMBX01-WF.jnpr.net> Content-Type: multipart/alternative; boundary="------------070409090708020102040505" Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:04:36 -0000 This is a multi-part message in MIME format. --------------070409090708020102040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ron, > > Benoit, > > IMHO, our first priority should be to provide concrete guidance to > BEHAVE. The BEHAVE WG will become grumpy if we ask them to wait while > OPS debates abstractions. > Agreed. Since we don't have the clear guidelines written down right now, I believe that conf. call is the way to go in this case. > > Our second priority should be to issue general guidance to WGs. > Guidance should answer the following questions: > > -Does the WG need model managed data? > > -Can managed data be divided into categories? If so, how? > (Configuration versus operational state? candidate versus current > versus previous state? Data that is sampled versus data that is > retained completely? Data that must be retained versus data that can > be lost?) > > -What protocol does the IETF recommend for each category? > > -Does the IETF recommendation give implementers latitude to use a > protocol other than that which is recommended? How much latitude? > > -How should data be modeled? Using an abstract notation or a protocol > specific notation? > That's a good series of questions to start with. Regards, Benoit > > Comments? > > Ron > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Thursday, August 09, 2012 9:55 AM > *To:* Ronald Bonica > *Cc:* ops-area@ietf.org; tsv-ads@tools.ietf.org; > behave-chairs@tools.ietf.org > *Subject:* Re: [OPS-AREA] Management Requirements > > Ron, > > I read the entire email thread. So let me reply to this email with > information from different participants > > I agree with Dan that there are two problems. > 1. a set of guidance on how a WG (any WG, not only BEHAVE) should > choose among various protocols' > 2. what to do specifically in the BEHAVE case > > Let me focus on 1., it's time to update RFC1052, as Dan and Tom > explained during the OPS-AREA meeting > We should set the guidance for the entire community. > The fact that there are not many YANG modules today shouldn't play > against NETCONF/YANG. The guidance could still be: if you want to do > configuration, YANG/NETCONF is the way to go > What we need is a flowchart type of things, to make it very easy for > non-OPS group to follow > As an _example _: > > - Document the operational requirements, and what information needs to > be configured/monitored/preserved. Ideally, use an information model > language (see the previous thread) > - Is there an existing data models you want to extend. If yes, extend it > - Configuration? Use NETCONF/YANG > no configuration now: do you plan on having configuration in > the future? > if "yes", investigate NETCONF/YANG > if "maybe", use an information model language (see the previous > thread) > - Operational data? > If there is a MIB, feel free to extend it? > If there is no MIB module so far, insert the operational data in > the YANG module > - you want to push some data at a high rate ? Investigate IPFIX > - you want some events > if you have a MIB module, evaluate the SNMP notification > if you have a YANG modue, evaluate the YANG notification > if you want plain english text events, evaluate syslog > if you want some structured events, evaluate syslog SDE > - etc... > > Note: obviously, when comparing technologies, the pros/cons must be > explained. > > > It's true that RFC 5706 and RFC 6632 will help, but we should really > set some guidance between the different OPS architectures. > > This exercise will certainly require some discussions with the couple > of first requests, to make sure we document everything. So that's > maybe what we should do in the BEHAVE case: have a live discussion. > > Regards, Benoit. > > Folks, > > > > The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > > consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible." > > > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows? > > > > My best guess follows...... > > > > - The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that. > > - The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation. > > - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols > > - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols > > > > Comments? > > > > Ron > > > > > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > > > > --------------070409090708020102040505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Ron,

Benoit,

 

IMHO, our first priority should be to provide concrete guidance to BEHAVE. The BEHAVE WG will become grumpy if we ask them to wait while OPS debates abstractions.

Agreed.
Since we don't have the clear guidelines written down right now, I believe that conf. call is the way to go in this case.

 

Our second priority should be to issue general guidance to WGs. Guidance should answer the following questions:

 

-          Does the WG need model managed data?

-          Can managed data be divided into categories? If so, how? (Configuration versus operational state?  candidate versus current versus previous state? Data that is sampled versus data that is retained completely? Data that must be retained versus data that can be lost?)

-          What protocol does the IETF recommend for each category?

-          Does the IETF recommendation give implementers latitude to use a protocol other than that which is recommended? How much latitude?

-          How should data be modeled? Using an abstract notation or a protocol specific notation?

That's a good series of questions to start with.

Regards, Benoit

 

Comments?

 

                    Ron

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Thursday, August 09, 2012 9:55 AM
To: Ronald Bonica
Cc: ops-area@ietf.org; tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org
Subject: Re: [OPS-AREA] Management Requirements

 

Ron,

I read the entire email thread. So let me reply to this email with information from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS group to follow
As an example :

- Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread)
- Is there an existing data models you want to extend. If yes, extend it
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread)
- Operational data?
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

Note: obviously, when comparing technologies, the pros/cons must be explained.


It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion.

Regards, Benoit.

Folks,
 
The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be
consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible."
 
Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows?
 
My best guess follows......
 
- The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that.
- The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation.
- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols
- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols
 
Comments?
 
                                              Ron
 
 
 
_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
 
 

 


--------------070409090708020102040505-- From bclaise@cisco.com Fri Aug 10 06:10:38 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D821F84A2 for ; Fri, 10 Aug 2012 06:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mzyhBFd8sx0 for ; Fri, 10 Aug 2012 06:10:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 996EB21F849B for ; Fri, 10 Aug 2012 06:10:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7ADAZFi002354; Fri, 10 Aug 2012 15:10:35 +0200 (CEST) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q7ADAYpk010105; Fri, 10 Aug 2012 15:10:34 +0200 (CEST) Message-ID: <5025084A.7050700@cisco.com> Date: Fri, 10 Aug 2012 15:10:34 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <5023C132.7040504@cisco.com> <056301cd769e$870933d0$951b9b70$@olddog.co.uk> In-Reply-To: <056301cd769e$870933d0$951b9b70$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------040200040001010502050609" Cc: ops-area@ietf.org, behave-chairs@tools.ietf.org, tsv-ads@tools.ietf.org Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 13:10:38 -0000 This is a multi-part message in MIME format. --------------040200040001010502050609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Thanks for your feedback. > > Hi Benoit, > > This is a reasonable start, but does omit the whole "information > model" thing. > I'm not sure how we could have some sort of data models consistency without a common information model. > > I confess to finding UML diagrams not very useful. I prefer an > information model written in some form of semi-formal language. I am > wondering whether YANG isn't exactly that language. > I'll investigate if this is the case... > > (Yes, that gives the YANG module an unfair advantage). > That would be nice. > > BTW, I really wish we didn't always write "NETCONF/YANG". They are > separate entities and one could use one without the other. > What was meant is: define your data model in YANG, and manage your boxes with the NETCONF protocol Regards, Benoit. > > Cheers, > > Adrian > > *From:*ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] > *On Behalf Of *Benoit Claise > *Sent:* 09 August 2012 14:55 > *To:* Ronald Bonica > *Cc:* tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; > ops-area@ietf.org > *Subject:* Re: [OPS-AREA] Management Requirements > > Ron, > > I read the entire email thread. So let me reply to this email with > information from different participants > > I agree with Dan that there are two problems. > 1. a set of guidance on how a WG (any WG, not only BEHAVE) should > choose among various protocols' > 2. what to do specifically in the BEHAVE case > > Let me focus on 1., it's time to update RFC1052, as Dan and Tom > explained during the OPS-AREA meeting > We should set the guidance for the entire community. > The fact that there are not many YANG modules today shouldn't play > against NETCONF/YANG. The guidance could still be: if you want to do > configuration, YANG/NETCONF is the way to go > What we need is a flowchart type of things, to make it very easy for > non-OPS group to follow > As an _example _: > > - Document the operational requirements, and what information needs to > be configured/monitored/preserved. Ideally, use an information model > language (see the previous thread) > - Is there an existing data models you want to extend. If yes, extend it > - Configuration? Use NETCONF/YANG > no configuration now: do you plan on having configuration in > the future? > if "yes", investigate NETCONF/YANG > if "maybe", use an information model language (see the previous > thread) > - Operational data? > If there is a MIB, feel free to extend it? > If there is no MIB module so far, insert the operational data in > the YANG module > - you want to push some data at a high rate ? Investigate IPFIX > - you want some events > if you have a MIB module, evaluate the SNMP notification > if you have a YANG modue, evaluate the YANG notification > if you want plain english text events, evaluate syslog > if you want some structured events, evaluate syslog SDE > - etc... > > Note: obviously, when comparing technologies, the pros/cons must be > explained. > > > It's true that RFC 5706 and RFC 6632 will help, but we should really > set some guidance between the different OPS architectures. > > This exercise will certainly require some discussions with the couple > of first requests, to make sure we document everything. So that's > maybe what we should do in the BEHAVE case: have a live discussion. > > Regards, Benoit. > > Folks, > > > > The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be > > consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible." > > > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows? > > > > My best guess follows...... > > > > - The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that. > > - The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation. > > - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols > > - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols > > > > Comments? > > > > Ron > > > > > > > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-area > > > > > --------------040200040001010502050609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Adrian,

Thanks for your feedback.

Hi Benoit,

 

This is a reasonable start, but does omit the whole "information model" thing.

I'm not sure how we could have some sort of data models consistency without a common information model.

I confess to finding UML diagrams not very useful. I prefer an information model written in some form of semi-formal language. I am wondering whether YANG isn't exactly that language.

I'll investigate if this is the case...

(Yes, that gives the YANG module an unfair advantage).

That would be nice.

 

BTW, I really wish we didn't always write "NETCONF/YANG". They are separate entities and one could use one without the other.

What was meant is: define your data model in YANG, and manage your boxes with the NETCONF protocol

Regards, Benoit.

 

Cheers,

Adrian

 

From: ops-area-bounces@ietf.org [mailto:ops-area-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: 09 August 2012 14:55
To: Ronald Bonica
Cc: tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org; ops-area@ietf.org
Subject: Re: [OPS-AREA] Management Requirements

 

Ron,

I read the entire email thread. So let me reply to this email with information from different participants

I agree with Dan that there are two problems.
1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose among various protocols'
2. what to do specifically in the BEHAVE case

Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained during the OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there are not many YANG modules today shouldn't play against NETCONF/YANG. The guidance could still be: if you want to do configuration, YANG/NETCONF is the way to go
What we need is a flowchart type of things, to make it very easy for non-OPS group to follow
As an example :

- Document the operational requirements, and what information needs to be configured/monitored/preserved. Ideally, use an information model language (see the previous thread)
- Is there an existing data models you want to extend. If yes, extend it
- Configuration? Use NETCONF/YANG
       no configuration now: do you plan on having configuration in the future?
       if "yes", investigate NETCONF/YANG
       if "maybe", use an information model language (see the previous thread)
- Operational data?
    If there is a MIB, feel free to extend it?
    If there is no MIB module so far, insert the operational data in the YANG module
- you want to push some data at a high rate ? Investigate IPFIX
- you want some events
        if you have a MIB module, evaluate the SNMP notification
        if you have a YANG modue, evaluate the YANG notification
        if you want plain english text events, evaluate syslog
        if you want some structured events, evaluate syslog SDE
- etc...

Note: obviously, when comparing technologies, the pros/cons must be explained.


It's true that RFC 5706 and RFC 6632 will help, but we should really set some guidance between the different OPS architectures.

This exercise will certainly require some discussions with the couple of first requests, to make sure we document everything. So that's maybe what we should do in the BEHAVE case: have a live discussion.

Regards, Benoit.

Folks,
 
The BEHAVE WG brings us a concrete example of a problem that we discussed in Vancouver. According to their charter, the BEHAVE WG "creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible." Also, according to their charter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be
consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible."
 
Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NETCONF is the right tool for configuration? Maybe SNMP is right for fault monitoring? Maybe syslog is right for maintaining a record of address mappings? Who knows?
 
My best guess follows......
 
- The BEHAVE WG knows what information needs to be configured/monitored/preserved. They MUST specify that.
- The BEHAVE WG and the OPS Area have an equal stake in determining which tool is recommended to manage each type of data. They should work together to make a recommendation. In the best of all possible worlds, that decision would be informed by a well-documented guideline. However, in the world that we inhabit, that decision may need to be facilitated by a conversation.
- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) for the recommended protocols
- The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for the non-recommended protocols
 
Comments?
 
                                              Ron
 
 
 
_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area
 
 

 


--------------040200040001010502050609-- From mgia0477@motorola.com Fri Aug 10 07:31:14 2012 Return-Path: X-Original-To: ops-area@ietfa.amsl.com Delivered-To: ops-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EC921F85F0 for ; Fri, 10 Aug 2012 07:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbYF4COYzrhB for ; Fri, 10 Aug 2012 07:31:13 -0700 (PDT) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id AECCE21F85FC for ; Fri, 10 Aug 2012 07:31:12 -0700 (PDT) Received: from il93mgrg01.am.mot-mobility.com ([144.188.21.13]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUCUbMNzmz1VDAX1hoPtwGoiBqZKYs5ai@postini.com; Fri, 10 Aug 2012 07:31:12 PDT Received: from il93mgrg01.am.mot-mobility.com ([10.176.130.20]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id q7AEMcXL003348 for ; Fri, 10 Aug 2012 10:22:39 -0400 (EDT) Received: from mail-pb0-f72.google.com (mail-pb0-f72.google.com [209.85.160.72]) by il93mgrg01.am.mot-mobility.com (8.14.3/8.14.3) with ESMTP id q7AEMbWj003327 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Fri, 10 Aug 2012 10:22:38 -0400 (EDT) Received: by pbbro12 with SMTP id ro12so657273pbb.3 for ; Fri, 10 Aug 2012 07:31:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=WjRh3BgqBuP7sDrIuV9eZMhzFuI+kHGhWvZXG0bfWo8=; b=Ex5sFwEb77CZyQQtj6a6CEezLNDiOD0V5manwxlNvzcQSvgqflosLlw1T9+OnlO69Q weBQhsswHpmp00aPYFrM8wyHm4wVi+bYTJFkc5XwpFJG/JganNuj2YNwyloRaG/+k31M zk714a/NnSXnHFRv4fx7FV2TMoz9SO56S1yUVUXJYlmHKEnKlC93JsVQt0OtGjC5L/Ru m7CbSxAa3Mp34zS2i8Tfu/SPPJ717N4c6jVY4RSVD6BsvZoxJeXCzHboANaQHS4TM8jn X1J6bqGJivHKhMHEb6IoVw3LNEzLpnlotuOoOioybXIh/fJdv4MhqdjCVeKIdPyxKwS6 zGOw== Received: by 10.68.195.197 with SMTP id ig5mr12849392pbc.137.1344609068769; Fri, 10 Aug 2012 07:31:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.197 with SMTP id ig5mr12849367pbc.137.1344609068591; Fri, 10 Aug 2012 07:31:08 -0700 (PDT) Received: by 10.68.6.135 with HTTP; Fri, 10 Aug 2012 07:31:07 -0700 (PDT) In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D77198937A@EMBX01-WF.jnpr.net> References: <20120803051042.GA88050@elstar.local> <13205C286662DE4387D9AF3AC30EF456D77178C173@EMBX01-WF.jnpr.net> <5023C132.7040504@cisco.com> <13205C286662DE4387D9AF3AC30EF456D77198937A@EMBX01-WF.jnpr.net> Date: Fri, 10 Aug 2012 10:31:07 -0400 Message-ID: From: Andrew Donati To: Ronald Bonica Content-Type: multipart/alternative; boundary=047d7b10c8dfe52aec04c6ea3141 X-Gm-Message-State: ALoCoQmo7jjXQvJb6heAW0h26Q1nTdX5DxsTUlFweFqhL/sbODA/s4oLFLr1LY0Ghqh1of5K7Qe23RPSOmQ4EOnzLnDBm0K0tMjfweD5DeBzvEk08RhfEhdSqP0O6QUqaIhoSVEM91h88tiNXAdxiDtZqsCkJj/IFw== X-CFilter-Loop: Reflected Cc: "tsv-ads@tools.ietf.org" , "behave-chairs@tools.ietf.org" , "ops-area@ietf.org" Subject: Re: [OPS-AREA] Management Requirements X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:31:14 -0000 --047d7b10c8dfe52aec04c6ea3141 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >What we need is a flowchart type of things, to make it very easy for non-OPS group to follow >As an *example *:- Document the operational requirements As part of the operational requirements, we also need insight on how management information will be used in the field . Knowing this information will also help determine the appropriate tool or set of tools to use. Here are a few questions to start with. - Is configuration required ? - Will numerous devices (i.e. hundreds of devices) be monitored by any one management entity ? - When monitoring any one device, does it require the collection of a large amount of data? If so , how large? - How frequently will any one device be monitored? - Will any one device be monitored periodically or only when it sends an unsolicited event ? - How busy and reliable will the management network be ? - Andy On Thu, Aug 9, 2012 at 8:53 PM, Ronald Bonica wrote: > Benoit,**** > > ** ** > > IMHO, our first priority should be to provide concrete guidance to BEHAVE= . > The BEHAVE WG will become grumpy if we ask them to wait while OPS debates > abstractions.**** > > ** ** > > Our second priority should be to issue general guidance to WGs. Guidance > should answer the following questions:**** > > ** ** > > **- **Does the WG need model managed data?**** > > **- **Can managed data be divided into categories? If so, how? > (Configuration versus operational state? candidate versus current versus > previous state? Data that is sampled versus data that is retained > completely? Data that must be retained versus data that can be lost?)**** > > **- **What protocol does the IETF recommend for each category? *= * > ** > > **- **Does the IETF recommendation give implementers latitude to > use a protocol other than that which is recommended? How much latitude?**= * > * > > **- **How should data be modeled? Using an abstract notation or > a protocol specific notation?**** > > ** ** > > Comments?**** > > ** ** > > Ron**** > > ** ** > > ** ** > > *From:* Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Thursday, August 09, 2012 9:55 AM > *To:* Ronald Bonica > *Cc:* ops-area@ietf.org; tsv-ads@tools.ietf.org; > behave-chairs@tools.ietf.org > *Subject:* Re: [OPS-AREA] Management Requirements**** > > ** ** > > Ron, > > I read the entire email thread. So let me reply to this email with > information from different participants > > I agree with Dan that there are two problems. > 1. a set of guidance on how a WG (any WG, not only BEHAVE) should choose > among various protocols' > 2. what to do specifically in the BEHAVE case > > Let me focus on 1., it's time to update RFC1052, as Dan and Tom explained > during the OPS-AREA meeting > We should set the guidance for the entire community. > The fact that there are not many YANG modules today shouldn't play agains= t > NETCONF/YANG. The guidance could still be: if you want to do configuratio= n, > YANG/NETCONF is the way to go > What we need is a flowchart type of things, to make it very easy for > non-OPS group to follow > As an *example *:**** > > - Document the operational requirements, and what information needs to be > configured/monitored/preserved. Ideally, use an information model languag= e > (see the previous thread) > - Is there an existing data models you want to extend. If yes, extend it > - Configuration? Use NETCONF/YANG > no configuration now: do you plan on having configuration in the > future? > if "yes", investigate NETCONF/YANG > if "maybe", use an information model language (see the previous > thread) > - Operational data? > If there is a MIB, feel free to extend it? > If there is no MIB module so far, insert the operational data in the > YANG module > - you want to push some data at a high rate ? Investigate IPFIX > - you want some events > if you have a MIB module, evaluate the SNMP notification > if you have a YANG modue, evaluate the YANG notification > if you want plain english text events, evaluate syslog > if you want some structured events, evaluate syslog SDE > - etc... > > Note: obviously, when comparing technologies, the pros/cons must be > explained.**** > > > It's true that RFC 5706 and RFC 6632 will help, but we should really set > some guidance between the different OPS architectures. > > This exercise will certainly require some discussions with the couple of > first requests, to make sure we document everything. So that's maybe what > we should do in the BEHAVE case: have a live discussion. > > Regards, Benoit.**** > > Folks,**** > > ** ** > > The BEHAVE WG brings us a concrete example of a problem that we discussed= in Vancouver. According to their charter, the BEHAVE WG "creates documents= to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a f= ashion as possible." Also, according to their charter, the BEHAVE WG "will = update the NAT MIB (RFC 4008) to be**** > > consistent with the management aspects of its IPv6/IPv4 NAT solutions, an= d specify IPFIX information elements to meet logging requirements, reusing = existing elements, if possible."**** > > ** ** > > Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe NE= TCONF is the right tool for configuration? Maybe SNMP is right for fault mo= nitoring? Maybe syslog is right for maintaining a record of address mapping= s? Who knows?**** > > ** ** > > My best guess follows......**** > > ** ** > > - The BEHAVE WG knows what information needs to be configured/monitored/p= reserved. They MUST specify that.**** > > - The BEHAVE WG and the OPS Area have an equal stake in determining which= tool is recommended to manage each type of data. They should work together= to make a recommendation. In the best of all possible worlds, that decisio= n would be informed by a well-documented guideline. However, in the world t= hat we inhabit, that decision may need to be facilitated by a conversation.= **** > > - The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG) fo= r the recommended protocols**** > > - The BEHAVE WG MAY produce protocol-specific data models (SMI, YANG) for= the non-recommended protocols**** > > ** ** > > Comments?**** > > ** ** > > Ron**** > > ** ** > > ** ** > > ** ** > > _______________________________________________**** > > OPS-AREA mailing list**** > > OPS-AREA@ietf.org**** > > https://www.ietf.org/mailman/listinfo/ops-area**** > > ** ** > > ** ** > > ** ** > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www.ietf.org/mailman/listinfo/ops-area > > --=20 Andy Donati Motorola Mobility 978-614-3190 --047d7b10c8dfe52aec04c6ea3141 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >What we need is a flowchart type of things, to make it very easy for no= n-OPS group to follow
>As an example :- Document the operation= al requirements

As part of the operational requirements,=A0 we also = need insight on how management information will be used in the field .=A0 K= nowing this information will also help determine the appropriate tool or se= t of tools to use.=A0 Here are a few=A0 questions to start with.

- Is configuration required ?
- Will numerous devices (i.e. hundreds= of devices) be monitored=A0 by any one management entity ?
- When monit= oring any one device, does it require the collection of a large amount of d= ata?=A0 If so , how large?
- How frequently will any one device be monitored?
- Will any one device= be monitored periodically or only when it sends an unsolicited event ?
= - How busy and reliable will the management network be ?

- Andy

On Thu, Aug 9, 2012 at 8:53 PM, Ronald Bonic= a <rbonica@juniper.net> wrote:
<= p class=3D"MsoNormal">Benoit,

=A0

IMHO, our first priority should be to provide= concrete guidance to BEHAVE. The BEHAVE WG will become grumpy if we ask th= em to wait while OPS debates abstractions.

=A0<= /p>

Our second priority sh= ould be to issue general guidance to WGs. Guidance should answer the follow= ing questions:

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Does the WG need model managed data?<= /u>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Can managed data be divided into categories= ? If so, how? (Configuration versus operational state? =A0candidate versus = current versus previous state? Data that is sampled versus data that is ret= ained completely? Data that must be retained versus data that can be lost?)=

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 What protocol does the IETF recommend for e= ach category?

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Does the IETF recommendation give implement= ers latitude to use a protocol other than that which is recommended? How mu= ch latitude?

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 How should data be modeled? Using an abstra= ct notation or a protocol specific notation?

=A0<= /p>

Comments?

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ron

=A0<= /p>

=A0

From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Thursday, August 09, 2012 9:55 AM
To: Ronald Bonica<= br>Cc: ops-ar= ea@ietf.org; tsv-ads@tools.ietf.org; behave-chairs@tools.ietf.org
Subject: Re: [OPS-AREA] Management Requirements=

=A0

Ron,

I read the entire email thread. So let me reply = to this email with information from different participants

I agree with Dan that there are two problems.
1. a set of guidance o= n how a WG (any WG, not only BEHAVE) should choose among various protocols&= #39;
2. what to do specifically in the BEHAVE case

Let me focus o= n 1., it's time to update RFC1052, as Dan and Tom explained during the = OPS-AREA meeting
We should set the guidance for the entire community.
The fact that there= are not many YANG modules today shouldn't play against NETCONF/YANG. T= he guidance could still be: if you want to do configuration, YANG/NETCONF i= s the way to go
What we need is a flowchart type of things, to make it very easy for non-OP= S group to follow
As an example :

- Document the operational requirements, and what information need= s to be configured/monitored/preserved. Ideally, use an information model l= anguage (see the previous thread)
- Is there an existing data models you want to extend. If yes, extend it - Configuration? Use NETCONF/YANG
=A0=A0=A0 =A0=A0 no configuration no= w: do you plan on having configuration in the future?
=A0=A0=A0 =A0=A0 i= f "yes", investigate NETCONF/YANG
=A0=A0=A0 =A0=A0 if "maybe", use an information model language (s= ee the previous thread)
- Operational data?
=A0=A0=A0 If there is a= MIB, feel free to extend it?
=A0=A0=A0 If there is no MIB module so far= , insert the operational data in the YANG module
- you want to push some data at a high rate ? Investigate IPFIX
- you wa= nt some events
=A0=A0=A0 =A0=A0=A0 if you have a MIB module, evaluate th= e SNMP notification
=A0=A0=A0 =A0=A0=A0 if you have a YANG modue, evalua= te the YANG notification
=A0=A0=A0 =A0=A0=A0 if you want plain english text events, evaluate syslog<= br>=A0=A0=A0 =A0=A0=A0 if you want some structured events, evaluate syslog = SDE
- etc...

Note: obviously, when comparing technologies, the pr= os/cons must be explained.


It's true tha= t RFC 5706 and RFC 6632 will help, but we should really set some guidance b= etween the different OPS architectures.

This exercise will certainly= require some discussions with the couple of first requests, to make sure w= e document everything. So that's maybe what we should do in the BEHAVE = case: have a live discussion.

Regards, Benoit.

Folks,
=A0<=
u>
The BEHAVE WG brings us a concrete example of a problem th=
at we discussed in Vancouver. According to their charter, the BEHAVE WG &qu=
ot;creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in =
as deterministic a fashion as possible." Also, according to their char=
ter, the BEHAVE WG "will update the NAT MIB (RFC 4008) to be=

consistent with the management aspects of its IPv6/IPv4 NAT solutions,=
 and specify IPFIX information elements to meet logging requirements, reusi=
ng existing elements, if possible."
=A0=

Now BEHAVE is asking whether SNMP and IPFIX are the right tools. Maybe=
 NETCONF is the right tool for configuration? Maybe SNMP is right for fault=
 monitoring? Maybe syslog is right for maintaining a record of address mapp=
ings? Who knows?
=A0
My best guess follows......<=
/pre>
=A0
- The BEHAVE WG knows what informatio=
n needs to be configured/monitored/preserved. They MUST specify that.


- The BEHAVE WG and the OPS Area have an equal stake in determining wh=
ich tool is recommended to manage each type of data. They should work toget=
her to make a recommendation. In the best of all possible worlds, that deci=
sion would be informed by a well-documented guideline. However, in the worl=
d that we inhabit, that decision may need to be facilitated by a conversati=
on.


- The BEHAVE WG MUST produce protocol-specific data models (SMI, YANG)=
 for the recommended protocols
- The BEHAVE WG MAY =
produce protocol-specific data models (SMI, YANG) for the non-recommended p=
rotocols


=A0
Comments?
=
=A0
 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0Ron
=A0
=A0=

=A0


_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/ops-area" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/ops-area
=A0
=A0

=A0


_______________= ________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www.ietf.org/mailman/listinfo/ops-area




--
Andy Donati
Moto= rola Mobility
978-614-3190
--047d7b10c8dfe52aec04c6ea3141--