From xuxiaohu@huawei.com Wed Nov 2 22:07:31 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DFD1F0C54 for ; Wed, 2 Nov 2011 22:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.453 X-Spam-Level: X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 USW59tg14qah for ; Wed, 2 Nov 2011 22:07:31 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4A1F0C43 for ; Wed, 2 Nov 2011 22:07:30 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU2005JVJK3TX@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 03 Nov 2011 13:07:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU2008V0JK1LF@szxga05-in.huawei.com> for opsawg@ietf.org; Thu, 03 Nov 2011 13:07:15 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AES55770; Thu, 03 Nov 2011 13:07:12 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 03 Nov 2011 13:07:06 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.181]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Thu, 03 Nov 2011 13:07:03 +0800 Date: Thu, 03 Nov 2011 05:07:02 +0000 From: Xuxiaohu X-Originating-IP: [10.108.4.59] To: "sob@harvard.edu" , "ietf@cdl.asgaard.org" , "rbonica@juniper.net" , "dromasca@avaya.com" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE73CD13@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: Request a timeslot for presentation on a DCI solution Thread-index: AcyZ6F76orxGETr0QZalsOze36BrKQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "opsawg@ietf.org" Subject: [OPSAWG] Request a timeslot for presentation on a DCI solution X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 05:07:31 -0000 Dear OPS WG co-chairs and OPS Area directors, I would like to request a timeslot for presenting Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) which realizes subnet extension across geographically dispersed data centers by using proven L3VPN and ARP proxy technologies. Subnet extension across data centers is a basic requirement for VM mobility across data centers. Since it has no change to L3VPN protocol, I think OPSWG/OPSArea is a good place to talk about it. Has there been a DCOPS WG/BOF in OPS AREA before? Abstract of Virtual Subnet: Virtual Subnet (VS) provides a scalable data center interconnection service (e.g., subnet extension across data centers) by reusing the proven BGP/MPLS IP VPN [RFC4364] and ARP proxy [RFC925][RFC1027] technologies. In contrast with the existing VPLS solutions, VS could bring us many attractive benefits: First, it alleviates the broadcast storm impact on the network performance to a great extent by splitting the otherwise whole ARP broadcast and unknown unicast flooding domain associated with the IP subnet that has been extended across multiple data centers, into multiple isolated parts; Second, the forwarding table scalability issue on data center switches (e.g., ToR switches) is successfully solved by splitting the MAC learning domain associated with the same subnet into multiple segments due to the usage of ARP proxy; Third, it can support active-active data center exits and path optimization.... Best regards, Xiaohu From leonidas@netmode.ntua.gr Mon Nov 7 03:41:04 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FEC21F8B1C for ; Mon, 7 Nov 2011 03:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l2ek7jhYxGh for ; Mon, 7 Nov 2011 03:41:04 -0800 (PST) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2CE21F8B1A for ; Mon, 7 Nov 2011 03:41:03 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by ulysses.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pA7Bf24l095805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Nov 2011 13:41:02 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pA7Bf1qH021681; Mon, 7 Nov 2011 13:41:02 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Date: Mon, 07 Nov 2011 13:40:02 +0200 To: opsawg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]); Mon, 07 Nov 2011 13:41:02 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at ulysses.noc.ntua.gr X-Virus-Status: Clean Subject: [OPSAWG] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 11:41:05 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From ietf@cdl.asgaard.org Sun Nov 13 22:35:41 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B221F0C5F for ; Sun, 13 Nov 2011 22:35:41 -0800 (PST) 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 JXH3UhuuXLvN for ; Sun, 13 Nov 2011 22:35:40 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id BD2401F0C36 for ; Sun, 13 Nov 2011 22:35:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id DA9F28D864B for ; Mon, 14 Nov 2011 06:35:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6pSimVaUMWG for ; Mon, 14 Nov 2011 06:35:39 +0000 (UTC) Received: from dhcp-6302.meeting.ietf.org (dhcp-6302.meeting.ietf.org [130.129.99.2]) by asgaard.org (Postfix) with ESMTPSA id C17818D863D for ; Mon, 14 Nov 2011 06:35:38 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_8093AB83-2D93-4B09-AA02-1205F2A5CBB1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Sun, 13 Nov 2011 22:35:37 -0800 Message-Id: <8A72E1F0-96F0-4BC1-867B-120FD864AB1A@cdl.asgaard.org> To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Subject: [OPSAWG] Scribes and Jabberers... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 06:35:41 -0000 --Apple-Mail=_8093AB83-2D93-4B09-AA02-1205F2A5CBB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, You will achieve fame and fortune (or at least a beer from the = chairs) if you volunteer for the scribe and jabber functions before the = meeting tomorrow. =20 See you all tomorrow morning. Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_8093AB83-2D93-4B09-AA02-1205F2A5CBB1 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOwLa6AAoJEGmx2Mt/+Iw/szkH/0Z1yR0lMhSDapp+ivd2KECs oS4RcLz3DA0vVHvToM0IY5r2K7w2dsSRGnRnnwjaVWjPZ388Tcwhr4hrJnLEx5l4 Yjk8id4DJEQ11fplyDFS79ydirEw2l05sdEt2aWAjtv3lmXvR1aN2xT6A8O3eziP vRFBvaNroMFV0fFXusGuNaTNOYGWGAmwg5HmoP1G4JS0QO7krcfJPvpC37VybxZp RlaOfTwDGfmyHc1CBHbIDJazd4wD2C/wC5ME8Z46ZJ2J0ButHriMIFF2tbiCJo/V ibnvNSO7KXCViPZ5TLqrcY/08ijEbS5a9Ox3YnT7EzaOgfb88x1THEpa24LEfPs= =IJb9 -----END PGP SIGNATURE----- --Apple-Mail=_8093AB83-2D93-4B09-AA02-1205F2A5CBB1-- From j.schoenwaelder@jacobs-university.de Mon Nov 14 06:34:22 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461AE11E80B0 for ; Mon, 14 Nov 2011 06:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.18 X-Spam-Level: X-Spam-Status: No, score=-103.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 meuZW54CdrZ9 for ; Mon, 14 Nov 2011 06:34:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E43C11E8081 for ; Mon, 14 Nov 2011 06:34:20 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E1A120D36 for ; Mon, 14 Nov 2011 15:34:19 +0100 (CET) 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 oZonuMUbwzlA; Mon, 14 Nov 2011 15:34:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 447AB20D34; Mon, 14 Nov 2011 15:34:18 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6EBBA1BB3F88; Mon, 14 Nov 2011 15:34:01 +0100 (CET) Date: Mon, 14 Nov 2011 15:34:01 +0100 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20111114143401.GA18848@elstar.local> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OPSAWG] management standards nits X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 14:34:22 -0000 Hi, while skimming , I observed that NETCONF is listed as Full Standard in Table 1. I also doubt that TWAMP is a Full Standard. Table 5 uses the phrases "Enterprise specific" and "Vendor specific"" and I am not sure the difference is by accident or by intention. That said, what might be more important is likely to avoid giving the expression that only enterprises/vendors can extend data models. We might want to be explicit that other SDOs of course can also extend data models. (Perhaps the last column in the take really is just a boolean if we change the column title.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Nov 14 10:18:53 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72D811E8336 for ; Mon, 14 Nov 2011 10:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETxuyDVfYCbp for ; Mon, 14 Nov 2011 10:18:53 -0800 (PST) Received: from av-tac-apt.cisco.com (no-less.cisco.com [64.104.206.252]) by ietfa.amsl.com (Postfix) with ESMTP id 84C0711E8333 for ; Mon, 14 Nov 2011 10:18:49 -0800 (PST) X-TACSUNS: Virus Scanned Received: from no-worries.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-apt.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAEIImOt026501 for ; Tue, 15 Nov 2011 05:18:48 +1100 (EST) Received: from [10.75.235.174] (hkidc-vpn-client-235-174.cisco.com [10.75.235.174]) by no-worries.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAEIIf8s002781 for ; Tue, 15 Nov 2011 05:18:43 +1100 (EST) Message-ID: <4EC15B81.9030407@cisco.com> Date: Tue, 15 Nov 2011 02:18:41 +0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <20111114143401.GA18848@elstar.local> In-Reply-To: <20111114143401.GA18848@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] management standards nits X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 18:18:54 -0000 Hi Juergen, > Hi, > > while skimming, I observed that > NETCONF is listed as Full Standard in Table 1. I also doubt that TWAMP > is a Full Standard. Good catch. And we should certainly reference RFC6241 instead of RFC4741 > > Table 5 uses the phrases "Enterprise specific" and "Vendor specific"" > and I am not sure the difference is by accident or by intention. This was done intentionally so that people could refer to the right functionality. For example, in IPFIX, it's called "Enterprise Specific Information Elements" see RFC5101. For example, in RADIUS, we speak about Vendor Specific Attributes > That > said, what might be more important is likely to avoid giving the > expression that only enterprises/vendors can extend data models. We > might want to be explicit that other SDOs of course can also extend > data models. (Perhaps the last column in the take really is just a > boolean if we change the column title.) OLD: +----------------+--------------------+---------------+-------------+ | Protocol | Data Modeling | Approach to | Proprietary | | | | extend the | Data | | | | Data Model | Modeling | | | | | Extensions | +----------------+--------------------+---------------+-------------+ NEW: +----------------+--------------------+---------------+-------------+ | Protocol | Data Modeling | Data | Proprietary | | | | Modeling | Data | | | | Extensions | Modeling | | | | | Extensions | +----------------+--------------------+--------------+-------------+ Regards, Benoit. > > /js > From j.schoenwaelder@jacobs-university.de Mon Nov 14 17:40:28 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E089111E80CA for ; Mon, 14 Nov 2011 17:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, 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 CD5KuT7CTFHU for ; Mon, 14 Nov 2011 17:40:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 33E9E11E80A2 for ; Mon, 14 Nov 2011 17:40:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2DE9220D5C; Tue, 15 Nov 2011 02:40:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TX7K3s8zXTRe; Tue, 15 Nov 2011 02:40:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED7DC20D5A; Tue, 15 Nov 2011 02:40:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A3AB1BB46D9; Tue, 15 Nov 2011 02:40:09 +0100 (CET) Date: Tue, 15 Nov 2011 02:40:09 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20111115014009.GD19642@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org References: <20111114143401.GA18848@elstar.local> <4EC15B81.9030407@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EC15B81.9030407@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] management standards nits X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 01:40:29 -0000 On Tue, Nov 15, 2011 at 02:18:41AM +0800, Benoit Claise wrote: > >Table 5 uses the phrases "Enterprise specific" and "Vendor specific"" > >and I am not sure the difference is by accident or by intention. > This was done intentionally so that people could refer to the right > functionality. > For example, in IPFIX, it's called "Enterprise Specific Information > Elements" see RFC5101. > For example, in RADIUS, we speak about Vendor Specific Attributes That's subtle, perhaps a bit too subtle for the target audience to catch. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Nov 14 18:25:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DAB11E836A for ; Mon, 14 Nov 2011 18:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MNyeRrODzsS for ; Mon, 14 Nov 2011 18:25:33 -0800 (PST) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id BE2AE11E8360 for ; Mon, 14 Nov 2011 18:25:32 -0800 (PST) X-TACSUNS: Virus Scanned Received: from sumo.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAF2PVjR022083 for ; Tue, 15 Nov 2011 11:25:31 +0900 (JST) Received: from [10.75.235.155] (hkidc-vpn-client-235-155.cisco.com [10.75.235.155]) by sumo.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAF2PUjb004584 for ; Tue, 15 Nov 2011 11:25:31 +0900 (JST) Message-ID: <4EC1CD9A.9040706@cisco.com> Date: Tue, 15 Nov 2011 10:25:30 +0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <20111114143401.GA18848@elstar.local> <4EC15B81.9030407@cisco.com> <20111115014009.GD19642@elstar.local> In-Reply-To: <20111115014009.GD19642@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OPSAWG] management standards nits X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 02:25:34 -0000 Hi Juergen, > On Tue, Nov 15, 2011 at 02:18:41AM +0800, Benoit Claise wrote: > >>> Table 5 uses the phrases "Enterprise specific" and "Vendor specific"" >>> and I am not sure the difference is by accident or by intention. >> This was done intentionally so that people could refer to the right >> functionality. >> For example, in IPFIX, it's called "Enterprise Specific Information >> Elements" see RFC5101. >> For example, in RADIUS, we speak about Vendor Specific Attributes > That's subtle, perhaps a bit too subtle for the target audience to > catch. Ok. I'll try to be less subtle then ;-) Regards, Benoit. > > /js > From vumip1@gmail.com Mon Nov 14 19:24:25 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C381F0DA8; Mon, 14 Nov 2011 19:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 v2fWxG4D7Xzf; Mon, 14 Nov 2011 19:24:25 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 131C81F0DA0; Mon, 14 Nov 2011 19:24:25 -0800 (PST) Received: by iaeo4 with SMTP id o4so10255830iae.31 for ; Mon, 14 Nov 2011 19:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=UbclDjDVjLHhl4Y7cW8z2uGagLagIYNDTjgY7WUxtOo=; b=eZLMpCSIy1tiHpmnHpEXnn8iTdLhN7kgEfuq0Y4nDCdKyY69d+c4Cf5MieI4Czj3Xm OZhFDAva9YxmCegX8Dtw+v3s6mXOHxpDPkFeh35WEBS7D7fKXwSo5R2jfTc5DutYF6+c BChs6AcgDxhrD8hGrrPrVRLkGUpmU/dmxbPo4= MIME-Version: 1.0 Received: by 10.50.194.231 with SMTP id hz7mr27882254igc.7.1321327464707; Mon, 14 Nov 2011 19:24:24 -0800 (PST) Received: by 10.50.187.161 with HTTP; Mon, 14 Nov 2011 19:24:24 -0800 (PST) Date: Mon, 14 Nov 2011 22:24:24 -0500 Message-ID: From: Bhumip Khasnabish To: l3vpn@ietf.org, opsawg@ietf.org Content-Type: multipart/alternative; boundary=14dae9340dc12a753d04b1bd8680 Cc: igor.faynberg@alcatel-lucent.com, wei.yinxing@zte.com.cn, Lin.ZhaoJi@zte.com.cn, Zachary.Zeltsan@alcatel-lucent.com, zhang.ruishan@zte.com.cn Subject: [OPSAWG] looking forward to your comments on the Security Framework for Virtualized Data Center Services draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:24:25 -0000 --14dae9340dc12a753d04b1bd8680 Content-Type: text/plain; charset=ISO-8859-1 Hello, We are planning to update Security Framework for Virtualized Data Center Services draft based on the comments that we received so far. If you have any additional comments, pls send to the dist. lists before middle of December 2011. Many thanks in advance. Best. Bhumip ================================================================== A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Framework for Virtualized Data Center Services Author(s) : Suren Karavettil Bhumip Khasnabish Ning So Wei Dong Filename : draft-karavettil-vdcs-security-framework-00.txt Pages : 20 Date : 2011-06-30 This document discusses the requirements and technology gaps related to security in the virtualized data center services (VDCS). The objective is to ensure end-to-end security for various types of carrier services built on virtualized infrastructure. The issues covered in this draft are focused on confidentiality and integrity of the services in the virtualized environment; including but not limited to infrastructure (IaaS), platform (PaaS), and application (SaaS) services. This draft also takes into account transient nature of identity, resources and connectivity in the virtualized environment. A URL for this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-karavettil-vdcs-security-framework-00.txt Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at:ftp://ftp.ietf.org/internet-drafts/draft-karavettil-vdcs-security-framework-00.txt --14dae9340dc12a753d04b1bd8680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
We are planning to update Security Framework for Virtualized Data Cent= er Services draft
based on the comments that we received so far.
=A0
If you have any additional comments, pls send to the dist. lists befor= e middle of December 2011.
=A0
Many thanks in advance.
=A0
Best.
=A0
Bhumip
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A Ne=
w Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Security Framework for Virtualized Data Center Services
	Author(s)       : Suren Karavettil
                          Bhumip Khasnabish
                          Ning So
                          Wei Dong
	Filename        : draft-karavettil-vdcs-security-framework-00.txt
	Pages           : 20
	Date            : 2011-06-30

   This document discusses the requirements and technology gaps related
   to security in the virtualized data center services (VDCS).  The
   objective is to ensure end-to-end security for various types of
   carrier services built on virtualized infrastructure.  The issues
   covered in this draft are focused on confidentiality and integrity of
   the services in the virtualized environment; including but not
   limited to infrastructure (IaaS), platform (PaaS), and application
   (SaaS) services.  This draft also takes into account transient nature
   of identity, resources and connectivity in the virtualized
   environment.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/d=
raft-karavettil-vdcs-security-framework-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.=
ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/dra=
ft-karavettil-vdcs-security-framework-00.txt
--14dae9340dc12a753d04b1bd8680-- From j.schoenwaelder@jacobs-university.de Wed Nov 16 20:19:22 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84EBC11E8106 for ; Wed, 16 Nov 2011 20:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.193 X-Spam-Level: X-Spam-Status: No, score=-103.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 KhguFuhJjyQ4 for ; Wed, 16 Nov 2011 20:19:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 15CFC11E80BB for ; Wed, 16 Nov 2011 20:19:17 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6BC2F20D9F for ; Thu, 17 Nov 2011 05:19:16 +0100 (CET) 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 bp2jLIG1n4n6; Thu, 17 Nov 2011 05:19:14 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D69E420DF9; Thu, 17 Nov 2011 05:19:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 30D781BB8002; Thu, 17 Nov 2011 05:18:57 +0100 (CET) Date: Thu, 17 Nov 2011 05:18:57 +0100 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20111117041857.GA25801@elstar.local> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="liOOAslEiF7prFVr" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 04:19:22 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, draft-ietf-opsawg-management-stds-02 has a section on "Network Management Data Models" which is structured around FCAPS which I happen to dislike for several reasons (data model work in the IETF is not organized around FCAPS, the discussion is constantly changing abstraction levels, some of the examples picked are somewhat surprising). To be constructive, I have written a replacement for this section that I think better summarizes what the IETF has to offer and how data modeling work happens to be done in the IETF. In addition, it is also shorter. I do not mind if my proposed rewrite is followed by a section discussing how all this fits into an FCAPS view of the world but such a section should be much shorter and different from what is in the current section 4. (For me, a short explanation that the IETF does not organize data models around FCAPS is really sufficient but I guess Mehmet and Benoit might not agree with that.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NMDM.txt" * Network Management Data Models The data models defined by the IETF can be broadly classified into the following categories depicted in Figure X. +-----------+ +-------------------------------+ +-----------+ | | | application layer data models | | network | | generic | +-------------------------------+ | management| | infra- | | transport layer data models | | infra- | | structure | +-------------------------------+ | structure | | data | | network layer data models | | data | | models | +-------------------------------+ | models | | | | link layer data models | | | +-----------+ +-------------------------------+ +-----------+ Figure X: Categories of network management data models Each of the categories is briefly described below. Note that the classification used here intends to provide orientation and reflects how most data models have been developed in the IETF by the various working groups. It is not a goal of this classification to easily and correctly classify all data models that have been defined by the IETF so far. The network layering model in the middle of Figure X follows the four layer model of the Internet as defined in [RFC1021]. There are many technology-specific IETF data models which are not mentioned in this document but can be found at [RFCSEARCH]. * Generic Infrastructure Data Models Generic infrastructure data models provide core abstractions that many other data models built upon. The most important of these is the interfaces data model defined in the IF-MIB [RFC2863]. It provides the basic notion of network interfaces and it allows to express stacking/layering relationships between interfaces. The interfaces data model also provides basic monitoring objects that are widely used for performance and fault management. The second important infrastructure data model is defined in the Entity MIB [RFC4133]. It exports the containment hierarchy of the physical entities (slots, modules, ports) that make up a networking device and as such it is a key data model for inventory management. Physical entities can have pointers to other data models that provide more specific information about a physical entity (e.g. physical ports usually point to the related network interface). Entity MIB extensions exist for physical sensors such as temperature sensors embedded on line cards or sensors that report fan rotation speeds [RFC3433]. Another extension models states and alarms of physical entities [RFC4268]. Some vendors have extended the basic Entity MIB with several proprietary data models. * Link Layer Data Models A number of data models exist in the form of MIB modules covering the link layers IP runs over, such as ADSL [RFC4706], VDSL [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606], Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318, RFC4363]. These so called transmission data models typically extend the generic network interfaces data model with interface type specific information. Most of the link layer data models focus on monitoring capabilities that can be used for performance and fault management functions and to some lesser extend for accounting and security management functions. The IEEE has meanwhile taken over the responsibility to maintain and further develop data models for the IEEE 802 family of protocols [RFC4663]. The cable modem industry consortium DOCSIS is working with the IETF to publish data models for cable modem networks as IETF standards-track specifications. * Network Layer Data Models There are data models in the form of MIB modules covering IP/ICMP [RFC4293, RFC4292] network protocols and their extensions (e.g., mobile IP), the core protocols of the Internet. In addition, there are data models covering popular unicast routing protocols (OSPF [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing protocols (PIM [RFC5060]). Detailed models also exist for performance measurements in the form of IP performance metrics [RFC2330]. IP performance metrics include the definition of measurement methodologies with the goal to produce repeatable and comparable measurement results. There is a growing number of metrics defined for measuring loss, delay, connectivity, etc. The necessary data model infrastructure for configuration data models covering network layers are currently being defined using NETCONF and YANG. * Transport Layer Data Models There are data models for the transport protocols TCP [RFC4022], UDP [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing extended statistics is defined as well [RFC4898]. * Application Layer Data Models Some data models have been developed for specific application protocols (e.g., SIP [RFC4780]). In addition, there are data models that provide a generic infrastructure for instrumenting applications in order to obtain data useful primarily for performance management and fault management [RFC2287, RFC2564]. In general, however, generic application MIB modules have been less successful in gaining wide-spread deployment. * Network Management Infrastructure Data Models A number of data models are concerned with the network management system itself. This includes, in addition to a set of SNMP MIB modules for monitoring and configuring SNMP itself [RFC3410], some MIB modules providing generic functions such as the calculation of expressions over MIB objects, generic functions for thresholding and event generation, event notification logging functions and data models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In addition, there are data models that allow to execute basic reachability and path discovery tests [RFC4560]. Another collection of MIB modules provides remote monitoring functions, ranging from the data link layer up to the application layer. This is known as the RMON family of MIB modules [RFC3577]. The IPFIX protocol [RFC5101] is used to export information about network flows collected at so called observation points (typically a network interface). The information elements [RFC5102] carried in IPFIX cover the network and transport layer very well but also provides some link layer specific information elements. Work is underway to further extend the standardized information that can be carried in IPFIX. The SYSLOG protocol document [RFC5424] defines an initial set of Structured Data Elements (SDEs) that relate to content time quality, content origin, and meta-information about the message, such as language. Proprietary SDEs can be used to supplement the IETF- defined SDEs. --liOOAslEiF7prFVr-- From dromasca@avaya.com Wed Nov 16 22:05:24 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5511E811B for ; Wed, 16 Nov 2011 22:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.878 X-Spam-Level: X-Spam-Status: No, score=-102.878 tagged_above=-999 required=5 tests=[AWL=-0.279, 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 fOltgjg3iE1y for ; Wed, 16 Nov 2011 22:05:19 -0800 (PST) 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 2CEB911E80EF for ; Wed, 16 Nov 2011 22:05:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAANWixE7GmAcF/2dsb2JhbAA/A5l4kA6BBYFyAQEBAQMSHgpLAgICAQgNAQIBBAEBCwYMCwEGARorCQgBAQQBEgganxibYAKGe4I3YwSaDowj X-IronPort-AV: E=Sophos;i="4.69,525,1315195200"; d="scan'208";a="218255027" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 17 Nov 2011 01:05:18 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Nov 2011 01:04:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 07:05:15 +0100 Message-ID: In-Reply-To: <20111117041857.GA25801@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [OPSAWG] network management data models - a rewrite thread-index: Acyk4BjFEtMcLpe2QdO/Rs7/TUDkEAAC0GTw References: <20111117041857.GA25801@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:05:24 -0000 Hi Juergen, It's not only Mehmet and Benoit, it's also me (as contributor and AD), and at least one position expressed in the meeting and also the silent majority in the WG meeting (to be confirmed on the list) that agree with us or do not care. You missed I think that part of the OPSAWG meeting, but what was said and agreed I think (pending on list confirmation) is that the goal of the document or one of its principal goals is to provide a view of the IETF data models for NM for external SDOs. Many of those look at management apps via a FCAPS view, and providing both views is equally important. This is the reason for which while agreeing with your view that we must emphasize the way data modeling happens in the IETF and explain it, I believe that keeping a minimal but meaningful level of presentation of the models through the FCAPS perspective is necessary for the participants out of the IETF. Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, November 17, 2011 6:19 AM > To: opsawg@ietf.org > Subject: [OPSAWG] network management data models - a rewrite >=20 > Hi, >=20 > draft-ietf-opsawg-management-stds-02 has a section on "Network > Management Data Models" which is structured around FCAPS which I happen > to dislike for several reasons (data model work in the IETF is not > organized around FCAPS, the discussion is constantly changing > abstraction levels, some of the examples picked are somewhat > surprising). To be constructive, I have written a replacement for this > section that I think better summarizes what the IETF has to offer and > how data modeling work happens to be done in the IETF. In addition, it > is also shorter. >=20 > I do not mind if my proposed rewrite is followed by a section > discussing how all this fits into an FCAPS view of the world but such a > section should be much shorter and different from what is in the > current section 4. (For me, a short explanation that the IETF does not > organize data models around FCAPS is really sufficient but I guess > Mehmet and Benoit might not agree with that.) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Nov 16 22:17:51 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C221F90F2 for ; Wed, 16 Nov 2011 22:17:51 -0800 (PST) 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 EZXnbAzQ4rpP for ; Wed, 16 Nov 2011 22:17:48 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C371621F979D for ; Wed, 16 Nov 2011 22:17:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAH6HjiH013897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 07:17:46 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAH6HjHw008306; Thu, 17 Nov 2011 07:17:45 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 07:17:45 +0100 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: Thu, 17 Nov 2011 07:17:44 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> In-Reply-To: <20111117041857.GA25801@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] network management data models - a rewrite Thread-Index: Acyk4BfDtLLjahf4SD2ftcdCWd2wAwADLafg References: <20111117041857.GA25801@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , X-OriginalArrivalTime: 17 Nov 2011 06:17:45.0724 (UTC) FILETIME=[9F37C3C0:01CCA4F0] Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:17:52 -0000 Dear Juergen, thank you for your contribution. It is valuable and fits the discussion=20 in the OPSAWG session for the second view in the document. > Hi, >=20 > draft-ietf-opsawg-management-stds-02 has a section on "Network > Management Data Models" which is structured around FCAPS which I > happen to dislike for several reasons (data model work in the IETF is > not organized around FCAPS, the discussion is constantly changing > abstraction levels, some of the examples picked are somewhat > surprising).=20 Please comment on the examples you find as not suitable. > To be constructive, I have written a replacement for this As discussed and agreed in the OPSAWG session (by the persons in the=20 session; unfortunately you were not in the meeting room at that time)=20 the best approach is to have both views in the document.=20 > section that I think better summarizes what the IETF has to offer and > how data modeling work happens to be done in the IETF. In addition, it > is also shorter. >=20 > I do not mind if my proposed rewrite is followed by a section > discussing how all this fits into an FCAPS view of the world but such > a section should be much shorter and different from what is in the > current section 4. (For me, a short explanation that the IETF does not > organize data models around FCAPS is really sufficient but I guess > Mehmet and Benoit might not agree with that.) >From the very first version of the draft our aim was to provide a detailed=20 data model survey as a guidance for the audience outside of the IETF.=20 The survey can be for sure tuned or optimized as necessary. However, we should strive for a publishing soon rather than having more cycles. Mehmet From cdl@asgaard.org Wed Nov 16 22:25:45 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA0B11E8135 for ; Wed, 16 Nov 2011 22:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 YgzfyK-Fyo04 for ; Wed, 16 Nov 2011 22:25:45 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3411E8127 for ; Wed, 16 Nov 2011 22:25:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id CBEC88F5C83; Thu, 17 Nov 2011 06:25:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-y6NJc5gYQS; Thu, 17 Nov 2011 06:25:42 +0000 (UTC) Received: from dhcp-6302.meeting.ietf.org (dhcp-6302.meeting.ietf.org [130.129.99.2]) by asgaard.org (Postfix) with ESMTPSA id 064D68F5C75; Thu, 17 Nov 2011 06:25:40 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_F7D5431B-C64D-49D2-95A6-47C141FC9DB7"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> Date: Wed, 16 Nov 2011 22:25:32 -0800 Message-Id: <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> To: "Ersue, Mehmet (NSN - DE/Munich)" , Juergen Schoenwaelder X-Mailer: Apple Mail (2.1244.3) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:25:46 -0000 --Apple-Mail=_F7D5431B-C64D-49D2-95A6-47C141FC9DB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings all, To confirm - the temperature check in the room was to include = both views in the document, as one view may resonate better with = different communities. I believe that your contribution will be a = valuable addition to the document, as it stands. If you have some = specific issues regarding the examples and their suitability, please = work with the authors on the document, however we need to do so quickly. = The consensus in the room was to advance the document in short order. =20= If anyone else in the group has a feeling on this topic, please = speak up on the list in short order. Thank you, Chris On 16Nov2011, at 22.17, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear Juergen, >=20 > thank you for your contribution. It is valuable and fits the = discussion=20 > in the OPSAWG session for the second view in the document. >=20 >> Hi, >>=20 >> draft-ietf-opsawg-management-stds-02 has a section on "Network >> Management Data Models" which is structured around FCAPS which I >> happen to dislike for several reasons (data model work in the IETF is >> not organized around FCAPS, the discussion is constantly changing >> abstraction levels, some of the examples picked are somewhat >> surprising).=20 >=20 > Please comment on the examples you find as not suitable. >=20 >> To be constructive, I have written a replacement for this >=20 > As discussed and agreed in the OPSAWG session (by the persons in the=20= > session; unfortunately you were not in the meeting room at that time)=20= > the best approach is to have both views in the document.=20 >=20 >> section that I think better summarizes what the IETF has to offer and >> how data modeling work happens to be done in the IETF. In addition, = it >> is also shorter. >>=20 >> I do not mind if my proposed rewrite is followed by a section >> discussing how all this fits into an FCAPS view of the world but such >> a section should be much shorter and different from what is in the >> current section 4. (For me, a short explanation that the IETF does = not >> organize data models around FCAPS is really sufficient but I guess >> Mehmet and Benoit might not agree with that.) >=20 > =46rom the very first version of the draft our aim was to provide a > detailed=20 > data model survey as a guidance for the audience outside of the IETF.=20= > The survey can be for sure tuned or optimized as necessary. However, > we should strive for a publishing soon rather than having more cycles. >=20 > Mehmet > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_F7D5431B-C64D-49D2-95A6-47C141FC9DB7 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOxKjfAAoJEGmx2Mt/+Iw/xq8H/1bwdV7lmSKLlsfHbEli8VXM DzKqpPEn1YR6jZvjB6tgNW3iZNbgSagmk4sa1d2UKT41HKOuscbg3VskW3JS8Q2T l5g33lBJLz0CfIiKdOH8sfWSfY/akVLx3v8UAB86jluDOQbgbrQyWbOQ+OzSgAzI oWmfsbtoSMKnpUSQlmM711vuSyim/XsrlrYX8o5BDd5JdfEDrJ4SuLGSs/Ze5QUR ifMEcLKbMtDJSu/0uJUCxhFF5pQNb6lY2Vbltme6JJBkyMtL7wTrEN/EsYkOcz05 HJCT9QRLCy79J2V+ee0f4sHzXtXkoekHLTGwNbbLqdiZH9MUkiOTzh+ns+GicbM= =PkbM -----END PGP SIGNATURE----- --Apple-Mail=_F7D5431B-C64D-49D2-95A6-47C141FC9DB7-- From j.schoenwaelder@jacobs-university.de Wed Nov 16 22:42:22 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5380611E80BA for ; Wed, 16 Nov 2011 22:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 R3ig4Cz5To7y for ; Wed, 16 Nov 2011 22:42:21 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 594DF11E80A0 for ; Wed, 16 Nov 2011 22:42:21 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE2A320E07; Thu, 17 Nov 2011 07:42:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id J6YEvdtkqzCf; Thu, 17 Nov 2011 07:42:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3155F20DF9; Thu, 17 Nov 2011 07:42:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BE0631BB8570; Thu, 17 Nov 2011 07:42:01 +0100 (CET) Date: Thu, 17 Nov 2011 07:42:01 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20111117064159.GA26328@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:42:22 -0000 On Thu, Nov 17, 2011 at 07:05:15AM +0100, Romascanu, Dan (Dan) wrote: > Hi Juergen, > > It's not only Mehmet and Benoit, it's also me (as contributor and AD), > and at least one position expressed in the meeting and also the silent > majority in the WG meeting (to be confirmed on the list) that agree with > us or do not care. You missed I think that part of the OPSAWG meeting, > but what was said and agreed I think (pending on list confirmation) is > that the goal of the document or one of its principal goals is to > provide a view of the IETF data models for NM for external SDOs. Many of > those look at management apps via a FCAPS view, and providing both views > is equally important. This is the reason for which while agreeing with > your view that we must emphasize the way data modeling happens in the > IETF and explain it, I believe that keeping a minimal but meaningful > level of presentation of the models through the FCAPS perspective is > necessary for the participants out of the IETF. The text there currently is in my view not suitable to say it politely. If needed, I can also write a short text explaining why data models are not organized around FCAPS in the IETF. (There is already text like that.) If people want text that puts our data models into FCAPS in some level of detail, you will either produce boring repetition (as most of our MIB modules do support P and F equally well) or you have to have text that is much shorter and remains at a rather abstract level, i.e. data link data models usually support P and F. I am not strictly against having some FCAPS discussion in the document but the text we currently have is IMHO not suitable. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Wed Nov 16 22:48:02 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76E21F9775 for ; Wed, 16 Nov 2011 22:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCs20m47EsnV for ; Wed, 16 Nov 2011 22:48:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B4EFA21F9774 for ; Wed, 16 Nov 2011 22:48:01 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14C1F20D44; Thu, 17 Nov 2011 07:48:01 +0100 (CET) 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 UDLGPPnuOyzp; Thu, 17 Nov 2011 07:48:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D902720D27; Thu, 17 Nov 2011 07:47:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 770531BB85E9; Thu, 17 Nov 2011 07:47:42 +0100 (CET) Date: Thu, 17 Nov 2011 07:47:42 +0100 From: Juergen Schoenwaelder To: Christopher LILJENSTOLPE Message-ID: <20111117064742.GB26328@elstar.local> Mail-Followup-To: Christopher LILJENSTOLPE , "Ersue, Mehmet (NSN - DE/Munich)" , opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:48:02 -0000 On Wed, Nov 16, 2011 at 10:25:32PM -0800, Christopher LILJENSTOLPE wrote: > To confirm - the temperature check in the room was to include both > views in the document, as one view may resonate better with > different communities. I believe that your contribution will be a > valuable addition to the document, as it stands. If you have some > specific issues regarding the examples and their suitability, please > work with the authors on the document, however we need to do so > quickly. The consensus in the room was to advance the document in > short order. I am trying to work with the authors. I think it is now their turn to revise their text. (I can also write something about FCAPS myself but that might not get us closer to a solution acceptable for all of us.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Nov 16 22:48:33 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1BB21F97B2 for ; Wed, 16 Nov 2011 22:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=0.223, 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 YpCFL6Q8G01C for ; Wed, 16 Nov 2011 22:48:27 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3F21F9774 for ; Wed, 16 Nov 2011 22:48:26 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArQAANCsxE7GmAcF/2dsb2JhbAA/A5l4kA6BBYFyAQEBAQMSHgo/DAICAgEIDQECAQQBAQEKBgwLAQYBGisJCAEBBBMIGp8qm1AChnuCN2MEmg6MIw X-IronPort-AV: E=Sophos;i="4.69,525,1315195200"; d="scan'208";a="277900217" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Nov 2011 01:48:25 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Nov 2011 01:47:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 07:48:15 +0100 Message-ID: In-Reply-To: <20111117064159.GA26328@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [OPSAWG] network management data models - a rewrite thread-index: Acyk9BAPnQnmVW8JSxWFLYbPwF3OvAAABSKQ References: <20111117041857.GA25801@elstar.local> <20111117064159.GA26328@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:48:33 -0000 Juergen, Text proposals are always welcome. The text needs however include IMO not only information about 'why data models are not organized around FCAPS in the IETF' but also 'text that puts our data models into FCAPS in some level of detail'. Some 'text that is much shorter and remains at a rather abstract level' could work, so, please, send your proposals.=20 Regards, Dan > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Thursday, November 17, 2011 8:42 AM > To: Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] network management data models - a rewrite >=20 > On Thu, Nov 17, 2011 at 07:05:15AM +0100, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > > > It's not only Mehmet and Benoit, it's also me (as contributor and > AD), > > and at least one position expressed in the meeting and also the > silent > > majority in the WG meeting (to be confirmed on the list) that agree > with > > us or do not care. You missed I think that part of the OPSAWG > meeting, > > but what was said and agreed I think (pending on list confirmation) > is > > that the goal of the document or one of its principal goals is to > > provide a view of the IETF data models for NM for external SDOs. Many > of > > those look at management apps via a FCAPS view, and providing both > views > > is equally important. This is the reason for which while agreeing > with > > your view that we must emphasize the way data modeling happens in the > > IETF and explain it, I believe that keeping a minimal but meaningful > > level of presentation of the models through the FCAPS perspective is > > necessary for the participants out of the IETF. >=20 > The text there currently is in my view not suitable to say it > politely. If needed, I can also write a short text explaining why data > models are not organized around FCAPS in the IETF. (There is already > text like that.) If people want text that puts our data models into > FCAPS in some level of detail, you will either produce boring > repetition (as most of our MIB modules do support P and F equally > well) or you have to have text that is much shorter and remains at a > rather abstract level, i.e. data link data models usually support P > and F. >=20 > I am not strictly against having some FCAPS discussion in the document > but the text we currently have is IMHO not suitable. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Nov 16 22:57:29 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB751F0C42 for ; Wed, 16 Nov 2011 22:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 27tSpWfJwOnZ for ; Wed, 16 Nov 2011 22:57:24 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A25311F0C6F for ; Wed, 16 Nov 2011 22:57:23 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAH6vFQC028406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 07:57:15 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAH6vFN3003787; Thu, 17 Nov 2011 07:57:15 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 07:57:03 +0100 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: Thu, 17 Nov 2011 07:57:03 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640301A290@DEMUEXC006.nsn-intra.net> In-Reply-To: <20111117064742.GB26328@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] network management data models - a rewrite Thread-Index: Acyk9NpCFsWlJCF+RMqOxy7CILXotAAAF02A References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> <20111117064742.GB26328@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Christopher LILJENSTOLPE" X-OriginalArrivalTime: 17 Nov 2011 06:57:03.0912 (UTC) FILETIME=[1CCEB280:01CCA4F6] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:57:29 -0000 Before producing text we should use the opportunity of the IETF meeting=20 to talk to each other. Unfortunately the meeting we planned today did not=20 happen. Shorting up the FCAPS-based view to a few lines is not helpful. There is a=20 need for a detailed survey as a guidance for the audience of the document. Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, November 17, 2011 7:48 AM > To: Christopher LILJENSTOLPE > Cc: Ersue, Mehmet (NSN - DE/Munich); opsawg@ietf.org > Subject: Re: [OPSAWG] network management data models - a rewrite >=20 > On Wed, Nov 16, 2011 at 10:25:32PM -0800, Christopher LILJENSTOLPE wrote: >=20 > > To confirm - the temperature check in the room was to include both > > views in the document, as one view may resonate better with > > different communities. I believe that your contribution will be a > > valuable addition to the document, as it stands. If you have some > > specific issues regarding the examples and their suitability, please > > work with the authors on the document, however we need to do so > > quickly. The consensus in the room was to advance the document in > > short order. >=20 > I am trying to work with the authors. I think it is now their turn to > revise their text. (I can also write something about FCAPS myself but > that might not get us closer to a solution acceptable for all of us.) >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From bertietf@bwijnen.net Wed Nov 16 22:58:18 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C80C1F0C42 for ; Wed, 16 Nov 2011 22:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 c5KA7N22Sw-A for ; Wed, 16 Nov 2011 22:58:18 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id D585A11E8083 for ; Wed, 16 Nov 2011 22:58:17 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RQvvJ-0003kS-Vk; Thu, 17 Nov 2011 07:58:15 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-538f.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RQvvJ-0007pE-CE; Thu, 17 Nov 2011 07:58:13 +0100 Message-ID: <4EC4B07F.2000303@bwijnen.net> Date: Thu, 17 Nov 2011 14:58:07 +0800 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christopher LILJENSTOLPE References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> In-Reply-To: <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd485f8ad51fe4e7fccf2968fcc3b5e38e3 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 06:58:18 -0000 I like Juergens contribution. And although I agree that some text on how our stuff relates to FCAPS might be good, I would not dwell on it too much. Bert On 11/17/11 2:25 PM, Christopher LILJENSTOLPE wrote: > If anyone else in the group has a feeling on this topic, please speak up on the list in short order. From j.schoenwaelder@jacobs-university.de Wed Nov 16 23:12:04 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF31F0C87 for ; Wed, 16 Nov 2011 23:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, 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 VgYh9uvLQ762 for ; Wed, 16 Nov 2011 23:12:03 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6CE21F985E for ; Wed, 16 Nov 2011 23:12:03 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8E3220CD2; Thu, 17 Nov 2011 08:12:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JjmHZr-m1Dfl; Thu, 17 Nov 2011 08:12:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41D9A20CCE; Thu, 17 Nov 2011 08:12:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9F1A21BB8909; Thu, 17 Nov 2011 08:11:44 +0100 (CET) Date: Thu, 17 Nov 2011 08:11:44 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20111117071144.GG26328@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Christopher LILJENSTOLPE , opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> <20111117064742.GB26328@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A290@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640301A290@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:12:04 -0000 On Thu, Nov 17, 2011 at 07:57:03AM +0100, Ersue, Mehmet (NSN - DE/Munich) wrote: > Shorting up the FCAPS-based view to a few lines is not > helpful. There is a need for a detailed survey as a guidance for the > audience of the document. One more example: Look at section 4.3 Accounting Management providing a list of different IPFIX information elements. Is that the level of detail you find appropriate? How many of the information elements listed there do you think are important for Accounting Management? Do you propose to have the IEs listed as well in sections 4.1 Fault Management, 4.4 Performance Management, and 4.5 Security Management? If we talk about FCAPS, we will only finish in finite time by staying abstract. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Wed Nov 16 23:14:05 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A194F1F0C88 for ; Wed, 16 Nov 2011 23:14:05 -0800 (PST) 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 L0OfVLFQIS+D for ; Wed, 16 Nov 2011 23:14:04 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 384841F0C54 for ; Wed, 16 Nov 2011 23:14:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=E4gDrwLPpD7tMfUGH7IHkSUjnIaQZv2T9tK6WjBESnRpacj5PDxPpgckGJnwLqTv; 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.55.174.255] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RQwAb-0002ug-QT for opsawg@ietf.org; Thu, 17 Nov 2011 02:14:02 -0500 Message-ID: <003501cca4f8$9e301e20$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20111117041857.GA25801@elstar.local><20111117064159.GA26328@elstar.local> Date: Wed, 16 Nov 2011 23:14:58 -0800 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f1c5670fdb4a236a03fd8bd25bfb5d700350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.174.255 Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:14:05 -0000 Hi - > From: "Romascanu, Dan (Dan)" > To: "Juergen Schoenwaelder" > Cc: > Sent: Wednesday, November 16, 2011 10:48 PM > Subject: Re: [OPSAWG] network management data models - a rewrite ... > Some 'text that is much shorter and remains at > a rather abstract level' could work, so, please, send your proposals. Here's a stab at a beginning: IETF network management data models are not organized in terms of FCAPS. However, one can generally categorize the use cases supported by a given model in those terms. For example, most (but not all) of the use cases one might envision for the VACM MIB are clearly related to security. For other MIBs, things are not necessarily as clear-cut, and the obvious use cases (which are not always documented in the RFCs) may relate to multiple FCAPS aspects. Randy From mehmet.ersue@nsn.com Wed Nov 16 23:42:08 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E5B11E80D8 for ; Wed, 16 Nov 2011 23:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 fg+LlHkmw4hI for ; Wed, 16 Nov 2011 23:42:07 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E98411E814E for ; Wed, 16 Nov 2011 23:42:07 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAH7g1A3010137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 08:42:01 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAH7g1Y9031757; Thu, 17 Nov 2011 08:42:01 +0100 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Nov 2011 08:42:01 +0100 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: Thu, 17 Nov 2011 08:41:59 +0100 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640301A2E6@DEMUEXC006.nsn-intra.net> In-Reply-To: <20111117071144.GG26328@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] network management data models - a rewrite Thread-Index: Acyk+DVNlGHjS4NUTjCsK90kcZ5sqwAA8yOw References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> <20111117064742.GB26328@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A290@DEMUEXC006.nsn-intra.net> <20111117071144.GG26328@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 17 Nov 2011 07:42:01.0176 (UTC) FILETIME=[64808580:01CCA4FC] Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 07:42:08 -0000 > One more example: Look at section 4.3 Accounting Management providing > a list of different IPFIX information elements. Is that the level of > detail you find appropriate? How many of the information elements > listed there do you think are important for Accounting Management? Do > you propose to have the IEs listed as well in sections 4.1 Fault > Management, 4.4 Performance Management, and 4.5 Security Management? I tend to agree that the IPFIX IEs are not needed in this level of detail. Benoit promised to provide an update. Mehmet From bclaise@cisco.com Thu Nov 17 21:00:44 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA9B1F0C74 for ; Thu, 17 Nov 2011 21:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUT9vOMQ+Krj for ; Thu, 17 Nov 2011 21:00:44 -0800 (PST) Received: from av-tac-jap.cisco.com (skinny-sumo.cisco.com [64.104.15.102]) by ietfa.amsl.com (Postfix) with ESMTP id 050FF1F0C40 for ; Thu, 17 Nov 2011 21:00:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from sumo.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-jap.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAI50dLw021639; Fri, 18 Nov 2011 14:00:39 +0900 (JST) Received: from [10.75.233.176] (hkidc-vpn-client-233-176.cisco.com [10.75.233.176]) by sumo.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id pAI50X4O011262; Fri, 18 Nov 2011 14:00:35 +0900 (JST) Message-ID: <4EC5E671.8040005@cisco.com> Date: Fri, 18 Nov 2011 13:00:33 +0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: <20111117041857.GA25801@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A26B@DEMUEXC006.nsn-intra.net> <988EAE3D-D019-4B7C-92EB-A6780DA3D376@asgaard.org> <20111117064742.GB26328@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A290@DEMUEXC006.nsn-intra.net> <20111117071144.GG26328@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640301A2E6@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640301A2E6@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org, Christopher LILJENSTOLPE Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2011 05:00:45 -0000 On 17/11/2011 15:41, Ersue, Mehmet (NSN - DE/Munich) wrote: >> One more example: Look at section 4.3 Accounting Management providing >> a list of different IPFIX information elements. Is that the level of >> detail you find appropriate? How many of the information elements >> listed there do you think are important for Accounting Management? Do >> you propose to have the IEs listed as well in sections 4.1 Fault >> Management, 4.4 Performance Management, and 4.5 Security Management? > I tend to agree that the IPFIX IEs are not needed in this level of > detail. > Benoit promised to provide an update. Yes, I agree too. Let me revisit this section (can't do before end of next week) Regards, Benoit. > > Mehmet > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From ietf@cdl.asgaard.org Tue Nov 22 02:35:11 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F46321F8DCA for ; Tue, 22 Nov 2011 02:35:11 -0800 (PST) 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 HG75aBXMmL3I for ; Tue, 22 Nov 2011 02:35:07 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id 57EDD21F87C5 for ; Tue, 22 Nov 2011 02:35:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 4334291A71F; Tue, 22 Nov 2011 10:35:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1SHejlhTeKF; Tue, 22 Nov 2011 10:34:47 +0000 (UTC) Received: from fenrir.asgaard.org (fenrir.asgaard.org [204.29.150.154]) by asgaard.org (Postfix) with ESMTPSA id 8D22E91A704; Tue, 22 Nov 2011 10:34:47 +0000 (UTC) From: Christopher LILJENSTOLPE Content-Type: multipart/signed; boundary="Apple-Mail=_7D948AD2-DBD6-4667-BA7B-6E1D24A60296"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 22 Nov 2011 02:34:40 -0800 Message-Id: To: opsawg@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Cc: opsawg-chairs@tools.ietf.org Subject: [OPSAWG] Minutes posted X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 10:35:11 -0000 --Apple-Mail=_7D948AD2-DBD6-4667-BA7B-6E1D24A60296 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings all, Thank's to the wonderful note taking of Linda Dunbar, I've been = able to get the notes up in quick order this time. They can be found at = http://www.ietf.org/proceedings/82/minutes/opsawg.html. If you have any = questions, quibbles, nits, or comments, please get them in to myself or = Scott before the 30th of Nov. =20 Thank's, Chris -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_7D948AD2-DBD6-4667-BA7B-6E1D24A60296 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJOy3rGAAoJEGmx2Mt/+Iw/nJMIAJmQ9fUBGJlZOIi5VILSi9Y5 jl7TDlj6KoTum3QEi7gZNTEzdckjqzDxBoGBFitNjkZIlNJdhWpPC9rakxVcS9Oc 7ENl148UH6FgsoSlP/A42SRYIJggrwMgVL2cXBaQ/iqYcnGX4Vq/DqywWRIFlx0b 5mAscnMfkA26s5iVO4Gzm8i6UfDuMT2fUiTvYeepIicdxgDC9F5Ip7YcSEW8zr47 HxOQtM83ZrWpoBoPPLKp/dRd+nsD7HEu/EGnS3qbffsex4CeAA9X3jNwOoAwC4M4 Julz35MnxptTBqi0YxOFKwmt/HoTI4Bgl4FYvoaBxfQl3fKu6hU1IULJkoS22D4= =Od8L -----END PGP SIGNATURE----- --Apple-Mail=_7D948AD2-DBD6-4667-BA7B-6E1D24A60296-- From ietfc@btconnect.com Thu Nov 24 01:26:04 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C282E21F8BA0 for ; Thu, 24 Nov 2011 01:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-1.326, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 LsjZK84hBold for ; Thu, 24 Nov 2011 01:26:04 -0800 (PST) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id EE3F621F8A95 for ; Thu, 24 Nov 2011 01:26:03 -0800 (PST) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr08.btconnect.com with SMTP id FFN87732; Thu, 24 Nov 2011 09:25:57 +0000 (GMT) Message-ID: <002201ccaa82$f75c6640$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Christopher LILJENSTOLPE" , References: Date: Thu, 24 Nov 2011 09:27:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4ECE0DA4.008F, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.24.85119:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __SUBJ_HIGHBIT, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __UTF8_SUBJ, __ANY_URI, __URI_NO_PATH, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_800_899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, BODY_SIZE_1000_LESS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4ECE0DA6.016F,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: opsawg-chairs@tools.ietf.org Subject: Re: [OPSAWG] =?utf-8?q?Minutes_posted_-_RFC=C3=95s?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 09:26:04 -0000 It would be good if the minutes could be in ASCII. I am not sure what code page is in use, but where I expect to see an apostrophe, I see something more like a diacritic mark, and, on at least one PC, I get a capital O with a line over the top, a bit like Icelandic or Norwegian. Likewise, the bullets are sometimes bullets and sometimes ... well, I don't have the language to describe it. Not unintelligible, but hard to read. Tom Petch ----- Original Message ----- From: "Christopher LILJENSTOLPE" To: Cc: Sent: Tuesday, November 22, 2011 11:34 AM Subject: [OPSAWG] Minutes posted > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From ietfc@btconnect.com Thu Nov 24 02:38:35 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BFB21F8C35 for ; Thu, 24 Nov 2011 02:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvMGXDIWi3Rt for ; Thu, 24 Nov 2011 02:38:34 -0800 (PST) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE221F8C04 for ; Thu, 24 Nov 2011 02:38:33 -0800 (PST) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr13.btconnect.com with SMTP id FHA89066; Thu, 24 Nov 2011 10:38:24 +0000 (GMT) Message-ID: <009601ccaa8d$162780a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Romascanu, Dan \(Dan\)" , "Juergen Schoenwaelder" , References: <20111117041857.GA25801@elstar.local> Date: Thu, 24 Nov 2011 10:40:05 +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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4ECE1E9E.00AA, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.11.24.93016:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_CONTACT_NUM, __CP_URI_IN_BODY, __C230066_P5, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4ECE1EA2.0165,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 10:38:35 -0000 ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" ; Sent: Thursday, November 17, 2011 7:05 AM > > It's not only Mehmet and Benoit, it's also me (as contributor and AD), > and at least one position expressed in the meeting and also the silent > majority in the WG meeting (to be confirmed on the list) that agree with > us or do not care. You missed I think that part of the OPSAWG meeting, > but what was said and agreed I think (pending on list confirmation) is > that the goal of the document or one of its principal goals is to > provide a view of the IETF data models for NM for external SDOs. Mmmm Looking at the minutes of the meeting, I would not have known that that was the outcome, but no matter. Writing this doubtless debars me from being in the silent majority, but I do think that FCAPS should be in, as the least bad way of surveying the subject. I started off with a seven topic structure of management, saw that expand to ten and shrink to six and three. Any one would do, but we do need something in that space; FCAPS seems the most likely to be understood. By contrast, saying that IETF MIB modules are not like that is an 'implementation detail'. It is how the IETF has chosen to implement its design in the problem space, and omitting the 'big picture' of the problem space can only reinforce the view that the IETF is something of an oddball. In passing, you could do with a reference for [FCAPS]. Tom Petch Many of > those look at management apps via a FCAPS view, and providing both views > is equally important. This is the reason for which while agreeing with > your view that we must emphasize the way data modeling happens in the > IETF and explain it, I believe that keeping a minimal but meaningful > level of presentation of the models through the FCAPS perspective is > necessary for the participants out of the IETF. > > Dan > > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of Juergen Schoenwaelder > > Sent: Thursday, November 17, 2011 6:19 AM > > To: opsawg@ietf.org > > Subject: [OPSAWG] network management data models - a rewrite > > > > Hi, > > > > draft-ietf-opsawg-management-stds-02 has a section on "Network > > Management Data Models" which is structured around FCAPS which I > happen > > to dislike for several reasons (data model work in the IETF is not > > organized around FCAPS, the discussion is constantly changing > > abstraction levels, some of the examples picked are somewhat > > surprising). To be constructive, I have written a replacement for this > > section that I think better summarizes what the IETF has to offer and > > how data modeling work happens to be done in the IETF. In addition, it > > is also shorter. > > > > I do not mind if my proposed rewrite is followed by a section > > discussing how all this fits into an FCAPS view of the world but such > a > > section should be much shorter and different from what is in the > > current section 4. (For me, a short explanation that the IETF does not > > organize data models around FCAPS is really sufficient but I guess > > Mehmet and Benoit might not agree with that.) > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From leonidas@netmode.ntua.gr Fri Nov 25 03:36:10 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B3C21F8C06 for ; Fri, 25 Nov 2011 03:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBKQeNWfArFd for ; Fri, 25 Nov 2011 03:36:10 -0800 (PST) Received: from ulysses.noc.ntua.gr (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]) by ietfa.amsl.com (Postfix) with ESMTP id C3C4B21F8BFE for ; Fri, 25 Nov 2011 03:36:09 -0800 (PST) Received: from netmode.ece.ntua.gr ([IPv6:2001:648:2000:d:21d:9ff:fe05:33c7]) by ulysses.noc.ntua.gr (8.14.4/8.14.4) with ESMTP id pAPBa8os039133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Nov 2011 13:36:08 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Received: from dhcp-71.netmode.ece.ntua.gr (dhcp-71.netmode.ece.ntua.gr [147.102.13.71]) by netmode.ece.ntua.gr (8.14.4/8.14.3) with ESMTP id pAPBa89L041535; Fri, 25 Nov 2011 13:36:08 +0200 (EET) (envelope-from leonidas@netmode.ntua.gr) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes References: Date: Fri, 25 Nov 2011 13:35:08 +0200 To: opsawg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Leonidas Lymberopoulos" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.50 (Linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (ulysses.noc.ntua.gr [IPv6:2001:648:2000:de::230]); Fri, 25 Nov 2011 13:36:08 +0200 (EET) X-Virus-Scanned: clamav-milter 0.97 at ulysses.noc.ntua.gr X-Virus-Status: Clean Subject: [OPSAWG] (CFP) IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 11:36:10 -0000 ----------------------------------------------------------------------------------------------------- Please accept our apologies if you receive multiple copies of this CfP ----------------------------------------------------------------------------------------------------- IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) ================================================================================== 16 April 2012 Maui, Hawaii, USA http://www.manfi.org CALL FOR PAPERS --------------- The Fourth IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012) will be held in conjunction with IEEE/IFIP NOMS 2012 in Maui, Hawaii, USA, from April 16-20, 2012. The workshop is sponsored by the IEEE Communications Society (ComSoc) and supported by POSTECH ITCE, Ghent University-IBBT, NEC, and Ericsson LM. The workshop is endorsed by the Technical Committee on Network Operations and Management (CNOM). It is widely agreed that, despite its many successes, the current Internet also has a set of systemic problems, ranging from an upcoming shortage of IP addresses to insufficient security. However, the lack of scalable and agile manageability is arguably more important, as without management, it is impossible to build systems that adapt the services and resources offered in a context-dependent manner. In either case (clean slate vs. evolution vs. revolution) we must consider the manageability of the Future Internet from the beginning. Following the success of the three previous editions of this workshop, held in conjunction with IM 2009, NOMS 2010 and IM 2011, ManFI 2012 aims at providing an international forum for researchers in these and similar areas. ManFI 2012 will combine original full paper presentations with a motivating keynote, quick hot topic presentations and a panel discussion to thoroughly explore this challenging topic. Topics of interest ------------------ Authors are invited to submit papers that fall into or are related to the topic areas listed below: - Architectural Issues * Advantages and disadvantages of revolutionary, evolutionary, and other approaches to managing the Future Internet * Separation of data, control, and management planes * Design of architectural building blocks for managing the Future Internet * Advances in measurement, management, security, accounting, mobility, and other functions * Virtualization of resources and services * Dynamic composition of management and operational functionality * Mechanisms for managing interconnected computational infrastructures (e.g. elastic clouds, federated clouds) in the Future Internet * Implications of social network success on the Future Internet architecture - Design and Implementation Issues * Abstractions for programmable network elements * Accommodating context-awareness in management * Applying situation awareness to network management * Federation between administrative domains and support of all constituencies * The role of models, ontologies, and other knowledge abstractions in the Future Internet * Uncertainty and probabilistic approaches to management of the Future Internet * Approaches for the organization of management data, data analytics and visualization * Experience reports from Future Internet experimental facilities set-up and results - Economic Issues * Economic aspects driving the deployment of Future Internet management technology * Economic opportunities and challenges for management technology * Experience reports from management in test beds Paper submission ---------------- Paper submissions must present original, research or experiences. Late-breaking advances and work-in-progress reports from ongoing research are also encouraged. Only original papers that have not been published or submitted for publication elsewhere can be submitted. Each submission must be written in English, accompanied by a 75 to 200 word abstract that clearly outlines the scope and contributions of the paper, and a list of up to 5 key words. There is a length limitation of 6 pages (including title, abstract, all figures, tables, and references) for regular conference papers, and 4 pages for short papers. Submissions must be in IEEE 2-column style. Papers exceeding these limits, multiple submissions, and self-plagiarized papers will be rejected without further review. Authors should submit their papers in PDF, postscript, or Word formats via JEMS: (https://submissoes.sbc.org.br/). Proceedings ----------- Papers accepted for ManFI 2012 will be included in the conference proceedings, IEEE Xplore, and EI Index. The IEEE reserves the right to remove any paper from IEEE Xplore if the paper is not presented at the workshop. Awards will be presented to the best paper and to the best student paper at the workshop. Furthermore, we plan to work with a leading journal, such as JNSM, TNSM and IJNM, to solicit extended versions of the best papers of ManFI 2012 to be submitted for review. Workshop Co-Chairs ------------------ - Prof. James Won-Ki Hong, POSTECH, Korea - Prof. Filip De Turck, Ghent University - IBBT, Belgium - Dr. Yoshiaki Kiriha, NEC, Japan - Dr. Sven van der Meer, Ericsson LM, Ireland Publicity Co-Chairs ------------------- - Leonidas Lymberopoulos, National Technical University of Athens, Greece - Cathryn Peoples, University of Ulster, UK Important dates --------------- - Abstract registration deadline: December 14, 2011 - Paper submission: December 20, 2011 - Notification of acceptance: January 31, 2012 - Final version of papers due: February 15, 2012 - Workshop date: April 16, 2012 For more information, please contact one of the Workshop Co-Chairs at tpcchairs@manfi2012.org From bclaise@cisco.com Fri Nov 25 09:07:21 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93FF21F88B6 for ; Fri, 25 Nov 2011 09:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 XpagLam-1wQM for ; Fri, 25 Nov 2011 09:07:20 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DA94921F85F2 for ; Fri, 25 Nov 2011 09:07:19 -0800 (PST) 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 pAPGxEwi019204 for ; Fri, 25 Nov 2011 17:59:14 +0100 (CET) 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 pAPGxDob017594 for ; Fri, 25 Nov 2011 17:59:13 +0100 (CET) Message-ID: <4ECFC961.4030708@cisco.com> Date: Fri, 25 Nov 2011 17:59:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> In-Reply-To: <20111117041857.GA25801@elstar.local> Content-Type: multipart/alternative; boundary="------------080508000403060707080403" Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 17:07:21 -0000 This is a multi-part message in MIME format. --------------080508000403060707080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Juergen, Thanks for your contribution. Here is some feedback: On 25/11/2011 17:31, Benoit Claise wrote: > * Network Management Data Models > > The data models defined by the IETF can be broadly classified into > the following categories depicted in Figure X. > > +-----------+ +-------------------------------+ +-----------+ > | | | application layer data models | | network | > | generic | +-------------------------------+ | management| > | infra- | | transport layer data models | | infra- | > | structure | +-------------------------------+ | structure | > | data | | network layer data models | | data | > | models | +-------------------------------+ | models | > | | | link layer data models | | | > +-----------+ +-------------------------------+ +-----------+ > > Figure X: Categories of network management data models > > Each of the categories is briefly described below. Note that the > classification used here intends to provide orientation and reflects > how most data models have been developed in the IETF by the various > working groups. It is not a goal of this classification to easily and > correctly classify all data models that have been defined by the IETF > so far. The network layering model in the middle of Figure X follows > the four layer model of the Internet as defined in [RFC1021]. > > There are many technology-specific IETF data models which are not > mentioned in this document but can be found at [RFCSEARCH]. > > * Generic Infrastructure Data Models > > Generic infrastructure data models provide core abstractions that > many other data models built upon. The most important of these is > the interfaces data model defined in the IF-MIB [RFC2863]. It > provides the basic notion of network interfaces and it allows to > express stacking/layering relationships between interfaces. The > interfaces data model also provides basic monitoring objects that > are widely used for performance and fault management. > > The second important infrastructure data model is defined in the > Entity MIB [RFC4133]. It exports the containment hierarchy of the > physical entities (slots, modules, ports) that make up a networking > device and as such it is a key data model for inventory management. > Physical entities can have pointers to other data models that > provide more specific information about a physical entity (e.g. > physical ports usually point to the related network interface). > Entity MIB extensions exist for physical sensors such as temperature > sensors embedded on line cards or sensors that report fan rotation > speeds [RFC3433]. BC> I would not mention this ENTITY-MIB extension about sensor. To the audience, it might seem that we have master the Internet of Things with SNMP, which is not correct at all! > Another extension models states and alarms of > physical entities [RFC4268]. Some vendors have extended the basic > Entity MIB with several proprietary data models. > > * Link Layer Data Models > > A number of data models exist in the form of MIB modules covering > the link layers IP runs over, such as ADSL [RFC4706], VDSL > [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606], > Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318, > RFC4363]. These so called transmission data models typically extend > the generic network interfaces data model with interface type > specific information. Most of the link layer data models focus on > monitoring capabilities that can be used for performance and fault > management functions and to some lesser extend for accounting and > security management functions. The IEEE has meanwhile taken over the > responsibility to maintain and further develop data models for the > IEEE 802 family of protocols [RFC4663]. The cable modem industry > consortium DOCSIS is working with the IETF to publish data models > for cable modem networks as IETF standards-track specifications. > > * Network Layer Data Models > > There are data models in the form of MIB modules covering IP/ICMP > [RFC4293, RFC4292] network protocols and their extensions (e.g., > mobile IP), the core protocols of the Internet. In addition, there > are data models covering popular unicast routing protocols (OSPF > [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing > protocols (PIM [RFC5060]). > > Detailed models also exist for performance measurements in the form > of IP performance metrics [RFC2330]. IP performance metrics include > the definition of measurement methodologies with the goal to produce > repeatable and comparable measurement results. There is a growing > number of metrics defined for measuring loss, delay, connectivity, > etc. > > The necessary data model infrastructure for configuration data > models covering network layers are currently being defined using > NETCONF and YANG. > > * Transport Layer Data Models > > There are data models for the transport protocols TCP [RFC4022], UDP > [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing > extended statistics is defined as well [RFC4898]. > > * Application Layer Data Models > > Some data models have been developed for specific application > protocols (e.g., SIP [RFC4780]). In addition, there are data models > that provide a generic infrastructure for instrumenting applications > in order to obtain data useful primarily for performance management > and fault management [RFC2287, RFC2564]. In general, however, > generic application MIB modules have been less successful in gaining > wide-spread deployment. > > * Network Management Infrastructure Data Models > > A number of data models are concerned with the network management > system itself. This includes, in addition to a set of SNMP MIB > modules for monitoring and configuring SNMP itself [RFC3410], some > MIB modules providing generic functions such as the calculation of > expressions over MIB objects, generic functions for thresholding and > event generation, event notification logging functions and data > models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In > addition, there are data models that allow to execute basic > reachability and path discovery tests [RFC4560]. Another collection > of MIB modules provides remote monitoring functions, ranging from > the data link layer up to the application layer. This is known as > the RMON family of MIB modules [RFC3577]. > > The IPFIX protocol [RFC5101] is used to export information about > network flows collected at so called observation points (typically a > network interface). The information elements [RFC5102] carried in > IPFIX cover the network and transport layer very well but also > provides some link layer specific information elements. Work is > underway to further extend the standardized information that can be > carried in IPFIX. Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already exists as a reference in the draft. Also add the following sentence "For example, the information element extension for packet sampling is specified in the the "information model for packet sampling reports" [RFC5477] > > The SYSLOG protocol document [RFC5424] defines an initial set of > Structured Data Elements (SDEs) that relate to content time quality, > content origin, and meta-information about the message, such as > language. Proprietary SDEs can be used to supplement the IETF- > defined SDEs. > I guess that we should say a few words about RADIUS and Diameter TLV/AVP in this " Network Management Infrastructure Data Models " section. This way we would cover all entries (except CAPWAP) from "Table 5: Data Models and their Extensibility" Regards, Benoit. > Hi, > > draft-ietf-opsawg-management-stds-02 has a section on "Network > Management Data Models" which is structured around FCAPS which I > happen to dislike for several reasons (data model work in the IETF is > not organized around FCAPS, the discussion is constantly changing > abstraction levels, some of the examples picked are somewhat > surprising). To be constructive, I have written a replacement for this > section that I think better summarizes what the IETF has to offer and > how data modeling work happens to be done in the IETF. In addition, it > is also shorter. > > I do not mind if my proposed rewrite is followed by a section > discussing how all this fits into an FCAPS view of the world but such > a section should be much shorter and different from what is in the > current section 4. (For me, a short explanation that the IETF does not > organize data models around FCAPS is really sufficient but I guess > Mehmet and Benoit might not agree with that.) > > /js > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --------------080508000403060707080403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Juergen,

Thanks for your contribution.
Here is some feedback:
On 25/11/2011 17:31, Benoit Claise wrote:
* Network Management Data Models

The data models defined by the IETF can be broadly classified into
the following categories depicted in Figure X.

  +-----------+  +-------------------------------+  +-----------+
  |           |  | application layer data models |  |  network  |
  |  generic  |  +-------------------------------+  | management|
  |  infra-   |  |  transport layer data models  |  |  infra-   |
  | structure |  +-------------------------------+  | structure |
  |   data    |  |   network layer data models   |  |   data    |
  |  models   |  +-------------------------------+  |  models   |
  |           |  |    link layer data models     |  |           |
  +-----------+  +-------------------------------+  +-----------+

  Figure X: Categories of network management data models

Each of the categories is briefly described below. Note that the
classification used here intends to provide orientation and reflects
how most data models have been developed in the IETF by the various
working groups. It is not a goal of this classification to easily and
correctly classify all data models that have been defined by the IETF
so far. The network layering model in the middle of Figure X follows
the four layer model of the Internet as defined in [RFC1021].

There are many technology-specific IETF data models which are not
mentioned in this document but can be found at [RFCSEARCH].

* Generic Infrastructure Data Models

  Generic infrastructure data models provide core abstractions that
  many other data models built upon. The most important of these is
  the interfaces data model defined in the IF-MIB [RFC2863]. It
  provides the basic notion of network interfaces and it allows to
  express stacking/layering relationships between interfaces. The
  interfaces data model also provides basic monitoring objects that
  are widely used for performance and fault management.

  The second important infrastructure data model is defined in the
  Entity MIB [RFC4133]. It exports the containment hierarchy of the
  physical entities (slots, modules, ports) that make up a networking
  device and as such it is a key data model for inventory management.
  Physical entities can have pointers to other data models that
  provide more specific information about a physical entity (e.g.
  physical ports usually point to the related network interface).
  Entity MIB extensions exist for physical sensors such as temperature
  sensors embedded on line cards or sensors that report fan rotation
  speeds [RFC3433].
BC> I would not mention this ENTITY-MIB extension about sensor. To the audience, it might seem that we have master the Internet of Things with SNMP, which is not correct at all!

Another extension models states and alarms of
  physical entities [RFC4268]. Some vendors have extended the basic
  Entity MIB with several proprietary data models.

* Link Layer Data Models

  A number of data models exist in the form of MIB modules covering
  the link layers IP runs over, such as ADSL [RFC4706], VDSL
  [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606],
  Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318,
  RFC4363]. These so called transmission data models typically extend
  the generic network interfaces data model with interface type
  specific information. Most of the link layer data models focus on
  monitoring capabilities that can be used for performance and fault
  management functions and to some lesser extend for accounting and
  security management functions. The IEEE has meanwhile taken over the
  responsibility to maintain and further develop data models for the
  IEEE 802 family of protocols [RFC4663]. The cable modem industry
  consortium DOCSIS is working with the IETF to publish data models
  for cable modem networks as IETF standards-track specifications.

* Network Layer Data Models

  There are data models in the form of MIB modules covering IP/ICMP
  [RFC4293, RFC4292] network protocols and their extensions (e.g.,
  mobile IP), the core protocols of the Internet. In addition, there
  are data models covering popular unicast routing protocols (OSPF
  [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing
  protocols (PIM [RFC5060]).

  Detailed models also exist for performance measurements in the form
  of IP performance metrics [RFC2330]. IP performance metrics include
  the definition of measurement methodologies with the goal to produce
  repeatable and comparable measurement results. There is a growing
  number of metrics defined for measuring loss, delay, connectivity,
  etc.

  The necessary data model infrastructure for configuration data
  models covering network layers are currently being defined using
  NETCONF and YANG.

* Transport Layer Data Models

  There are data models for the transport protocols TCP [RFC4022], UDP
  [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing
  extended statistics is defined as well [RFC4898].

* Application Layer Data Models

  Some data models have been developed for specific application
  protocols (e.g., SIP [RFC4780]). In addition, there are data models
  that provide a generic infrastructure for instrumenting applications
  in order to obtain data useful primarily for performance management
  and fault management [RFC2287, RFC2564]. In general, however,
  generic application MIB modules have been less successful in gaining
  wide-spread deployment.

* Network Management Infrastructure Data Models

  A number of data models are concerned with the network management
  system itself. This includes, in addition to a set of SNMP MIB
  modules for monitoring and configuring SNMP itself [RFC3410], some
  MIB modules providing generic functions such as the calculation of
  expressions over MIB objects, generic functions for thresholding and
  event generation, event notification logging functions and data
  models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In
  addition, there are data models that allow to execute basic
  reachability and path discovery tests [RFC4560].  Another collection
  of MIB modules provides remote monitoring functions, ranging from
  the data link layer up to the application layer. This is known as
  the RMON family of MIB modules [RFC3577].

  The IPFIX protocol [RFC5101] is used to export information about
  network flows collected at so called observation points (typically a
  network interface). The information elements [RFC5102] carried in
  IPFIX cover the network and transport layer very well but also
  provides some link layer specific information elements. Work is
  underway to further extend the standardized information that can be
  carried in IPFIX.
Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already exists as a reference in the draft.

Also add the following sentence "For example, the information element extension for packet sampling is
specified in the the "information model for packet sampling reports" [RFC5477]

  The SYSLOG protocol document [RFC5424] defines an initial set of
  Structured Data Elements (SDEs) that relate to content time quality,
  content origin, and meta-information about the message, such as
  language. Proprietary SDEs can be used to supplement the IETF-
  defined SDEs.

I guess that we should say a few words about RADIUS and Diameter TLV/AVP in this " Network Management Infrastructure Data Models " section.
This way we would cover all entries (except CAPWAP) from "Table 5: Data Models and their Extensibility"

Regards, Benoit.

Hi,

draft-ietf-opsawg-management-stds-02 has a section on "Network
Management Data Models" which is structured around FCAPS which I
happen to dislike for several reasons (data model work in the IETF is
not organized around FCAPS, the discussion is constantly changing
abstraction levels, some of the examples picked are somewhat
surprising). To be constructive, I have written a replacement for this
section that I think better summarizes what the IETF has to offer and
how data modeling work happens to be done in the IETF. In addition, it
is also shorter.

I do not mind if my proposed rewrite is followed by a section
discussing how all this fits into an FCAPS view of the world but such
a section should be much shorter and different from what is in the
current section 4. (For me, a short explanation that the IETF does not
organize data models around FCAPS is really sufficient but I guess
Mehmet and Benoit might not agree with that.)


/js




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

--------------080508000403060707080403-- From j.schoenwaelder@jacobs-university.de Fri Nov 25 11:44:19 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0821F8B54 for ; Fri, 25 Nov 2011 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.195 X-Spam-Level: X-Spam-Status: No, score=-103.195 tagged_above=-999 required=5 tests=[AWL=0.054, 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 PlMKoW5hMsIF for ; Fri, 25 Nov 2011 11:44:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 917BD21F8B5C for ; Fri, 25 Nov 2011 11:44:18 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 815A220CD2; Fri, 25 Nov 2011 20:44:17 +0100 (CET) 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 B6VKqxD3RJXh; Fri, 25 Nov 2011 20:44:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A39120CCF; Fri, 25 Nov 2011 20:44:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D951D1BE4D1C; Fri, 25 Nov 2011 20:43:57 +0100 (CET) Date: Fri, 25 Nov 2011 20:43:57 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20111125194355.GA17736@elstar.local> Mail-Followup-To: Benoit Claise , opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> <4ECFC961.4030708@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ECFC961.4030708@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 19:44:20 -0000 On Fri, Nov 25, 2011 at 05:59:13PM +0100, Benoit Claise wrote: > > The second important infrastructure data model is defined in the > > Entity MIB [RFC4133]. It exports the containment hierarchy of the > > physical entities (slots, modules, ports) that make up a networking > > device and as such it is a key data model for inventory management. > > Physical entities can have pointers to other data models that > > provide more specific information about a physical entity (e.g. > > physical ports usually point to the related network interface). > > Entity MIB extensions exist for physical sensors such as temperature > > sensors embedded on line cards or sensors that report fan rotation > > speeds [RFC3433]. > BC> I would not mention this ENTITY-MIB extension about sensor. To > the audience, it might seem that we have master the Internet of > Things with SNMP, which is not correct at all! You mentioned this earlier and this is why I wrote text that is more specific: "physical sensors such as temperature sensors embedded on line cards or sensors that report fan rotation speeds". If people still misunderstand this because they are only used to scan for keywords and then make up their own story I think we can't help. > >Another extension models states and alarms of > > physical entities [RFC4268]. Some vendors have extended the basic > > Entity MIB with several proprietary data models. > > > >* Link Layer Data Models > > > > A number of data models exist in the form of MIB modules covering > > the link layers IP runs over, such as ADSL [RFC4706], VDSL > > [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515, RFC3606], > > Cable Modems [RFC4546] or Ethernet [RFC4188, RFC4318, > > RFC4363]. These so called transmission data models typically extend > > the generic network interfaces data model with interface type > > specific information. Most of the link layer data models focus on > > monitoring capabilities that can be used for performance and fault > > management functions and to some lesser extend for accounting and > > security management functions. The IEEE has meanwhile taken over the > > responsibility to maintain and further develop data models for the > > IEEE 802 family of protocols [RFC4663]. The cable modem industry > > consortium DOCSIS is working with the IETF to publish data models > > for cable modem networks as IETF standards-track specifications. > > > >* Network Layer Data Models > > > > There are data models in the form of MIB modules covering IP/ICMP > > [RFC4293, RFC4292] network protocols and their extensions (e.g., > > mobile IP), the core protocols of the Internet. In addition, there > > are data models covering popular unicast routing protocols (OSPF > > [RFC4750], ISIS [RFC4444], BGP-4 [RFC4273]) and multicast routing > > protocols (PIM [RFC5060]). > > > > Detailed models also exist for performance measurements in the form > > of IP performance metrics [RFC2330]. IP performance metrics include > > the definition of measurement methodologies with the goal to produce > > repeatable and comparable measurement results. There is a growing > > number of metrics defined for measuring loss, delay, connectivity, > > etc. > > > > The necessary data model infrastructure for configuration data > > models covering network layers are currently being defined using > > NETCONF and YANG. > > > >* Transport Layer Data Models > > > > There are data models for the transport protocols TCP [RFC4022], UDP > > [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing > > extended statistics is defined as well [RFC4898]. > > > >* Application Layer Data Models > > > > Some data models have been developed for specific application > > protocols (e.g., SIP [RFC4780]). In addition, there are data models > > that provide a generic infrastructure for instrumenting applications > > in order to obtain data useful primarily for performance management > > and fault management [RFC2287, RFC2564]. In general, however, > > generic application MIB modules have been less successful in gaining > > wide-spread deployment. > > > >* Network Management Infrastructure Data Models > > > > A number of data models are concerned with the network management > > system itself. This includes, in addition to a set of SNMP MIB > > modules for monitoring and configuring SNMP itself [RFC3410], some > > MIB modules providing generic functions such as the calculation of > > expressions over MIB objects, generic functions for thresholding and > > event generation, event notification logging functions and data > > models to represent alarms [RFC2981, RFC2982, RFC3014, RFC3877]. In > > addition, there are data models that allow to execute basic > > reachability and path discovery tests [RFC4560]. Another collection > > of MIB modules provides remote monitoring functions, ranging from > > the data link layer up to the application layer. This is known as > > the RMON family of MIB modules [RFC3577]. > > > > The IPFIX protocol [RFC5101] is used to export information about > > network flows collected at so called observation points (typically a > > network interface). The information elements [RFC5102] carried in > > IPFIX cover the network and transport layer very well but also > > provides some link layer specific information elements. Work is > > underway to further extend the standardized information that can be > > carried in IPFIX. > Let's add a reference to [IPFIX-IANA]. Note: [IPFIX-IANA] already > exists as a reference in the draft. > > Also add the following sentence "For example, the information > element extension for packet sampling is > specified in the the "information model for packet sampling reports" > [RFC5477] Fine. > > The SYSLOG protocol document [RFC5424] defines an initial set of > > Structured Data Elements (SDEs) that relate to content time quality, > > content origin, and meta-information about the message, such as > > language. Proprietary SDEs can be used to supplement the IETF- > > defined SDEs. > > > I guess that we should say a few words about RADIUS and Diameter > TLV/AVP in this " Network Management Infrastructure Data Models " > section. > This way we would cover all entries (except CAPWAP) from "Table 5: > Data Models and their Extensibility" I am less familiar with their AVPs and how to summarize them. I agree that they should be mentioned - would be great is someone can propose text. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bclaise@cisco.com Mon Nov 28 02:44:34 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0515F21F8B03 for ; Mon, 28 Nov 2011 02:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.302 X-Spam-Level: ** X-Spam-Status: No, score=2.302 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MANGLED_ONLINE=2.3] 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 LJRDc4w5sdt4 for ; Mon, 28 Nov 2011 02:44:33 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB6521F8CEA for ; Mon, 28 Nov 2011 02:44:33 -0800 (PST) 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 pASAiWkr026745 for ; Mon, 28 Nov 2011 11:44:32 +0100 (CET) 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 pASAiV9Q020914 for ; Mon, 28 Nov 2011 11:44:31 +0100 (CET) Message-ID: <4ED3660F.2070309@cisco.com> Date: Mon, 28 Nov 2011 11:44:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <20111117041857.GA25801@elstar.local> <4ECFC961.4030708@cisco.com> <20111125194355.GA17736@elstar.local> In-Reply-To: <20111125194355.GA17736@elstar.local> Content-Type: multipart/alternative; boundary="------------070304030507060309090406" Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 10:44:34 -0000 This is a multi-part message in MIME format. --------------070304030507060309090406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Juergen, > On Fri, Nov 25, 2011 at 05:59:13PM +0100, Benoit Claise wrote: > >>> The second important infrastructure data model is defined in the >>> Entity MIB [RFC4133]. It exports the containment hierarchy of the >>> physical entities (slots, modules, ports) that make up a networking >>> device and as such it is a key data model for inventory management. >>> Physical entities can have pointers to other data models that >>> provide more specific information about a physical entity (e.g. >>> physical ports usually point to the related network interface). >>> Entity MIB extensions exist for physical sensors such as temperature >>> sensors embedded on line cards or sensors that report fan rotation >>> speeds [RFC3433]. >> BC> I would not mention this ENTITY-MIB extension about sensor. To >> the audience, it might seem that we have master the Internet of >> Things with SNMP, which is not correct at all! > You mentioned this earlier and this is why I wrote text that is more > specific: "physical sensors such as temperature sensors embedded on > line cards or sensors that report fan rotation speeds". If people > still misunderstand this because they are only used to scan for > keywords and then make up their own story I think we can't help. > Ok, I give up. Fine with your text. For a draft that is supposed to educate about IETF OPS, promote it, and at the end ease our OPS lives (*), not sure why it became so sensitive.... (*) For example, this draft was mentioned as a potential solution for the "Next Generation Mobile Networks (NGMN) requirements on Next Generation Converged Operations Requirements (NGCOR)" liaison presentation during the last IETF opsarea meeting. Busy now improving the FCAPS sections. Regards, Benoit. --------------070304030507060309090406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Juergen, 
On Fri, Nov 25, 2011 at 05:59:13PM +0100, Benoit Claise wrote:


 The second important infrastructure data model is defined in the
 Entity MIB [RFC4133]. It exports the containment hierarchy of the
 physical entities (slots, modules, ports) that make up a networking
 device and as such it is a key data model for inventory management.
 Physical entities can have pointers to other data models that
 provide more specific information about a physical entity (e.g.
 physical ports usually point to the related network interface).
 Entity MIB extensions exist for physical sensors such as temperature
 sensors embedded on line cards or sensors that report fan rotation
 speeds [RFC3433].

BC> I would not mention this ENTITY-MIB extension about sensor. To
the audience, it might seem that we have master the Internet of
Things with SNMP, which is not correct at all!

You mentioned this earlier and this is why I wrote text that is more
specific: "physical sensors such as temperature sensors embedded on
line cards or sensors that report fan rotation speeds". If people
still misunderstand this because they are only used to scan for
keywords and then make up their own story I think we can't help.
Ok, I give up. Fine with your text.

For a draft that is supposed to educate about IETF OPS, promote it, and at the end ease our OPS lives (*), not sure why it became so sensitive....

(*) For example, this draft was mentioned as a potential solution for  the "Next Generation Mobile Networks (NGMN) requirements on Next Generation Converged Operations Requirements (NGCOR)" liaison presentation during the last IETF opsarea meeting.

Busy now improving the FCAPS sections.

Regards, Benoit. --------------070304030507060309090406-- From dromasca@avaya.com Mon Nov 28 06:45:48 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6921F8BF7 for ; Mon, 28 Nov 2011 06:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.998 X-Spam-Level: X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 svibceJM7mQD for ; Mon, 28 Nov 2011 06:45:47 -0800 (PST) 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 E0C4A21F87D9 for ; Mon, 28 Nov 2011 06:45:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAF2d007GmAcF/2dsb2JhbABDgk2oMYEFgXIBAQEBAxIKEQNZAgEIDQEHDQYMCwEGAUURAQEEARIIGqMHm0WJf2MEmiqMLA X-IronPort-AV: E=Sophos;i="4.69,584,1315195200"; d="scan'208,217";a="316737004" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Nov 2011 09:45:44 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Nov 2011 09:43:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCADDC.67AA0911" Date: Mon, 28 Nov 2011 15:45:42 +0100 Message-ID: In-Reply-To: <4ECFC961.4030708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] network management data models - a rewrite Thread-Index: AcyrlLblVpLCzC9wTsi6kvLSPctYIgCRzqrA References: <20111117041857.GA25801@elstar.local> <4ECFC961.4030708@cisco.com> From: "Romascanu, Dan (Dan)" To: "Benoit Claise" , Subject: Re: [OPSAWG] network management data models - a rewrite X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:45:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCADDC.67AA0911 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 One comment on Benoit's comment:=20 =20 =20 =20 =20 From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Benoit Claise The second important infrastructure data model is defined in the=20 Entity MIB [RFC4133]. It exports the containment hierarchy of the=20 physical entities (slots, modules, ports) that make up a networking=20 device and as such it is a key data model for inventory management.=20 Physical entities can have pointers to other data models that=20 provide more specific information about a physical entity (e.g.=20 physical ports usually point to the related network interface).=20 Entity MIB extensions exist for physical sensors such as temperature=20 sensors embedded on line cards or sensors that report fan rotation=20 speeds [RFC3433].=20 BC> I would not mention this ENTITY-MIB extension about sensor. To the audience, it might seem that we have master the Internet of Things with SNMP, which is not correct at all! Another extension models states and alarms of=20 physical entities [RFC4268]. Some vendors have extended the basic=20 Entity MIB with several proprietary data models.=20 [[DR]] I respectfully disagree with Benoit's comment. There is not claim that 'we have mastered the IoT management', just an example of the way the Entity MIB can be used and extended to represent information from physical sensors, followed by another example about alarms. I would rather leave them as written by Juergen.=20 =20 Dan (speaking as contributor) =20 ------_=_NextPart_001_01CCADDC.67AA0911 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

One comment on Benoit’s comment:

 

 

 

 

From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of Benoit Claise

  The second important infrastructure data model = is defined in the
  Entity MIB [RFC4133]. It exports the = containment hierarchy of the
  physical entities (slots, = modules, ports) that make up a networking
  device and as such = it is a key data model for inventory management.
  Physical = entities can have pointers to other data models that
  provide = more specific information about a physical entity (e.g.
  = physical ports usually point to the related network interface). =
  Entity MIB extensions exist for physical sensors such as = temperature
  sensors embedded on line cards or sensors that = report fan rotation
  speeds [RFC3433].

BC> I would not mention this ENTITY-MIB extension = about sensor. To the audience, it might seem that we have master the = Internet of Things with SNMP, which is not correct at = all!


Another extension = models states and alarms of
  physical entities [RFC4268]. Some = vendors have extended the basic
  Entity MIB with several = proprietary data models.


[[DR]] I respectfully disagree with Benoit’s comment. There is = not claim that ‘we have mastered the IoT management’, just = an example of the way the Entity MIB can be used and extended to = represent information from physical sensors, followed by another example = about alarms. I would rather leave them as written by Juergen. =

 

Dan

(speaking as contributor)

 

------_=_NextPart_001_01CCADDC.67AA0911-- From wesley.george@twcable.com Mon Nov 28 12:25:25 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA81C1F0C83 for ; Mon, 28 Nov 2011 12:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 u4scDl6O99am for ; Mon, 28 Nov 2011 12:25:25 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9DA1F0C35 for ; Mon, 28 Nov 2011 12:25:25 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,585,1315195200"; d="scan'208";a="287393422" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Nov 2011 15:16:27 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 28 Nov 2011 15:22:09 -0500 From: "George, Wes" To: Juergen Schoenwaelder , Kent Watsen Date: Mon, 28 Nov 2011 15:22:08 -0500 Thread-Topic: review draft-ietf-opsawg-automated-network-configuration-02 Thread-Index: AcypBg+4xZjDlcecQjS3et2oJzC6bgFARhfw Message-ID: References: <20111122110055.GA94266@elstar.local> In-Reply-To: <20111122110055.GA94266@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: "opsawg@ietf.org" Subject: Re: [OPSAWG] review draft-ietf-opsawg-automated-network-configuration-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 20:25:26 -0000 As requested, I've reviewed the changes between -01 and -02. Most of my con= cerns from my previous message (http://www.ietf.org/mail-archive/web/opsawg= /current/msg01756.html) have been addressed, with two exceptions: First, the introduction and later sections still do not provide a clear exp= lanation of the gaps and issues associated with CAPWAP, NETCONF/YANG, and t= he cited BBF/3GPP standards. The current intro section ends abruptly with s= everal surveys of different existing protocols without making it clear why = those are inadequate. It may be that this is more left for a follow-on docu= ment (a formal gap analysis, perhaps), but that's worth stating explicitly.= Otherwise, I'd recommend at least some explanation of why the existing eff= orts are not enough, thus necessitating this problem statement. It's discussed somewhat in section 6, but I think some linking text in the = intro would be helpful. Second, there is still no discussion of anycast as a potential solution for= 5.3 (config server discovery), either why it would work or why it would no= t. I would think that this would be significantly less brittle than preconf= iguring a standard IP address or a URI, because typically anycast routing c= an use route scoping to manage where traffic destined for that IP block is = sent, and a well-known address doesn't suffer from the same inflexibility t= hat using a provider-address or a hard-coded private address might create. Thanks, Wes > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > Sent: Tuesday, November 22, 2011 6:01 AM > To: Kent Watsen; George, Wes > Cc: opsawg-chairs@tools.ietf.org > Subject: review draft-ietf-opsawg-automated-network-configuration-02 > > Hi, > > your comments on the -01 version have led to a new revision of this > document: > > http://tools.ietf.org/html/draft-ietf-opsawg-automated-network- > configuration-02 > > It would be helpful if you can review the changes and let the WG know > whether you are happy with the edits or detail which changes you think > should still be done. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From j.schoenwaelder@jacobs-university.de Tue Nov 29 03:55:54 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4220D21F8C14 for ; Tue, 29 Nov 2011 03:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=0.382, 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 ZbZ-NZU-1fT2 for ; Tue, 29 Nov 2011 03:55:53 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4A16821F8BD5 for ; Tue, 29 Nov 2011 03:55:53 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C28D20C58; Tue, 29 Nov 2011 12:55:52 +0100 (CET) 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 JSsDstCbarFj; Tue, 29 Nov 2011 12:55:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B138E20C8E; Tue, 29 Nov 2011 12:55:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CAE4B1BE87F8; Tue, 29 Nov 2011 12:55:33 +0100 (CET) Date: Tue, 29 Nov 2011 12:55:33 +0100 From: Juergen Schoenwaelder To: "George, Wes" Message-ID: <20111129115533.GB30681@elstar.local> Mail-Followup-To: "George, Wes" , Kent Watsen , "opsawg@ietf.org" References: <20111122110055.GA94266@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review draft-ietf-opsawg-automated-network-configuration-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 11:55:54 -0000 On Mon, Nov 28, 2011 at 03:22:08PM -0500, George, Wes wrote: > As requested, I've reviewed the changes between -01 and -02. Most of my concerns from my previous message (http://www.ietf.org/mail-archive/web/opsawg/current/msg01756.html) have been addressed, with two exceptions: > > First, the introduction and later sections still do not provide a clear explanation of the gaps and issues associated with CAPWAP, NETCONF/YANG, and the cited BBF/3GPP standards. The current intro section ends abruptly with several surveys of different existing protocols without making it clear why those are inadequate. It may be that this is more left for a follow-on document (a formal gap analysis, perhaps), but that's worth stating explicitly. Otherwise, I'd recommend at least some explanation of why the existing efforts are not enough, thus necessitating this problem statement. > It's discussed somewhat in section 6, but I think some linking text in the intro would be helpful. I will draft some text to address this but I need to check some of the specs again to get this right. > Second, there is still no discussion of anycast as a potential solution for 5.3 (config server discovery), either why it would work or why it would not. I would think that this would be significantly less brittle than preconfiguring a standard IP address or a URI, because typically anycast routing can use route scoping to manage where traffic destined for that IP block is sent, and a well-known address doesn't suffer from the same inflexibility that using a provider-address or a hard-coded private address might create. My understanding of IP anycast is that - it works well if there is service that is highly replicated and every (replicated) server provides the same service (the common example seems to be DNS) - it works well for short (ideally stateless) transactions where the impact of disruptions due to routing updates is small - to work with BGP (that is the interdomain scenario), one typically needs to allocate a /24 prefix for a service in the case of IPv4 (which is kind of costly); for interior routing protocols, a host route might work Section 5.3. talks about the problem of locating the configuration server of a device. To use IP anycasts, one would need to preconfigure IP anycast addresses or prefixes and we would then need servers that provide redirection services for all devices being deployed. However, a device at the end needs to find "it's" configuration server not an arbitrary configuration server and hence I do not see how IP anycasts would work in an inter-domain scenario unless the anycast servers all can provide the same redirection service. It is likely that I am missing something basic, please let me know if this is the case. I am also wondering whether there is any operational experience with products doing this sort of discovery via IP anycasts. Any insights and pointers might help me to get my understanding clear. 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 wesley.george@twcable.com Tue Nov 29 07:23:14 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F0121F8770 for ; Tue, 29 Nov 2011 07:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 Iw+1mlhGBEfZ for ; Tue, 29 Nov 2011 07:23:14 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id C86D021F8A64 for ; Tue, 29 Nov 2011 07:23:13 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.69,590,1315195200"; d="scan'208";a="287754699" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 29 Nov 2011 10:17:29 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 29 Nov 2011 10:23:12 -0500 From: "George, Wes" To: Juergen Schoenwaelder Date: Tue, 29 Nov 2011 10:23:12 -0500 Thread-Topic: review draft-ietf-opsawg-automated-network-configuration-02 Thread-Index: Acyujd+dSab3kJBLSQahFTnSatCGJgAGHfOw Message-ID: References: <20111122110055.GA94266@elstar.local> <20111129115533.GB30681@elstar.local> In-Reply-To: <20111129115533.GB30681@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: "opsawg@ietf.org" Subject: Re: [OPSAWG] review draft-ietf-opsawg-automated-network-configuration-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:23:15 -0000 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs- > university.de] > > My understanding of IP anycast is that > > - it works well if there is service that is highly replicated and > every (replicated) server provides the same service (the common > example seems to be DNS) [WEG] I don't think that highly replicated is totally necessary for a case = like this. Typically replication is used as a means for redundancy and load= -balancing (often geographically or route-metric aware). That wouldn't nece= ssarily be a requirement for this application. Simply having the right one = be reachable from a given point in the network is enough. If one wants mult= iple servers for redundancy or balancing, the simple requirement is that ea= ch be in sync with the other, so that a client can hit any and receive the = information it needs. > > - it works well for short (ideally stateless) transactions where the > impact of disruptions due to routing updates is small [WEG] yes, but in this case, instead of using anycast for the entire config= uration exchange, that might be as simple as: 1) client hits anycast server IP, exchanges some identifying information (i= ncluding certs) 2) server uses the info provided to respond with a redirect to send client = to the right unicast IP location to request config OR 2a) server responds on a different (unicast) address with the required conf= ig, so that if there are issues, the client knows which server it needs to = send retransmit requests, etc. OR 2b) if the config fails, the client simply sends repeated requests for conf= ig to the anycast address until it's successful or a timeout expires (the a= ssumption being that if a server fails and a reroute is triggered, a retry = will absorb this problem) > > - to work with BGP (that is the interdomain scenario), one typically > needs to allocate a /24 prefix for a service in the case of IPv4 > (which is kind of costly); for interior routing protocols, a host > route might work [WEG] I believe that we could have IANA allocate a well-known prefix for th= is, but allow for those who wish to use their own as well. Using a well-kno= wn prefix allows the networks involved to control the scope - if they have = a business relationship that requires them to be able to route from one net= work to another to reach the closest conf server, they can leak the routes,= or carry them in a vpn. If they want it to remain local, they don't announ= ce the routes beyond their ASN, and they filter it inbound. Managing anycas= t prefixes and routing scope across AS boundaries is already sort of a know= n quantity with things like 6to4 (independent of the implementation problem= s due to 6to4 using stateless tunneling), where people leak, announce, or f= ilter it based on a number of different factors to control which networks c= an use the "service" that they are advertising based on its reachability. > > Section 5.3. talks about the problem of locating the configuration > server of a device. To use IP anycasts, one would need to preconfigure > IP anycast addresses or prefixes and we would then need servers that > provide redirection services for all devices being deployed. However, a > device at the end needs to find "it's" configuration server not an > arbitrary configuration server and hence I do not see how IP anycasts > would work in an inter-domain scenario unless the anycast servers all > can provide the same redirection service. [WEG] I think the thing you're missing is that you're assuming globally-sco= ped anycast (eg reachable from anywhere on any network), which requires som= e sort of central repository and hierarchy, and that's not what I'm suggest= ing. It's possible to control the scope (reachability, really) of an anycas= t address block through route policy, meaning that a given anycast listener= only needs to know about the equipment within the domain that it's scoped = for based on the routing. This allows you to burn the same network-independ= ent IP on all devices, but allow the network provider to decide where that = traffic goes: to the bit-bucket if they are not using that auto-conf model,= to another network if they're serving as transit, to a local server if the= y're maintaining their infrastructure with this autoconf model, etc. This would allow for an ISP to provide something like this as a service to = their customers (especially if combined with methods of identifying one cus= tomer's device from another, like certs), or to use it solely for internal = infrastructure, or some combination of the two. Managing the scope and reac= hability is critical, but quite possible, especially with a good discussion= of the "gotchas." Hope this helps to clarify... Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From cdl@asgaard.org Wed Nov 30 15:37:00 2011 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1838D1F0C55 for ; Wed, 30 Nov 2011 15:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.607 X-Spam-Level: X-Spam-Status: No, score=-5.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 fwiUHhpAJC59 for ; Wed, 30 Nov 2011 15:36:59 -0800 (PST) Received: from asgaard.org (odin.asgaard.org [204.29.151.68]) by ietfa.amsl.com (Postfix) with ESMTP id E51051F0C35 for ; Wed, 30 Nov 2011 15:36:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by asgaard.org (Postfix) with ESMTP id 13DF29659B3; Wed, 30 Nov 2011 23:36:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at asgaard.org Received: from asgaard.org ([127.0.0.1]) by localhost (odin.asgaard.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqpVWe0TPp7b; Wed, 30 Nov 2011 23:36:56 +0000 (UTC) Received: from [192.168.2.200] (74-93-4-129-sfba.hfc.comcastbusiness.net [74.93.4.129]) by asgaard.org (Postfix) with ESMTPSA id E9DD19659A9; Wed, 30 Nov 2011 23:36:55 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/signed; boundary="Apple-Mail=_20684589-5F3B-4DDE-A326-D430C79D43BD"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Christopher LILJENSTOLPE In-Reply-To: <20111129115533.GB30681@elstar.local> Date: Tue, 29 Nov 2011 16:55:26 -0800 Message-Id: References: <20111122110055.GA94266@elstar.local> <20111129115533.GB30681@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1244.3) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review draft-ietf-opsawg-automated-network-configuration-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 23:37:00 -0000 --Apple-Mail=_20684589-5F3B-4DDE-A326-D430C79D43BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings Juergen, Some comments in-line On 29Nov2011, at 03.55, Juergen Schoenwaelder wrote: > On Mon, Nov 28, 2011 at 03:22:08PM -0500, George, Wes wrote: >> As requested, I've reviewed the changes between -01 and -02. Most of = my concerns from my previous message = (http://www.ietf.org/mail-archive/web/opsawg/current/msg01756.html) have = been addressed, with two exceptions: >>=20 >> First, the introduction and later sections still do not provide a = clear explanation of the gaps and issues associated with CAPWAP, = NETCONF/YANG, and the cited BBF/3GPP standards. The current intro = section ends abruptly with several surveys of different existing = protocols without making it clear why those are inadequate. It may be = that this is more left for a follow-on document (a formal gap analysis, = perhaps), but that's worth stating explicitly. Otherwise, I'd recommend = at least some explanation of why the existing efforts are not enough, = thus necessitating this problem statement. >> It's discussed somewhat in section 6, but I think some linking text = in the intro would be helpful. >=20 > I will draft some text to address this but I need to check some of the > specs again to get this right. >=20 >> Second, there is still no discussion of anycast as a potential = solution for 5.3 (config server discovery), either why it would work or = why it would not. I would think that this would be significantly less = brittle than preconfiguring a standard IP address or a URI, because = typically anycast routing can use route scoping to manage where traffic = destined for that IP block is sent, and a well-known address doesn't = suffer from the same inflexibility that using a provider-address or a = hard-coded private address might create. >=20 > My understanding of IP anycast is that=20 >=20 > - it works well if there is service that is highly replicated and > every (replicated) server provides the same service (the common > example seems to be DNS) doesn't need to be highly replicated. Anycast of one works fine. >=20 > - it works well for short (ideally stateless) transactions where the > impact of disruptions due to routing updates is small Or routing is stable enough that the anycast route doesn't change = frequently >=20 > - to work with BGP (that is the interdomain scenario), one typically > needs to allocate a /24 prefix for a service in the case of IPv4 > (which is kind of costly); for interior routing protocols, a host > route might work You would use a /24 for multiple anycast services. But yes, most eBGP = speakers will throw-away a longer than /24 without prior arrangement. >=20 > Section 5.3. talks about the problem of locating the configuration > server of a device. To use IP anycasts, one would need to preconfigure > IP anycast addresses or prefixes and we would then need servers that > provide redirection services for all devices being deployed. However, > a device at the end needs to find "it's" configuration server not an > arbitrary configuration server and hence I do not see how IP anycasts > would work in an inter-domain scenario unless the anycast servers all > can provide the same redirection service. Not necessarily so. If we picked an address a.b.c.d as the re-direction = service, I would policy filter a.b.c.d route imports from networks that = are not part of my anycast-based configuration network. >=20 > It is likely that I am missing something basic, please let me know if > this is the case. I am also wondering whether there is any operational > experience with products doing this sort of discovery via IP anycasts. > Any insights and pointers might help me to get my understanding clear. >=20 > Thanks, >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- =20 =E6=9D=8E=E6=9F=AF=E7=9D=BF Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf --Apple-Mail=_20684589-5F3B-4DDE-A326-D430C79D43BD Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJO1X7+AAoJEGmx2Mt/+Iw/yU8H/02BX0WC8L62Gb20wCa9kKxP kH+vDQ8FLYnDTVl9NEemd0azG7A+ykiZkCfJXeEU6K6d9Q+FrNDex/AVbfd8rBBo LkJxS7/Ad9qrO/Afu6TT5iUwJ5XFEZV+Ph4wH1T+L3WOMZaDL0bpvfk0KAYocpl5 xqSFhs9bGAidlwlrnZRuvIHgF6YKN7fBBJixcZJpiiOUly8axjWTMXs5x3GsQ7Ff jEh8S3rQRP/Wjt95TjMLssvNSmhAkyx+r4vGPH02WzCUwcNZHVXQlm8pPdiN8N2q jlTca+Hurkhyo6SigROV+S4yyWGCLUzW4KcZQXcr2bXws4HFkatvV/u/I1zY8eY= =RXg7 -----END PGP SIGNATURE----- --Apple-Mail=_20684589-5F3B-4DDE-A326-D430C79D43BD--