From network-automation-owner@greatcircle.com Thu Apr 7 13:32:53 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id DE96332C69A for ; Thu, 7 Apr 2005 13:32:52 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Thu, 7 Apr 2005 13:32:49 -0800 To: network-automation@greatcircle.com From: Brent Chapman Subject: Test to new Network Automation list Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/1 X-Sequence-Number: 1 This is a test message to the newly created Network-Automation@GreatCircle.COM mailing list. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Fri Apr 8 13:21:56 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5A1EC32C222 for ; Fri, 8 Apr 2005 13:21:55 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j38KMf5C026799 for ; Fri, 8 Apr 2005 13:22:41 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j38KMf2Z026796 for ; Fri, 8 Apr 2005 13:22:41 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Fri, 8 Apr 2005 13:22:41 -0700 (PDT) From: Paxton To: Subject: available network automation tools Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/2 X-Sequence-Number: 2 I haven't seen any messages yet so I have no idea who has signed up, but I would love to hear a frank discussion of currently available network automation/configuration management (not monitoring) tools, both $$$ and open source. I was interested by Brent's original NANOG posting, in which he states: ..."I'm not simply talking about [..] device configuration monitoring systems [..] Instead I'm talking about systems that will start from a description of how a network ought to be configured, then interact with the various devices on that network to make it so..." What currently available tools actually do this? IMO the $$$ tools out there today (or at least those I have seen referenced, ie the network world article, rendition/Opsware, etc) all are pandering to the sarbanes-oxley scare tactics because that's where the money is. If you really look at them and peel away the marketing fluff and hand-waving, they are all basically a configuration monitoring systems with a stamp on the cd that says: your sarbanes-oxley problems solved here! Is their goal even to solve network automation problems? I find it ironically humorous that rendition renamed true control to "network automation". Maybe they should have renamed it: Sarbanes-Oxley BandAid. Not to pick on rendition, but the reality is there's money in checkbox sarbanes-oxley solutions - and that's money in the right place (execs) and a lot of it. So are real network management solutions getting left in the dust? And what's worse at least IMO is that these guys all claim to provide network management solutions, but don't actually provide value to network administrators (or that isn't their main goal, its an afterthought if its given any consideration at all), and because the money is already spent, the network administrators don't get tools that might actually solve a real problem. I hope this is just controversial enough to spur on some conversation, because I would really like to hear everyone else's opinions and experiences, and what else is out there that I haven't seen yet. Can anyone recommend open source tools for configuration management/network automation, or is there interest in starting such a project? Thanks! From network-automation-owner@greatcircle.com Fri Apr 8 13:42:00 2005 X-Original-To: Network-Automation@GreatCircle.COM Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id E7CD032C29F for ; Fri, 8 Apr 2005 13:41:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Fri, 8 Apr 2005 13:41:57 -0700 To: Network-Automation@GreatCircle.COM From: Brent Chapman Subject: Welcome, and BoF at USENIX next week Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/3 X-Sequence-Number: 3 It's been less than 24 hours since I announced this list, and we've already passed the 200 subscriber mark... Welcome one and all! I'm looking forward to some very interesting discussions on this list. If any of you are going to be at the USENIX conference in Anaheim next week, I've scheduled a Network Automation BoF (Birds of a Feather session, where folks interested in a particular topic get together to chat about it) for Wednesday night, 8:30-9:30pm. Right now, they've got us scheduled in Salon H, but that's subject to change, so check the scheduling board at the conference. BoF info: Automating Network Configuration & Management Organizer/Moderator: Brent Chapman, Great Circle Associates Wednesday, April 13, 8:30 pm-9:30 pm, Salon H What's the state of the art for automated network configuration and management? What systems and tools are available, either freely or commercially? Where are these issues being considered and discussed? Over the last 15 years or so, much of the research in the system administration field has focused on automation. It's now well accepted that a well-run operation doesn't manage 10,000 servers individually, but rather uses tools like cfengine to manage definitions of those servers and then create instances of those servers as needed. In the networking world, though, most of us seem to be still manually configuring (and reconfiguring) every device. Some URLs: All scheduled BoF: http://www.usenix.org/events/usenix05/bofs.html Our BoF: http://www.usenix.org/events/usenix05/bofs.html#automating Conference info: http://www.usenix.org/events/usenix05/ So, now that we're all here, let the games begin! ;-) -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Fri Apr 8 13:56:58 2005 X-Original-To: network-automation@greatcircle.com Received: from iad2smtpout03.target.com (smtpout03.target.com [161.225.129.10]) by mycroft.greatcircle.com (Postfix) with ESMTP id D8FC132C2A7 for ; Fri, 8 Apr 2005 13:56:57 -0700 (PDT) Received: from emailhub02.target.com ([10.114.73.22]) by iad2smtpout03.target.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 15:56:57 -0500 Received: from EMAILSTORE13.target.com ([10.114.81.32]) by emailhub02.target.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 15:56:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: available network automation tools Date: Fri, 8 Apr 2005 15:56:55 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: available network automation tools Thread-Index: AcU8eKEz+8ZTeH3/QGWpUOt/S75iCgAANXdg From: "Network.Security" To: X-OriginalArrivalTime: 08 Apr 2005 20:56:59.0012 (UTC) FILETIME=[81703440:01C53C7D] X-Archive-Number: 200504/4 X-Sequence-Number: 4 OK, I'll bite. We use Rendition (now Opsware) for config mgmt. of our network stuff and the change detection / archival function has already saved my butt a number of times. Our engineers gripe about the Big-Brother aspect, but per the quasi-rant about SOX / CISP / PCI it's a fact of life now for any SEC-filing corp at a minimum. I realize this is somewhat OT for this list, but SOX (in general) shouldn't really matter to network admins (network meaning L1 to ~L4), as SOX is all about altering the financial data. As a network person, you can certainly see all of that data, but you can't change it (packet injection doesn't count, most apps pick up on that sort of activity even if they don't know why they know :) For that you need to be a server admin / DBA, so for true network people, we don't really care. (Loose generalization there. Re: caring) As for Opsware, their SOX report is static. It doesn't tell you anything. It's just text so the tool offers no value to that. Now, CISP / PCI on the other hand, that's the project funding behemoth you've all been waiting for. If you need money, say it's for PCI and poof-like-magic, here's the cash to make it happen. PCI has some fairly strict requirements that are defined to the network level regarding open ports, encryption schemes, use of clear-text, etc. Tools like Opsware can help enforce or at least notify on those data points. Re: free tools, I think we've all heard of RANCID as a config-o-monitor (I personally am CVS debilitated and have not yet been able to make it work on any platform). Big companies do not like free tools. That's why Linux was not making progress in large enterprises until we could start paying for it (aka Red Hat). If they can't get maintenance / support for something that the business needs, it's not coming into the environment. This makes sense, though not really from a "help us stay on the cutting-edge of technology aspect". Opsware and Voyence (we demo-ed them) both do some configuration templating so that if you are building out CPE, you can have it make your router configs or whatever, but for already installed networks, the templating is not valuable. I'm all about the configuration policy piece, I want to know how many of my devices don't have enough ntp servers configured, that sort of thing or down the road to make sure my QoS policies are consistent across the board. But that's all to get me to a point in time where everything is "right", it doesn't help me deploy new services all that differently than my perl scripts did before. What I think you are talking about is an application aware network provisioning system. Something that is aware of all possible topological paths between endpoints and is smart enough to know how to configure all the hops / connections in between the two to make something happen. Like a DOS mitigation system or punching holes through a series of firewalls or configuring multi-hop VPN tunnels. Yeah, that doesn't exist as far as I know. Or more to the point, I'm sure these tools could do that, but the work required on the front-end won't end up saving you anything on the back-end. Oh and it has to be vendor-agnostic. Heh. That market is more in the NetDoctor or related simulation style configuration analyzers that do the what-if type stuff or there are a couple other QoS policers out there that do something similar, but they are niche market tools for QoS only and appliances at that. So to your question, No would be my answer, there isn't something like that out there today, there are point solutions that solve particular aspects of the overall issue, but nothing end-to-end. BTW, Opsware and others would love to see this list if it grows and utilize it as a tool for soliciting industry-wide customer feedback. I would suggest consideration of that either for it or against (I don't really care) and noting it in the policy. Scott.altman@target.com From network-automation-owner@greatcircle.com Fri Apr 8 14:45:16 2005 X-Original-To: network-automation@greatcircle.com Received: from mail02inhq.keynote.com (mail02inhq.keynote.com [65.198.48.194]) by mycroft.greatcircle.com (Postfix) with ESMTP id 4460732C3A9 for ; Fri, 8 Apr 2005 14:18:18 -0700 (PDT) Received: from exchange04inhq.int.win.keynote.com (exchange04inhq.keynote.com [65.198.49.44]) by mail02inhq.keynote.com (8.12.11/8.12.11) with ESMTP id j38LIHjj024513 for ; Fri, 8 Apr 2005 14:18:18 -0700 X-Relayed-By: mail02inhq.keynote.com x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53C80.7B387BBB" Subject: ACL management Date: Fri, 8 Apr 2005 14:18:17 -0700 Message-ID: <663A9295DD2FFB46A85D0264EEB83F60CC144B@exchange04inhq.keynote.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACL management Thread-Index: AcU8gHsafKWCV076RgmleNYt+sERMA== From: "Alan Young" To: X-Archive-Number: 200504/5 X-Sequence-Number: 5 This is a multi-part message in MIME format. ------_=_NextPart_001_01C53C80.7B387BBB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 What products out there can I use to automate/simplify ACL management? Cur= rently, the process I follow is a very tedious and manual process. =20 I am specifically thinking of applications that work in a Cisco centric env= ironment. Before everyone suggests CiscoWorks ACL manager, I would like to= state that I have had many problems with CiscoWorks and would rather not u= se it. However, CiscoWorks ACL Manager might be a different beast, so I wo= uld like to hear people's thoughts on the product. =20 Having a easy way to make changes to an ACL would really help many people u= sing old bogon lists from places such as: http://www.cymru.com/Documents/se= cure-ios-template.html=20 =20 Thanks, =20 -Alan Young ------_=_NextPart_001_01C53C80.7B387BBB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

All,

 <= /span>

What products out there can I use to automate/simplify ACL managemen= t?  Currently, the process I follow i= s a very tedious and manual process.

 <= /span>

I am specifically thinking of applications that work in a Cisco cent= ric environment.  Before everyone suggests CiscoWor= ks ACL manager, I would like to state that I have had many problems with CiscoWorks and would rather not use it.  However, CiscoWorks ACL Manager might be a different beast, so I wou= ld like to hear people’s thoughts on the product.

 <= /span>

Having a easy way to make changes to an ACL would really help many people using old bogon lists from places such as: http://www= .cymru.com/Documents/secure-ios-template.html

 <= /span>

Thanks,

 <= /span>

-Alan Young

------_=_NextPart_001_01C53C80.7B387BBB-- From network-automation-owner@greatcircle.com Fri Apr 8 15:43:48 2005 X-Original-To: network-automation@greatcircle.com Received: from mta1.lbl.gov (mta1.lbl.gov [128.3.41.24]) by mycroft.greatcircle.com (Postfix) with ESMTP id BEBDF32C340 for ; Fri, 8 Apr 2005 15:43:47 -0700 (PDT) Received: from mta1.lbl.gov (localhost [127.0.0.1]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j38Mhin3023126 for ; Fri, 8 Apr 2005 15:43:44 -0700 (PDT) Received: from [127.0.0.1] (dhcp163-8.nersc.gov [128.55.8.163]) by mta1.lbl.gov (8.12.10/8.12.10) with ESMTP id j38MhhP9023119; Fri, 8 Apr 2005 15:43:43 -0700 (PDT) Message-ID: <4257091F.4050700@nersc.gov> Date: Fri, 08 Apr 2005 15:43:43 -0700 From: Eli Dart Reply-To: dart@nersc.gov Organization: NERSC Center, LBNL User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Young Cc: network-automation@greatcircle.com Subject: Re: ACL management References: <663A9295DD2FFB46A85D0264EEB83F60CC144B@exchange04inhq.keynote.com> In-Reply-To: <663A9295DD2FFB46A85D0264EEB83F60CC144B@exchange04inhq.keynote.com> X-Enigmail-Version: 0.90.1.1 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archive-Number: 200504/6 X-Sequence-Number: 6 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alan Young wrote: > All, > > What products out there can I use to automate/simplify ACL management? For IOS-like boxes, we've found that a tftp server works very well. You edit the command file (which contains the set of commands to install the acl) on the tftp server (where you have version control, etc) and then pull it into the router via tftp when you're done editing it. If you have to push a given list out to many routers, I could envision a perl Net::Telnet script to install an acl bound to a given interface in a given direction. You could also put together a make infrastructure that created the acls and then your perl script would only pull them down to the appropriate router. I've not had the need to build such a beast, but it feels fairly straightforward. --eli -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVwkfLTFEeF+CsrMRAu4BAKCdgG2LIWLuPeLIhQYRO2v+ji03ZQCgzkpy YvQjwM4vCBI281tbMzph8Cw= =kBdI -----END PGP SIGNATURE----- From network-automation-owner@greatcircle.com Fri Apr 8 18:11:21 2005 X-Original-To: network-automation@greatcircle.com Received: from mail.axint.net (mail.axint.net [38.116.133.5]) by mycroft.greatcircle.com (Postfix) with ESMTP id 805DA32C213 for ; Fri, 8 Apr 2005 18:11:20 -0700 (PDT) Received: (qmail 18667 invoked by uid 514); 9 Apr 2005 01:11:18 -0000 Received: from 38.116.133.27 by mail.axint.net (envelope-from , uid 89) with qmail-scanner-1.24-st-qms (clamdscan: 0.83/741. bitdefender: v7.0/2490/101512. perlscan: 1.24-st-qms. Clear:RC:1(38.116.133.27):. Processed in 0.602935 secs); 09 Apr 2005 01:11:18 -0000 Received: from unknown (HELO cs.axint.net) (cstone@axint.net@38.116.133.27) by 0 with (RC4-MD5 encrypted) SMTP; 9 Apr 2005 01:11:18 -0000 From: Chris Stone Organization: AxisInternet, Inc. To: network-automation@greatcircle.com Subject: Re: ACL management Date: Fri, 8 Apr 2005 19:11:11 -0600 User-Agent: KMail/1.6.2 References: <663A9295DD2FFB46A85D0264EEB83F60CC144B@exchange04inhq.keynote.com> <4257091F.4050700@nersc.gov> In-Reply-To: <4257091F.4050700@nersc.gov> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200504081911.15864.cstone@axint.net> X-Archive-Number: 200504/7 X-Sequence-Number: 7 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 08 April 2005 04:43 pm, Eli Dart wrote: > Alan Young wrote: > > What products out there can I use to automate/simplify ACL management? > > For IOS-like boxes, we've found that a tftp server works very well. > You edit the command file (which contains the set of commands to > install the acl) on the tftp server (where you have version control, > etc) and then pull it into the router via tftp when you're done > editing it. > > If you have to push a given list out to many routers, I could > envision a perl Net::Telnet script to install an acl bound to a > given interface in a given direction. You could also put together a > make infrastructure that created the acls and then your perl script > would only pull them down to the appropriate router. I've not had > the need to build such a beast, but it feels fairly straightforward. There is an open source project on SourceForge called the Cisco-centril Ope= n=20 Source Initiative that has a bunch of scripts for dealing with cisco router= s=20 and switches, include ACL management. Recommend a look: http://sourceforge.net/projects/cosi-nms/ Chris Stone, MCSE AxisInternet, Inc. www.axint.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCVyuvG4PxJjbMvv0RAij1AKCeKR5s7Xhy1VCpgL6fYXTFzRBkWACgrQdd B5vSSaEhn+R2kkhzElnngSc=3D =3D4nWF -----END PGP SIGNATURE----- From network-automation-owner@greatcircle.com Fri Apr 8 18:53:54 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id A261832C193 for ; Fri, 8 Apr 2005 18:53:53 -0700 (PDT) Received: from [64.47.15.110] ([64.47.15.110]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 20:53:11 -0500 Message-ID: <42573546.7050503@gmail.com> Date: Fri, 08 Apr 2005 21:52:06 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paxton Cc: network-automation@greatcircle.com Subject: Re: available network automation tools References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Apr 2005 01:53:11.0419 (UTC) FILETIME=[E29E4CB0:01C53CA6] X-Archive-Number: 200504/8 X-Sequence-Number: 8 Paxton wrote on 04/08/2005 04:22 PM: > I was interested by Brent's original NANOG posting, in which he states: > > ..."I'm not simply talking about [..] device configuration monitoring > systems [..] Instead I'm talking about systems that will start from a > description of how a network ought to be configured, then interact with > the various devices on that network to make it so..." > > What currently available tools actually do this? None that I've seen. Before going the route of building our own internal system for vendor-independent configuration generation and management, I met with every CM vendor I could find, including a whole bunch of dot-com busts. To name a few (the more promising ones): Orchestream Dorado Goldwire Digital Fairways Cplane Network Mantra Rendition Most of these focused on two things: config backup, and limited Cisco service config templating. What we were looking for was a full network equipment and relationship model, generic enough to model all types of routers, switches and containers, along with a scriptable configuration generation engine to interpret that model into device-dependent configuration deltas, and a service activation manager to resolve dependencies (which services required changes to which devices) and schedule config changes. Some of the tools above evolved to be support a little more than just Cisco, and some of the config templating got a little more sophisticated, but most have since died or been acquired, and none meet the above goals. Unfortunately, 4 years later, we still wouldn't be able to replace our homegrown configuration management system with any COTS system that had comparable features. And the importance of having a queryable network model cannot be overstated. This has become the core of our OSS systems: driving data collection, automating NMS configuration and performance measurement, and enabling much better inventory control than we ever had before. Originally, I had hoped that the DMTF Common Information Model and Directory Enabled Networking initiatives might yield some useful products in this direction, where TMN failed to help. But these took the same path of TMN of over-abstracting and over-specifying particularly at the physical layer, making them unworkable for logical network modeling. --kirby files NMS Software Lead Masergy Communications From network-automation-owner@greatcircle.com Sat Apr 9 08:05:53 2005 X-Original-To: network-automation@greatcircle.com Received: from smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.4.112.95]) by mycroft.greatcircle.com (Postfix) with SMTP id 391C732C19D for ; Sat, 9 Apr 2005 08:05:51 -0700 (PDT) Received: (qmail 20461 invoked by uid 89); 9 Apr 2005 15:05:49 -0000 Received: from unknown (HELO localhost) (max.reid@saikonetworks.com@192.168.15.3) by mail1.no-ip.com with SMTP; 9 Apr 2005 15:05:49 -0000 Received: from wbar3.sea1-4-5-119-184.sea1.dsl-verizon.net (wbar3.sea1-4-5-119-184.sea1.dsl-verizon.net [4.5.119.184]) by webmail.no-ip.com (IMP) with HTTP for ; Sat, 9 Apr 2005 08:05:49 -0700 Message-ID: <1113059149.4257ef4d5e7aa@webmail.no-ip.com> Date: Sat, 9 Apr 2005 08:05:49 -0700 From: max.reid@saikonetworks.com To: Paxton Cc: network-automation@greatcircle.com Subject: Re: available network automation tools References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-WebMail: No-IP.com X-Originating-IP: 4.5.119.184 X-Archive-Number: 200504/9 X-Sequence-Number: 9 Hi all, Currently, I'm pretty good at putting together stuff like subversion, rancid, RRDtool, Cacti, Nagios, tftp, scp, together into a somewhat useful package for basic stuff, automated diffs and version control and Monitoring. I think we can all agree that such homegrown systems are great for that sort of thing. There certainly isn't a cfengine type application for multivendor network devices, but with cisco Incorporating Tcl shells and precompilers in IOS, F5 using a Tcl shell to replace their proprietary scripting language, There just needs to be an Open Reference model or XML schema to describe device functions... I don't think we're there yet. What I don't like are some of the things various vendors are doing to try to address the problem in their devices, like the Cisco "AutoSecure" feature. I suppose this will open discussion into how much automation is a good thing. If it saves me from carpel tunnel or having to produce funky perl code, then perhaps it is useful. I think we get into trouble when the tools start to dynamically alter the network topology. If you take a look at some IDS/IDP systems, you'll understand what I mean. While they are policy driven, they aren't very useful out of the box and take considerable work in order to have them function properly for your specific environment. Regards, Max Quoting Paxton : > > I haven't seen any messages yet so I have no idea who has signed up, but I > would love to hear a frank discussion of currently available network > automation/configuration management (not monitoring) tools, both $$$ and > open source. > > I was interested by Brent's original NANOG posting, in which he states: > > ..."I'm not simply talking about [..] device configuration monitoring > systems [..] Instead I'm talking about systems that will start from a > description of how a network ought to be configured, then interact with > the various devices on that network to make it so..." > > What currently available tools actually do this? IMO the $$$ tools out > there today (or at least those I have seen referenced, ie the network > world article, rendition/Opsware, etc) all are pandering to the > sarbanes-oxley scare tactics because that's where the money is. If you > really look at them and peel away the marketing fluff and hand-waving, > they are all basically a configuration monitoring systems with a stamp on > the cd that says: your sarbanes-oxley problems solved here! Is their > goal even to solve network automation problems? I find it > ironically humorous that rendition renamed true control to "network > automation". Maybe they should have renamed it: Sarbanes-Oxley BandAid. > Not to pick on rendition, but the reality is there's money in checkbox > sarbanes-oxley solutions - and that's money in the right place (execs) and > a lot of it. So are real network management solutions getting left in the > dust? And what's worse at least IMO is that these guys all claim to > provide network management solutions, but don't actually provide value to > network administrators (or that isn't their main goal, its an > afterthought if its given any consideration at all), and because the money > is already spent, the network administrators don't get tools that might > actually solve a real problem. > > I hope this is just controversial enough to spur on some conversation, > because I would really like to hear everyone else's opinions and > experiences, and what else is out there that I haven't seen yet. > > Can anyone recommend open source tools for configuration > management/network automation, or is there interest in starting such a > project? > > > Thanks! > > > > From network-automation-owner@greatcircle.com Sat Apr 9 08:17:09 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id B610032C331 for ; Sat, 9 Apr 2005 08:17:08 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j39FHp5C027737; Sat, 9 Apr 2005 08:17:51 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j39FHo2J027734; Sat, 9 Apr 2005 08:17:50 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Sat, 9 Apr 2005 08:17:50 -0700 (PDT) From: Paxton To: Kirby Files Cc: Subject: Re: available network automation tools In-Reply-To: <42573546.7050503@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/10 X-Sequence-Number: 10 >> And the importance of having a queryable network model cannot be overstated. This has become the core of our OSS systems exactly. The vendor CM tools I've looked at all miss the boat in this regard. I don't want a bunch of one-hit-wonder tools, I want a foundation we can build from. I'm not sure any of these guys will get it right because they are going after what sells to the CIO, and the queryable network model is not sellable at that level (or so I'm told.) On Fri, 8 Apr 2005, Kirby Files wrote: > Paxton wrote on 04/08/2005 04:22 PM: > > I was interested by Brent's original NANOG posting, in which he states: > > > > ..."I'm not simply talking about [..] device configuration monitoring > > systems [..] Instead I'm talking about systems that will start from a > > description of how a network ought to be configured, then interact with > > the various devices on that network to make it so..." > > > > What currently available tools actually do this? > > None that I've seen. Before going the route of building our own > internal system for vendor-independent configuration generation and > management, I met with every CM vendor I could find, including a whole > bunch of dot-com busts. To name a few (the more promising ones): > > Orchestream > Dorado > Goldwire > Digital Fairways > Cplane > Network Mantra > Rendition > > Most of these focused on two things: config backup, and limited Cisco > service config templating. > > What we were looking for was a full network equipment and relationship > model, generic enough to model all types of routers, switches and > containers, along with a scriptable configuration generation engine to > interpret that model into device-dependent configuration deltas, and a > service activation manager to resolve dependencies (which services > required changes to which devices) and schedule config changes. > > Some of the tools above evolved to be support a little more than just > Cisco, and some of the config templating got a little more > sophisticated, but most have since died or been acquired, and none > meet the above goals. > > Unfortunately, 4 years later, we still wouldn't be able to replace our > homegrown configuration management system with any COTS system that > had comparable features. And the importance of having a queryable > network model cannot be overstated. This has become the core of our > OSS systems: driving data collection, automating NMS configuration and > performance measurement, and enabling much better inventory control > than we ever had before. > > Originally, I had hoped that the DMTF Common Information Model and > Directory Enabled Networking initiatives might yield some useful > products in this direction, where TMN failed to help. But these took > the same path of TMN of over-abstracting and over-specifying > particularly at the physical layer, making them unworkable for logical > network modeling. > > --kirby files > NMS Software Lead > Masergy Communications > From network-automation-owner@greatcircle.com Sat Apr 9 08:33:27 2005 X-Original-To: network-automation@greatcircle.com Received: from smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.4.112.95]) by mycroft.greatcircle.com (Postfix) with SMTP id A77FC32C331 for ; Sat, 9 Apr 2005 08:33:26 -0700 (PDT) Received: (qmail 27817 invoked by uid 89); 9 Apr 2005 15:33:25 -0000 Received: from unknown (HELO localhost) (max.reid@saikonetworks.com@192.168.15.3) by mail1.no-ip.com with SMTP; 9 Apr 2005 15:33:25 -0000 Received: from wbar3.sea1-4-5-119-184.sea1.dsl-verizon.net (wbar3.sea1-4-5-119-184.sea1.dsl-verizon.net [4.5.119.184]) by webmail.no-ip.com (IMP) with HTTP for ; Sat, 9 Apr 2005 08:33:25 -0700 Message-ID: <1113060805.4257f5c567b57@webmail.no-ip.com> Date: Sat, 9 Apr 2005 08:33:25 -0700 From: max.reid@saikonetworks.com To: "Network.Security" Cc: network-automation@greatcircle.com Subject: Re: available network automation tools References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-WebMail: No-IP.com X-Originating-IP: 4.5.119.184 X-Archive-Number: 200504/11 X-Sequence-Number: 11 Quoting "Network.Security" : > OK, I'll bite. > > We use Rendition (now Opsware) for config mgmt. of our network stuff and > the change detection / archival function has already saved my butt a > number of times. Our engineers gripe about the Big-Brother aspect, but > per the quasi-rant about SOX / CISP / PCI it's a fact of life now for > any SEC-filing corp at a minimum. > > I realize this is somewhat OT for this list, but SOX (in general) > shouldn't really matter to network admins (network meaning L1 to ~L4), > as SOX is all about altering the financial data. Hmm... I can understand the focus on the financial data, but doesn't it also cover stuff like email and all of IT under the umbrella of "Significant Security controls"? I know for a fact that storage vendors are drooling over the opportunity to sell SOX related warez and disks to PHBs everywhere. Regards, Max From network-automation-owner@greatcircle.com Sat Apr 9 17:45:40 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mycroft.greatcircle.com (Postfix) with ESMTP id 540D032C3FE for ; Sat, 9 Apr 2005 17:45:39 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so912108rna for ; Sat, 09 Apr 2005 17:45:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BGQRKEVrK2cbdSFyYL4jPT+MRn+Ty//qME+w6MQeisf1yGTtr8fax0703Cq6WTFhVDLEo9S+FbrVjGYmZaGIr82Z2Sc2HPd/lSXtL8QcM9xcbM5Iywif58QPAfPvMReY235ZVJAtaIKqrDiGxzjlSKr1rECO95qLNnwKEJ18jPQ= Received: by 10.38.152.48 with SMTP id z48mr2830862rnd; Sat, 09 Apr 2005 17:45:38 -0700 (PDT) Received: by 10.38.151.34 with HTTP; Sat, 9 Apr 2005 17:45:38 -0700 (PDT) Message-ID: <18f60194050409174575ada600@mail.gmail.com> Date: Sat, 9 Apr 2005 17:45:38 -0700 From: Aaron Glenn Reply-To: Aaron Glenn To: Kirby Files Subject: Re: available network automation tools Cc: network-automation@greatcircle.com In-Reply-To: <42573546.7050503@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42573546.7050503@gmail.com> X-Archive-Number: 200504/12 X-Sequence-Number: 12 Kirby, If you would be so kind as to elaborate on a few of your points outlined below. On Apr 8, 2005 6:52 PM, Kirby Files wrote: > What we were looking for was a full network equipment and relationship > model, generic enough to model all types of routers, switches and > containers, along with a scriptable configuration generation engine to > interpret that model into device-dependent configuration deltas, and a > service activation manager to resolve dependencies (which services > required changes to which devices) and schedule config changes. Perhaps it's the cleaning fluid fumes in my apartment today, but I'm having trouble fully grasping what you're describing there. Can you take it down a notch to laymens terms? > Unfortunately, 4 years later, we still wouldn't be able to replace our > homegrown configuration management system with any COTS system that > had comparable features. And the importance of having a queryable > network model cannot be overstated. This has become the core of our > OSS systems: driving data collection, automating NMS configuration and > performance measurement, and enabling much better inventory control > than we ever had before. What is a "queryable network model" ? Thank you, aaron.glenn From network-automation-owner@greatcircle.com Sun Apr 10 08:03:45 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id E026732C335 for ; Sun, 10 Apr 2005 08:03:43 -0700 (PDT) Received: from [64.47.15.101] ([64.47.15.101]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Apr 2005 10:03:01 -0500 Message-ID: <42593FE4.7030901@gmail.com> Date: Sun, 10 Apr 2005 11:01:56 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Glenn Cc: network-automation@greatcircle.com Subject: Re: available network automation tools References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> In-Reply-To: <18f60194050409174575ada600@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Apr 2005 15:03:01.0616 (UTC) FILETIME=[63CA3F00:01C53DDE] X-Archive-Number: 200504/13 X-Sequence-Number: 13 Aaron Glenn wrote on 04/09/2005 08:45 PM: > Kirby, > > If you would be so kind as to elaborate on a few of your points outlined below. > > On Apr 8, 2005 6:52 PM, Kirby Files wrote: > >>What we were looking for was a full network equipment and relationship >>model, generic enough to model all types of routers, switches and >>containers, along with a scriptable configuration generation engine to >>interpret that model into device-dependent configuration deltas, and a >>service activation manager to resolve dependencies (which services >>required changes to which devices) and schedule config changes. > > > Perhaps it's the cleaning fluid fumes in my apartment today, but I'm > having trouble fully grasping what you're describing there. Can you > take it down a notch to laymens terms? For us, a complete configuration management system includes: * a vendor-independent model of the physical and logical network (objects and fields describing configuration of devices, cards, interfaces, etc; and relationships between these objects) * An interface for defining this model in network engineering terms * definition of services in terms of component devices and logical path * scripts or code defining how to build configs for specific vendors based upon the model, connections, and applied services * service activation manager that can manage many simultaneous threads of network communication for deploying these configs in a transactional process * configuration backups, history, diffs, equipment hardware management, etc. * network auditing to ensure database accuracy * a database schema or API to query all fields, relationships, events, etc. This combination allows for the shifting of all configuration responsibilities from users to the CM system (now, users mostly login to core equipment only for troubleshooting), speeding up deployment, reducing errors, and improving reliability. It also serves to provide a true functional definition for all services frequently lacking in Product Mangement docs; if the product can't be reduced to a well-defined body of script or code, it's not baked enough to be called "standard". > What is a "queryable network model" ? Well, as described above, the network model is a database that is capable of describing what the equipment is, how it is configured, and how devices are connected to each other. It includes the network topologies and hierarchy, logical connections, IP subnets, routing policies, physical components, etc. For us, the key has been to keeps the schema for the model defined not in the management software or static database tables, but a NetEng modifiable syntax that can be quickly changed to add new concepts, hardware, and services. In this context, queryable means just that: all interesting features of the network should be discoverable by external users and systems, rather than being hardcoded in software. Whether this is implemented in SQL (not always recommended, especially since SQL is terrible at tree representations), a well-defined API, query syntax, or message format is less important. Thanks, --kirby From network-automation-owner@greatcircle.com Sun Apr 10 21:49:16 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mycroft.greatcircle.com (Postfix) with ESMTP id 096A332C446 for ; Sun, 10 Apr 2005 21:49:11 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1103743rna for ; Sun, 10 Apr 2005 21:49:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=MSMF9Z42NayzbqKkEeoCcE+V5jjyGNGD7OYAcSDUVCLkA89HAAg6eVrunjFMklrQNz0ODUu9KBPH4NJAV7t6/ouOzEf0s7mcPX96VG+yMXIdelYtdCA1asPNFaQXn5QfgIBrgaphVT8acHOPy7J0IaGNtmoqo5cuDIKb1MZaAds= Received: by 10.38.90.72 with SMTP id n72mr4896607rnb; Sun, 10 Apr 2005 21:49:10 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Sun, 10 Apr 2005 21:49:10 -0700 (PDT) Message-ID: <7654d9d05041021497c88c860@mail.gmail.com> Date: Mon, 11 Apr 2005 14:49:10 +1000 From: Andrew Fort Reply-To: Andrew Fort To: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <42593FE4.7030901@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> X-Archive-Number: 200504/14 X-Sequence-Number: 14 On Apr 11, 2005 1:01 AM, Kirby Files wrote: > For us, a complete configuration management system includes: > * a vendor-independent model of the physical and logical network > (objects and fields describing configuration of devices, cards, > interfaces, etc; and relationships between these objects) > * An interface for defining this model in network engineering terms > * definition of services in terms of component devices and logical path > * scripts or code defining how to build configs for specific vendors > based upon the model, connections, and applied services > * service activation manager that can manage many simultaneous > threads of network communication for deploying these configs in a > transactional process > * configuration backups, history, diffs, equipment hardware > management, etc. > * network auditing to ensure database accuracy > * a database schema or API to query all fields, relationships, > events, etc. > > This combination allows for the shifting of all configuration > responsibilities from users to the CM system (now, users mostly login > to core equipment only for troubleshooting), speeding up deployment, > reducing errors, and improving reliability. It also serves to provide > a true functional definition for all services frequently lacking in > Product Mangement docs; if the product can't be reduced to a > well-defined body of script or code, it's not baked enough to be > called "standard". All spot on. I particularly like the product definition one, that has played an important role here already - and we've only gotten to the stage of importing network configuration into the model and highlighting further study cases... The key steps and comments in building and implementing such a system, which many are faced with doing (hence: this is a great focus for an open source project I think :-)), are, I see (and this is the process we're going through now where I work): - Model the network. In one projection of the idea, at the simplest level you have objects and relationships (which are objects themselves). Both of these types have attributes. It's important to be able to map any network type that you'll need to configure, so you probably need to store VLAN/FrDLCI information, for example. How to map that? Perhaps some recursion is useful (a network segment object (e.g. DLCI, VLAN) is "a member of" or "attached to" a physical link object. IP interfaces are just mapped to a logical or physical parent, and so on. The key is obviously to get a model which can represent your entire network completely enough that you don't need to work around it. The basic approach above will work, how far you abstract it is network dependant. - Understand your deployment characteristics. You may or may not have out-of-band management (in some and not all locations). If not, how do you avoid cases like disabling the IGP router so that you won't break the telnet session as the config is applied? How then, do you perform changes to vital (e.g. management) interface configuration? How do you avoid such problems? "disable certain commands" immediately comes to mind, but how can you allow certain configuration to occur whilst disabling potentially important commands. This part is inevitably somewhat network specific, but you may like to use approaches to have an interface attribute such as "management". Configuration for these interfaces is then manual. However, it may be impossible to know of all of these cases ahead of time without an exhaustive search (possibly related to strange loops/Godel's incompleteness theorem?). Then you'll need some way of applying the config to the devices. A device agent would be best (since we can treat the change to happen atomically, at some particular pre-scheduled time) (cisco have such an agent, but the interface is closed), at worst scripted-VTY access. The latter of course has the problems spoken about above. Scripted-console access may be a real boon, but is largely unsuitable for many devices (CPE, small sites depending on your management "will"), so we'll have to consider scripted VTY or similar - SNMP configuration MIBs are not an option here (no non-v3 write (policy)), but may be for you.. - Finally, enforce the model as being more important than the element. The network element just provides reality for your network model. Process as well as policy is needed (I encourage TAC+ command lockouts), Other notes I have about the goals of the system are: - Configuration applied must have the same action no matter what the initial state of the target element. This generally translates to "bring all pre-requisite configuration along with the change". This is important so that you can apply partial configurations to devices in whatever state -- many of the "big boys" who do network configuration management presently load to startup and reload, and their networks handle this type of management. For many of us out there, that's not possible. So the model must support storing all necessary configuration (or at least, identifying what standard templates need to be placed in what order to build the "base config" of the device) so that both partial and complete configurations can be formed. How do I know what is already configured on the device? Assume nothing? Probably. This depends on if you want to completely trust your database, or whether you have some trust in the existing configuration. The more I work in this area, the less I can trust the network configuration. - Allow the network operators to easily identify the change (via some ID) that caused the most recent (or couple of most recent) change to the element configuration. This tends to be important in helping the NOC identify the triggers for recent change to the configuration. You can alert people of this in other ways, e.g. via the configuration manager itself. Auto-generating "banner exec" works well on cisco devices, for example, as a sign that "the change was applied" (whether it was successful or not, is somewhat different). Once the above has been nutted out, the multi-vendor hurdles are mostly irrelevant, and all related to the "deployment characteristics" situation above. -andrew From network-automation-owner@greatcircle.com Mon Apr 11 07:55:28 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 101D932C452 for ; Sun, 10 Apr 2005 23:24:35 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 9614119343; Mon, 11 Apr 2005 02:24:30 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.6174.403374.979347@perdition.linnaean.org> Date: Mon, 11 Apr 2005 02:24:30 -0400 To: Andrew Fort Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041021497c88c860@mail.gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/15 X-Sequence-Number: 15 > Configuration for these interfaces is then manual. However, it may be > impossible to know of all of these cases ahead of time without an > exhaustive search (possibly related to strange loops/Godel's > incompleteness theorem?). "It depends". On one extreme, you limit the language you can speak, preventing the ugly cases, consequently limiting the capability of your model. On the other is no restriction, with a resultingly more expressive model, but with halting trouble if the user doesn't use it well. Personally, I'm for being allowed to shoot myself in the head if that's what I said to do, but getting to a model that allows me to both shoot myself in the head and have the computer warn me that "by the way, you might want to know that saying 'twiddle the flubbypux into state 29' may mean 'shoot yourself and twenty friends in the head'" is a little bit of work. Witness my example from a few days ago on infrastructures: the addresses within a subnet are numbers. I don't mean that in the obvious sense (being 32 bit numbers), I mean that in a more subtle one. If you allow the user of your configuration system to operate on these numbers in arbitrary ways and define functions on them (which you pretty much have to do in order to give them what they need), you're giving them the very tools they need to create halting problems. In the case of network engineering, your semantic and reflection problems with reasoning with loops is relatively easy. Consider the case of destroying the only path to talk to a computer (not terribly different from a router in this simple example). Assuming a linux machine, and we were sitting at some other host in our network, typing something like the following is an instance of the statement class we are concerned with: $ ssh host-thats-gonna-die $ sudo ifconfig eth0 0 where once authenticate2 completes, the deed is done. What we want to be able to do is equate the above statement with the notion of destroying our ability to reach hosts-thats-gonna-die from wherever we started from (and if our network has reasonable transitive properties, no host can reach it). This is "simple", for an annoying value of simple. It mostly comes down to being able to compute the meaning of each statement in a reasonably large size world (one thats as large as your network). In particular, you need to be able to reason with how "sudo ifconfig eth0 0" transmitted to our victim host is going to side effect the network configuration of the victim such that it would be unreachable to the broader world. Somehow differentiate this condition from other cases like "sudo ifconfig eth0 192.168.1.1 netmask 0xffffff00" where that isn't a reasonable value for your broader network and "sudo ifconfig eth0 192.168.2.1 netmask 0xffffff00" where that just so happens to be the same as what's configured now. May of the issues you speak of are creations of the semantic issues of configuration management. Here's the basic ordering that the math enforces: 1. Do the following, in parallel. They do not readily seperate. a. Figure out the semantic problems. b. Figure out the knowledge problems. 2. Arrive at something that works for your domain. Try to apply it to another domain. Watch it break. Go back to step 1. So, "model the network" is really step 1 in disguise. Understanding of your deployment characteristics is once again step 1. The question of how to avoid disabling IGP when you're using telnet that depends on routing working to perform the configuration changes is a knowledge and semantics question. Some amount of the questions of "how to produce delta statements", both at some macro level of the entire network, and the micro level of a given device are also semantic in nature. There are lot of other issues involved, but questions in the form of "how does it behave" and "how do I tell it...?" should set of bells. This is not to say that you are in an endless sea of "figure out step one first or you're doomed". Quite the opposite; take the problem apart in whatever way you find works, and there are plenty of parts out there. Hopefully some of my own examples help. I'm not sure how tall we'll have to climb to really produce satisfactory reasoning with the problem of "this" yet. The IGP example, the destroy the ip address of the interface, and many other complex "godel" looking problems in configuration come down to the presence of an implied "this" concept. For simple things like "this router", it's can be easy enough to express. Other things are probably less so. From network-automation-owner@greatcircle.com Mon Apr 11 08:18:51 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id 630F332C36F for ; Mon, 11 Apr 2005 08:18:50 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3BFJZ5C029420 for ; Mon, 11 Apr 2005 08:19:35 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3BFJUas029417 for ; Mon, 11 Apr 2005 08:19:35 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Mon, 11 Apr 2005 08:19:30 -0700 (PDT) From: Paxton To: Subject: Re: available network automation tools In-Reply-To: <7654d9d05041021497c88c860@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/16 X-Sequence-Number: 16 on network modeling, have you all come up with your own model or used something existing? Or taken something existing and modified it? I have looked at CIM and after scratching my head for a few days finally realized that I think of the network in terms of associations, and CIM is laid out by generalizations (inheritance.) The associations are defined, but are sort of hard to find because of the generalization perspective. I don't want to get into a semantics discussion of what's right, I'm more interested in being able to hand a database to a network engineer and say: go for it. IMO a db schema laid out with CIM is too confusing because it isn't laid out according to associations, which is (IMO) how network engineers (vs IT modeling guys) see things. Anyway, I have done this before and we sort of took some clues from what was available at the time (SNMP and some vendor tools.) It wasn't exactly right, but I learned a lot from the experience. We put together the database for one specific tool, then realized afterwards how much else it could be used for. I believe the core piece missing is the network model/database, consider all the other parts (how to update devices, monitoring configuration changes, etc) as component services that the database enables. Not all the component parts have to be written for the database to have value, and not everyone will want to use the same component parts. Are you all interested in starting an open source project around this? On Mon, 11 Apr 2005, Andrew Fort wrote: > On Apr 11, 2005 1:01 AM, Kirby Files wrote: > > > For us, a complete configuration management system includes: > > * a vendor-independent model of the physical and logical network > > (objects and fields describing configuration of devices, cards, > > interfaces, etc; and relationships between these objects) > > * An interface for defining this model in network engineering terms > > * definition of services in terms of component devices and logical path > > * scripts or code defining how to build configs for specific vendors > > based upon the model, connections, and applied services > > * service activation manager that can manage many simultaneous > > threads of network communication for deploying these configs in a > > transactional process > > * configuration backups, history, diffs, equipment hardware > > management, etc. > > * network auditing to ensure database accuracy > > * a database schema or API to query all fields, relationships, > > events, etc. > > > > This combination allows for the shifting of all configuration > > responsibilities from users to the CM system (now, users mostly login > > to core equipment only for troubleshooting), speeding up deployment, > > reducing errors, and improving reliability. It also serves to provide > > a true functional definition for all services frequently lacking in > > Product Mangement docs; if the product can't be reduced to a > > well-defined body of script or code, it's not baked enough to be > > called "standard". > > All spot on. I particularly like the product definition one, that has > played an important role here already - and we've only gotten to the > stage of importing network configuration into the model and > highlighting further study cases... > > The key steps and comments in building and implementing such a system, > which many are faced with doing (hence: this is a great focus for an > open source project I think :-)), are, I see (and this is the process > we're going through now where I work): > > - Model the network. In one projection of the idea, at the simplest > level you have objects and relationships (which are objects > themselves). Both of these types have attributes. It's important to > be able to map any network type that you'll need to configure, so you > probably need to store VLAN/FrDLCI information, for example. How to > map that? Perhaps some recursion is useful (a network segment object > (e.g. DLCI, VLAN) is "a member of" or "attached to" a physical link > object. IP interfaces are just mapped to a logical or physical > parent, and so on. > > The key is obviously to get a model which can represent your entire > network completely enough that you don't need to work around it. The > basic approach above will work, how far you abstract it is network > dependant. > > - Understand your deployment characteristics. You may or may not > have out-of-band management (in some and not all locations). If not, > how do you avoid cases like disabling the IGP router so that you won't > break the telnet session as the config is applied? How then, do you > perform changes to vital (e.g. management) interface configuration? > > How do you avoid such problems? "disable certain commands" > immediately comes to mind, but how can you allow certain configuration > to occur whilst disabling potentially important commands. This part > is inevitably somewhat network specific, but you may like to use > approaches to have an interface attribute such as "management". > Configuration for these interfaces is then manual. However, it may be > impossible to know of all of these cases ahead of time without an > exhaustive search (possibly related to strange loops/Godel's > incompleteness theorem?). > > Then you'll need some way of applying the config to the devices. A > device agent would be best (since we can treat the change to happen > atomically, at some particular pre-scheduled time) (cisco have such an > agent, but the interface is closed), at worst scripted-VTY access. > The latter of course has the problems spoken about above. > Scripted-console access may be a real boon, but is largely unsuitable > for many devices (CPE, small sites depending on your management > "will"), so we'll have to consider scripted VTY or similar - SNMP > configuration MIBs are not an option here (no non-v3 write (policy)), > but may be for you.. > > - Finally, enforce the model as being more important than the > element. The network element just provides reality for your network > model. Process as well as policy is needed (I encourage TAC+ command > lockouts), > > Other notes I have about the goals of the system are: > > - Configuration applied must have the same action no matter what the > initial state of the target element. This generally translates to > "bring all pre-requisite configuration along with the change". > > This is important so that you can apply partial configurations to > devices in whatever state -- many of the "big boys" who do network > configuration management presently load to startup and reload, and > their networks handle this type of management. For many of us out > there, that's not possible. > > So the model must support storing all necessary configuration (or at > least, identifying what standard templates need to be placed in what > order to build the "base config" of the device) so that both partial > and complete configurations can be formed. > > How do I know what is already configured on the device? Assume > nothing? Probably. This depends on if you want to completely trust > your database, or whether you have some trust in the existing > configuration. The more I work in this area, the less I can trust the > network configuration. > > - Allow the network operators to easily identify the change (via some > ID) that caused the most recent (or couple of most recent) change to > the element configuration. This tends to be important in helping the > NOC identify the triggers for recent change to the configuration. You > can alert people of this in other ways, e.g. via the configuration > manager itself. > > Auto-generating "banner exec" works well on cisco devices, for > example, as a sign that "the change was applied" (whether it was > successful or not, is somewhat different). > > Once the above has been nutted out, the multi-vendor hurdles are > mostly irrelevant, and all related to the "deployment characteristics" > situation above. > > -andrew > From network-automation-owner@greatcircle.com Mon Apr 11 08:44:05 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 885C032C16B for ; Mon, 11 Apr 2005 08:44:04 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 11 Apr 2005 08:44:01 -0700 To: From: Brent Chapman Subject: Re: available network automation tools Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/17 X-Sequence-Number: 17 At 3:56 PM -0500 4/8/05, Network.Security wrote: >Now, CISP / PCI on the other hand, that's the project funding behemoth >you've all been waiting for. If you need money, say it's for PCI and >poof-like-magic, here's the cash to make it happen. PCI has some fairly >strict requirements that are defined to the network level regarding open >ports, encryption schemes, use of clear-text, etc. Tools like Opsware >can help enforce or at least notify on those data points. What are CISP and PCI? >Opsware and Voyence (we demo-ed them) both do some configuration >templating so that if you are building out CPE, you can have it make >your router configs or whatever, but for already installed networks, the >templating is not valuable. I'm all about the configuration policy >piece, I want to know how many of my devices don't have enough ntp >servers configured, that sort of thing or down the road to make sure my >QoS policies are consistent across the board. But that's all to get me >to a point in time where everything is "right", it doesn't help me >deploy new services all that differently than my perl scripts did >before. If all you're using config generation for is CPE (branch office and employee home devices, for example), rather than your core systems, then I don't think you're ever going to reap the benefits that I'm contemplating. The trick, of course, is moving an existing network from manually-configured, manually-maintained (and grossly inconsistent) configurations to automated configurations without disrupting service. It's hard, but I think it can be done, and is worthwhile to do so. >What I think you are talking about is an application aware network >provisioning system. Something that is aware of all possible >topological paths between endpoints and is smart enough to know how to >configure all the hops / connections in between the two to make >something happen. Like a DOS mitigation system or punching holes >through a series of firewalls or configuring multi-hop VPN tunnels. No, I was talking about something more general, although what you're describing are examples of things ("applications", in a sense) that you could build on top of what I'm talking about. >BTW, Opsware and others would love to see this list if it grows and >utilize it as a tool for soliciting industry-wide customer feedback. I >would suggest consideration of that either for it or against (I don't >really care) and noting it in the policy. Vendors and developers are welcome to participate or lurk here, although blatant and content-free self-promotion will be met with ridicule from the audience (their potential customers). If you've got any technical or product management contacts at various relevant vendors, please let them know about the list: http://www.greatcircle.com/network-automation/ -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 08:46:10 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id EAFE032C320 for ; Mon, 11 Apr 2005 08:46:08 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 7BC3A19342; Mon, 11 Apr 2005 11:46:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16986.39872.398150.16825@perdition.linnaean.org> Date: Mon, 11 Apr 2005 11:46:08 -0400 To: Andrew Fort Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041021497c88c860@mail.gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/18 X-Sequence-Number: 18 [ Resending after majordomo decided it didn't like me. Forgive me if you've seen this before. ] > Configuration for these interfaces is then manual. However, it may be > impossible to know of all of these cases ahead of time without an > exhaustive search (possibly related to strange loops/Godel's > incompleteness theorem?). "It depends". On one extreme, you limit the language you can speak, preventing the ugly cases, consequently limiting the capability of your model. On the other is no restriction, with a resultingly more expressive model, but with halting trouble if the user doesn't use it well. Personally, I'm for being allowed to shoot myself in the head if that's what I said to do, but getting to a model that allows me to both shoot myself in the head and have the computer warn me that "by the way, you might want to know that saying 'twiddle the flubbypux into state 29' may mean 'shoot yourself and twenty friends in the head'" is a little bit of work. Witness my example from a few days ago on infrastructures: the addresses within a subnet are numbers. I don't mean that in the obvious sense (being 32 bit numbers), I mean that in a more subtle one. If you allow the user of your configuration system to operate on these numbers in arbitrary ways and define functions on them (which you pretty much have to do in order to give them what they need), you're giving them the very tools they need to create halting problems. In the case of network engineering, your semantic and reflection problems with reasoning with loops is relatively easy. Consider the case of destroying the only path to talk to a computer (not terribly different from a router in this simple example). Assuming a linux machine, and we were sitting at some other host in our network, typing something like the following is an instance of the statement class we are concerned with: $ ssh host-thats-gonna-die $ sudo ifconfig eth0 0 where once authenticate2 completes, the deed is done. What we want to be able to do is equate the above statement with the notion of destroying our ability to reach hosts-thats-gonna-die from wherever we started from (and if our network has reasonable transitive properties, no host can reach it). This is "simple", for an annoying value of simple. It mostly comes down to being able to compute the meaning of each statement in a reasonably large size world (one thats as large as your network). In particular, you need to be able to reason with how "sudo ifconfig eth0 0" transmitted to our victim host is going to side effect the network configuration of the victim such that it would be unreachable to the broader world. Somehow differentiate this condition from other cases like "sudo ifconfig eth0 192.168.1.1 netmask 0xffffff00" where that isn't a reasonable value for your broader network and "sudo ifconfig eth0 192.168.2.1 netmask 0xffffff00" where that just so happens to be the same as what's configured now. May of the issues you speak of are creations of the semantic issues of configuration management. Here's the basic ordering that the math enforces: 1. Do the following, in parallel. They do not readily seperate. a. Figure out the semantic problems. b. Figure out the knowledge problems. 2. Arrive at something that works for your domain. Try to apply it to another domain. Watch it break. Go back to step 1. So, "model the network" is really step 1 in disguise. Understanding of your deployment characteristics is once again step 1. The question of how to avoid disabling IGP when you're using telnet that depends on routing working to perform the configuration changes is a knowledge and semantics question. Some amount of the questions of "how to produce delta statements", both at some macro level of the entire network, and the micro level of a given device are also semantic in nature. There are lot of other issues involved, but questions in the form of "how does it behave" and "how do I tell it...?" should set of bells. This is not to say that you are in an endless sea of "figure out step one first or you're doomed". Quite the opposite; take the problem apart in whatever way you find works, and there are plenty of parts out there. Hopefully some of my own examples help. I'm not sure how tall we'll have to climb to really produce satisfactory reasoning with the problem of "this" yet. The IGP example, the destroy the ip address of the interface, and many other complex "godel" looking problems in configuration come down to the presence of an implied "this" concept. For simple things like "this router", it's can be easy enough to express. Other things are probably less so. From network-automation-owner@greatcircle.com Mon Apr 11 09:15:38 2005 X-Original-To: network-automation@greatcircle.com Received: from iad2smtpout02.target.com (smtpout03.target.com [161.225.129.10]) by mycroft.greatcircle.com (Postfix) with ESMTP id 125EE32C36D for ; Mon, 11 Apr 2005 09:15:37 -0700 (PDT) Received: from emailhub03.target.com ([10.114.73.110]) by iad2smtpout02.target.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:15:36 -0500 Received: from EMAILSTORE13.target.com ([10.114.81.32]) by emailhub03.target.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:15:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: available network automation tools Date: Mon, 11 Apr 2005 11:15:34 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: available network automation tools Thread-Index: AcU+rU+zA/Us/xdzSSqbTA5LF4UxqQAAbHKQ From: "Network.Security" To: X-OriginalArrivalTime: 11 Apr 2005 16:15:35.0927 (UTC) FILETIME=[B1932070:01C53EB1] X-Archive-Number: 200504/19 X-Sequence-Number: 19 >What are CISP and PCI? CISP =3D Cardholder Information Security Program (Visa specific) and PCI = =3D Payment Card Industry Data Security Standard. These govern the security of credit cardholder data, the transmission of that data, the security practices and polices around it, etc. This was an effort started by Visa and later adopted by the major CC companies into a consolidated security audit. Companies that process CC data are evaluated and later penalized if they do not meet criteria within a given timeframe. The penalties can be navigated around if you present a solid plan, that sort of thing. Further, it outlines minimum financial penalties for security breaches and release of CC data (aka hacked accounts). For retailers and other entities that depend on CC data, this is huge. For an industry audit, it's fairly detailed in that it talks about specific TCP ports, encryption schemes, etc. Info at: www.visa.com/cisp =20 My comments re: SOX were not meant to imply that it doesn't matter, more that there are multiple sources of funding for compliance related projects, some may be more applicable than others. - Scott scott.altman@target.com From network-automation-owner@greatcircle.com Mon Apr 11 16:11:51 2005 X-Original-To: Network-Automation@GreatCircle.COM Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 021DE32C4D2 for ; Mon, 11 Apr 2005 16:11:50 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 11 Apr 2005 16:11:46 -0700 To: Network-Automation@GreatCircle.COM From: Brent Chapman Subject: NetML? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/20 X-Sequence-Number: 20 At 8:05 AM -0700 4/9/05, max.reid@saikonetworks.com wrote: >There certainly isn't a cfengine type application for multivendor >network devices, but with cisco Incorporating Tcl shells and >precompilers in IOS, F5 using a Tcl shell to replace their >proprietary scripting language, There just needs to be an Open >Reference model or XML schema to describe device functions... I >don't think we're there yet. Has anybody take a look at NetML? http://giga.dia.uniroma3.it/~ivan/NetML/intro.html NetML is a network description/configuration markup language. It is based on the eXtensible Markup Language (XML). Its main aims are to describe a network at Autonomous System level or at a lower level (i.e. ISO-OSI level 2) and to be able to configure Cisco, Juniper or Zebra routers. Using the eXtensible Stylesheet Language Transformations, it is possible to produce the configuration files for the various types of routers. The tools produced in this project allow the writing of the NetML file (using a browser) and the production of the configuration files for the various constructors starting from the NetML file. See also: http://www.ripe.net/ripe/meetings/ripe-47/eof.html#netml http://www.netkit.org/ -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 16:15:14 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 1673432C4D8; Mon, 11 Apr 2005 16:15:13 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 11 Apr 2005 16:15:10 -0700 To: Paxton , Kirby Files From: Brent Chapman Subject: Re: available network automation tools Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/21 X-Sequence-Number: 21 At 8:17 AM -0700 4/9/05, Paxton wrote: > >> And the importance of having a queryable >network model cannot be overstated. This has become the core of our >OSS systems > >exactly. The vendor CM tools I've looked at all miss the boat in this >regard. I don't want a bunch of one-hit-wonder tools, I want >a foundation we can build from. Hear, hear! This is the sort of thing I've been thinking about, too. >I'm not sure any of these guys will get >it right because they are going after what sells to the CIO, and the >queryable network model is not sellable at that level (or so I'm told.) Perhaps not directly sellable, but the features and benefits of tools built atop such a model (modularity, expandability, consistency, predictability, efficiency, etc.) ought to be. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 16:30:23 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7DE4A32C4DC; Mon, 11 Apr 2005 16:30:21 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <42593FE4.7030901@gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> Date: Mon, 11 Apr 2005 16:30:18 -0700 To: Kirby Files , Aaron Glenn From: Brent Chapman Subject: Re: available network automation tools Cc: network-automation@greatcircle.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/22 X-Sequence-Number: 22 At 11:01 AM -0400 4/10/05, Kirby Files wrote: >Aaron Glenn wrote on 04/09/2005 08:45 PM: > > Perhaps it's the cleaning fluid fumes in my apartment today, but I'm >> having trouble fully grasping what you're describing there. Can you >> take it down a notch to laymens terms? > >For us, a complete configuration management system includes: > * a vendor-independent model of the physical and logical network >(objects and fields describing configuration of devices, cards, >interfaces, etc; and relationships between these objects) In other words, we want a model that represents information like: - Device D1 contains cards C1, C2, and C3 - Card C1 on Device X has ports P1, P2, P3, and P4 of type Y - Port P1 on Card C1 on Device D1 is a 100 Mb/s Ethernet port - Port P1 on Card C1 on Device D1 is connected to network N1 - Network N1 is 192.168.1.0/24 - Port P1 on Card C1 on Device D1 is 192.168.1.1/24 And so forth, in as much detail as you want, for all the various parts of your network. > * An interface for defining this model in network engineering terms In other words, an interface that lets you do things like - Add Device - Add Card to Device - Add Port to Card - Add Network - Describe connection from Port to Network etc. > * definition of services in terms of component devices and logical path I think I know what Kirby is talking about here, but I can't think of a simple example. > * scripts or code defining how to build configs for specific vendors >based upon the model, connections, and applied services In other words, code that knows how to generate a config file for Device D1 if that device is a Cisco, based on data drawn from the model. The code has to be able to extract information from the model such as: - What make/model of device is D1? - What interfaces exist on D1? - What ports are in use on those interfaces? - What networks are those ports connected to? - What are the characteristics/parameters of those connections? > * service activation manager that can manage many simultaneous >threads of network communication for deploying these configs in a >transactional process At this point, we move beyond the model to the actual ability to deploy configurations derived from the model. In other words, I conceptually separate the problem into two parts: 1) What should the configs be for each device? 2) How do I get those configs onto those devices? > * configuration backups, history, diffs, equipment hardware >management, etc. In other words, the ability to answer questions like: - What was the configuration of device D1 yesterday, before we changed things and started having problems? - How many unused card slots are there in device D1? - How many unused ports are there on Card C1 in device D1? > * network auditing to ensure database accuracy In other words, "is my model of the network accurate?" > * a database schema or API to query all fields, relationships, >events, etc. So that you can write the code to generate the configs for the devices, as well as generate configs for related tools like SNMP monitors (Cricket, etc.), system status monitors (Nagios, etc.) >This combination allows for the shifting of all configuration >responsibilities from users to the CM system (now, users mostly login >to core equipment only for troubleshooting), speeding up deployment, >reducing errors, and improving reliability. It also serves to provide >a true functional definition for all services frequently lacking in >Product Mangement docs; if the product can't be reduced to a >well-defined body of script or code, it's not baked enough to be >called "standard". Yup. > > What is a "queryable network model" ? > >Well, as described above, the network model is a database that is >capable of describing what the equipment is, how it is configured, and >how devices are connected to each other. It includes the network >topologies and hierarchy, logical connections, IP subnets, routing >policies, physical components, etc. > >For us, the key has been to keeps the schema for the model defined not >in the management software or static database tables, but a NetEng >modifiable syntax that can be quickly changed to add new concepts, >hardware, and services. Yes, this is important; it's got to be extendable, because you aren't going to think of everything up front. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 16:35:29 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 0C2CA32C4D8; Mon, 11 Apr 2005 16:35:28 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 11 Apr 2005 16:35:25 -0700 To: Paxton , From: Brent Chapman Subject: Re: available network automation tools Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/23 X-Sequence-Number: 23 At 8:19 AM -0700 4/11/05, Paxton wrote: >on network modeling, have you all come up with your own model or used >something existing? Or taken something existing and modified it? > >I have looked at CIM and after scratching my head for a few days finally >realized that I think of the network in terms of associations, and CIM is >laid out by generalizations (inheritance.) The associations are defined, >but are sort of hard to find because of the generalization perspective. I >don't want to get into a semantics discussion of what's right, I'm more >interested in being able to hand a database to a network engineer and say: >go for it. IMO a db schema laid out with CIM is too confusing because it >isn't laid out according to associations, which is (IMO) how network >engineers (vs IT modeling guys) see things. Can you point us to any references for CIM? I'm not familiar with it. >Anyway, I have done this before and we sort of took some clues from what >was available at the time (SNMP and some vendor tools.) It wasn't exactly >right, but I learned a lot from the experience. We put together the >database for one specific tool, then realized afterwards how much else it >could be used for. I believe the core piece missing is the network >model/database, consider all the other parts (how to update devices, >monitoring configuration changes, etc) as component services that the >database enables. Not all the component parts have to be written for the >database to have value, and not everyone will want to use the same >component parts. Bingo! I've been thinking much the same thing... >Are you all interested in starting an open source project around this? I don't know about anybody else, but I certainly am. I think that such a "network database" would then become a platform upon which much else could and would be built; like you said, though, it's currently the core missing piece. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 16:37:28 2005 X-Original-To: network-automation@greatcircle.com Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.200]) by mycroft.greatcircle.com (Postfix) with ESMTP id 48EBF32C4DE for ; Mon, 11 Apr 2005 16:37:27 -0700 (PDT) Received: by zproxy.gmail.com with SMTP id 12so480899nzp for ; Mon, 11 Apr 2005 16:37:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=TdErcJEgpjw+8d8KtouvSCQvJ0GR8YkIIi1qsybo4K1uQxknwDtC4SswLDf+batQd45sCouHiREQN6A4XlDs664t5zlSdaZiwo1pXRP4aI/Badsm0er7pUo4LdObd53EzNj0QbnYR4SBWsJo48TaMdOvOoIalGDJizdWO/qVwnA= Received: by 10.36.80.17 with SMTP id d17mr218327nzb; Mon, 11 Apr 2005 16:37:25 -0700 (PDT) Received: by 10.36.67.1 with HTTP; Mon, 11 Apr 2005 16:37:25 -0700 (PDT) Message-ID: <18f6019405041116371c27f131@mail.gmail.com> Date: Mon, 11 Apr 2005 16:37:25 -0700 From: Aaron Glenn Reply-To: Aaron Glenn To: Brent Chapman Subject: Re: available network automation tools Cc: network-automation@greatcircle.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> X-Archive-Number: 200504/24 X-Sequence-Number: 24 On Apr 11, 2005 4:30 PM, Brent Chapman wrote: > > Yes, this is important; it's got to be extendable, because you aren't > going to think of everything up front. > Can one model a network in such a way ontop of SQL, or is there a better (easier/more extensible/effecient) way? aaron.glenn From network-automation-owner@greatcircle.com Mon Apr 11 16:42:09 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id CD23B32C4E1; Mon, 11 Apr 2005 16:42:08 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <18f6019405041116371c27f131@mail.gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <18f6019405041116371c27f131@mail.gmail.com> Date: Mon, 11 Apr 2005 16:42:05 -0700 To: Aaron Glenn From: Brent Chapman Subject: Re: available network automation tools Cc: network-automation@greatcircle.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/25 X-Sequence-Number: 25 At 4:37 PM -0700 4/11/05, Aaron Glenn wrote: >On Apr 11, 2005 4:30 PM, Brent Chapman wrote: >> >> Yes, this is important; it's got to be extendable, because you aren't >> going to think of everything up front. >> > >Can one model a network in such a way ontop of SQL, or is there a >better (easier/more extensible/effecient) way? I don't know. It would seem to me that being _able_ to represent your network model in SQL is a worthwhile goal, but I'm not sure if the constraints imposed by SQL would force too many compromises in the model. I'd be tempted to model the data structures and relationships in the abstract, and then figure out how to represent those in SQL (or any other tool, including plain text). -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Mon Apr 11 16:45:34 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id 6B78732C4A9; Mon, 11 Apr 2005 16:45:33 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3BNkK5C000253; Mon, 11 Apr 2005 16:46:20 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3BNkJqE000250; Mon, 11 Apr 2005 16:46:19 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Mon, 11 Apr 2005 16:46:19 -0700 (PDT) From: Paxton To: Brent Chapman Cc: Subject: Re: available network automation tools In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/26 X-Sequence-Number: 26 sure thing... http://www.dmtf.org/standards/cim/ I have heard that cisco makes use of cim in something they are doing, possibly this: http://www.cisco.com/en/US/products/sw/netmgtsw/ps4748/products_programming_usage_guide_chapter09186a00801e18e6.html but I don't know for sure. CIM has also been debated in the netconf discussions: http://www.ietf.org/html.charters/netconf-charter.html On Mon, 11 Apr 2005, Brent Chapman wrote: > At 8:19 AM -0700 4/11/05, Paxton wrote: > >on network modeling, have you all come up with your own model or used > >something existing? Or taken something existing and modified it? > > > >I have looked at CIM and after scratching my head for a few days finally > >realized that I think of the network in terms of associations, and CIM is > >laid out by generalizations (inheritance.) The associations are defined, > >but are sort of hard to find because of the generalization perspective. I > >don't want to get into a semantics discussion of what's right, I'm more > >interested in being able to hand a database to a network engineer and say: > >go for it. IMO a db schema laid out with CIM is too confusing because it > >isn't laid out according to associations, which is (IMO) how network > >engineers (vs IT modeling guys) see things. > > Can you point us to any references for CIM? I'm not familiar with it. > > >Anyway, I have done this before and we sort of took some clues from what > >was available at the time (SNMP and some vendor tools.) It wasn't exactly > >right, but I learned a lot from the experience. We put together the > >database for one specific tool, then realized afterwards how much else it > >could be used for. I believe the core piece missing is the network > >model/database, consider all the other parts (how to update devices, > >monitoring configuration changes, etc) as component services that the > >database enables. Not all the component parts have to be written for the > >database to have value, and not everyone will want to use the same > >component parts. > > Bingo! I've been thinking much the same thing... > > >Are you all interested in starting an open source project around this? > > I don't know about anybody else, but I certainly am. I think that > such a "network database" would then become a platform upon which > much else could and would be built; like you said, though, it's > currently the core missing piece. > > > -Brent > -- > Brent Chapman -- Great Circle Associates, Inc. > Specializing in network infrastructure for Silicon Valley since 1989 > For info about us and our services, please see http://www.greatcircle.com/ > Network Automation blog: http://www.greatcircle.com/blog/network_automation > From network-automation-owner@greatcircle.com Mon Apr 11 18:05:53 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7592B32C4DB for ; Mon, 11 Apr 2005 18:05:52 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1357587rna for ; Mon, 11 Apr 2005 18:05:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YYj1lQg7xAcgTH9pJqpzppOBd0EPvR70ZW2xg5g75klJqp/QwmSWFpcW+OQxMhEgmLhqqyJJegUUNHPHN3jIBgK7qxBTiXuD97oiWUWTszJ0tZb9VUwkxXmSp2CDuBAKlwAiVNd5ftcxM6gY/ycjyjPnFVXJyk8w+RhL4Y5avsA= Received: by 10.38.90.49 with SMTP id n49mr370903rnb; Mon, 11 Apr 2005 18:05:51 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Mon, 11 Apr 2005 18:05:51 -0700 (PDT) Message-ID: <7654d9d05041118057c4ed5fa@mail.gmail.com> Date: Tue, 12 Apr 2005 11:05:51 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Daniel Hagerty Subject: Re: available network automation tools Cc: network-automation@greatcircle.com In-Reply-To: <16986.6174.403374.979347@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> <16986.6174.403374.979347@perdition.linnaean.org> X-Archive-Number: 200504/27 X-Sequence-Number: 27 On Apr 11, 2005 4:24 PM, Daniel Hagerty wrote: > I'm not sure how tall we'll have to climb to really produce > satisfactory reasoning with the problem of "this" yet. And that's the heart of it. Routing protocols suggest a common "this" (the IGP configuration), and the mixing of syntax and semantics got me re-reading "godel, escher, bach". > The IGP example, the destroy the ip address of the interface, and many > other complex "godel" looking problems in configuration come down to > the presence of an implied "this" concept. For simple things like > "this router", it's can be easy enough to express. Other things are > probably less so. Our approach is inherently "network" specific (i mean, "my network" versus "your network"), because the semantics of this network are tied up in the syntax of our language of abstraction. When you solve the problem, some of the lessons learned may be useful for me, but some will undoubtedly be overly simplistic or not complex enough to avoid unwanted looping or halting states. Beauty in the world is such a difficult thing when you just want to automate your network! -andrew From network-automation-owner@greatcircle.com Mon Apr 11 20:29:46 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 3A33532C338; Mon, 11 Apr 2005 20:29:45 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id D15FF19344; Mon, 11 Apr 2005 23:29:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.16543.735569.79861@perdition.linnaean.org> Date: Mon, 11 Apr 2005 23:29:35 -0400 To: Brent Chapman Cc: Aaron Glenn , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <18f6019405041116371c27f131@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/28 X-Sequence-Number: 28 > I'd be tempted to model the data structures and relationships in the > abstract, and then figure out how to represent those in SQL (or any > other tool, including plain text). Your temptation is good intuition; listen to it. Producing something concrete like a SQL model is effectively syntax -- something you never want to do first. Producing the model and using it to produce represenations from it (be they text, sql, or whatever) works better. Also, this approach allows you to leverage the strenghts of each tool as appropriate; if your model can be represented either as text or SQL, you can presumbably convert between the two forms as needed. For example, SQL is good for structured search, whereas text can be better for a mostly undirected browse. From network-automation-owner@greatcircle.com Mon Apr 11 21:09:36 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id EBCB732C2C2 for ; Mon, 11 Apr 2005 21:09:26 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3C4AC5C000469; Mon, 11 Apr 2005 21:10:12 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3C4ABdP000464; Mon, 11 Apr 2005 21:10:12 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Mon, 11 Apr 2005 21:10:11 -0700 (PDT) From: Paxton To: "Network.Security" Cc: Subject: Re: available network automation tools In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/29 X-Sequence-Number: 29 Scott - do you guys use this as well: http://www.opnet.com/products/itsentinel/ITSentinel.pdf I noticed you are from target and they list target as a customer. from their site it looks like they started out as a predictive analysis sort of thing, but also have some config mgt, possibly added later??? If you do use it, can you comment on it? thanks! On Fri, 8 Apr 2005, Network.Security wrote: > OK, I'll bite. > > We use Rendition (now Opsware) for config mgmt. of our network stuff and > the change detection / archival function has already saved my butt a > number of times. Our engineers gripe about the Big-Brother aspect, but > per the quasi-rant about SOX / CISP / PCI it's a fact of life now for > any SEC-filing corp at a minimum. > > I realize this is somewhat OT for this list, but SOX (in general) > shouldn't really matter to network admins (network meaning L1 to ~L4), > as SOX is all about altering the financial data. As a network person, > you can certainly see all of that data, but you can't change it (packet > injection doesn't count, most apps pick up on that sort of activity even > if they don't know why they know :) For that you need to be a server > admin / DBA, so for true network people, we don't really care. (Loose > generalization there. Re: caring) > > As for Opsware, their SOX report is static. It doesn't tell you > anything. It's just text so the tool offers no value to that. > > Now, CISP / PCI on the other hand, that's the project funding behemoth > you've all been waiting for. If you need money, say it's for PCI and > poof-like-magic, here's the cash to make it happen. PCI has some fairly > strict requirements that are defined to the network level regarding open > ports, encryption schemes, use of clear-text, etc. Tools like Opsware > can help enforce or at least notify on those data points. > > Re: free tools, I think we've all heard of RANCID as a config-o-monitor > (I personally am CVS debilitated and have not yet been able to make it > work on any platform). Big companies do not like free tools. That's > why Linux was not making progress in large enterprises until we could > start paying for it (aka Red Hat). If they can't get maintenance / > support for something that the business needs, it's not coming into the > environment. This makes sense, though not really from a "help us stay > on the cutting-edge of technology aspect". > > Opsware and Voyence (we demo-ed them) both do some configuration > templating so that if you are building out CPE, you can have it make > your router configs or whatever, but for already installed networks, the > templating is not valuable. I'm all about the configuration policy > piece, I want to know how many of my devices don't have enough ntp > servers configured, that sort of thing or down the road to make sure my > QoS policies are consistent across the board. But that's all to get me > to a point in time where everything is "right", it doesn't help me > deploy new services all that differently than my perl scripts did > before. > > What I think you are talking about is an application aware network > provisioning system. Something that is aware of all possible > topological paths between endpoints and is smart enough to know how to > configure all the hops / connections in between the two to make > something happen. Like a DOS mitigation system or punching holes > through a series of firewalls or configuring multi-hop VPN tunnels. > Yeah, that doesn't exist as far as I know. Or more to the point, I'm > sure these tools could do that, but the work required on the front-end > won't end up saving you anything on the back-end. Oh and it has to be > vendor-agnostic. Heh. > > That market is more in the NetDoctor or related simulation style > configuration analyzers that do the what-if type stuff or there are a > couple other QoS policers out there that do something similar, but they > are niche market tools for QoS only and appliances at that. > > So to your question, No would be my answer, there isn't something like > that out there today, there are point solutions that solve particular > aspects of the overall issue, but nothing end-to-end. > > BTW, Opsware and others would love to see this list if it grows and > utilize it as a tool for soliciting industry-wide customer feedback. I > would suggest consideration of that either for it or against (I don't > really care) and noting it in the policy. > > Scott.altman@target.com > > From network-automation-owner@greatcircle.com Mon Apr 11 22:18:12 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id A51A232C50C for ; Mon, 11 Apr 2005 22:18:11 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 335B219344; Tue, 12 Apr 2005 01:18:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.23050.77047.3526@perdition.linnaean.org> Date: Tue, 12 Apr 2005 01:18:02 -0400 To: Andrew Fort Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041118057c4ed5fa@mail.gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> <16986.6174.403374.979347@perdition.linnaean.org> <7654d9d05041118057c4ed5fa@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/30 X-Sequence-Number: 30 > Our approach is inherently "network" specific (i mean, "my network" > versus "your network"), because the semantics of this network are tied > up in the syntax of our language of abstraction. When you solve the > problem, some of the lessons learned may be useful for me, but some > will undoubtedly be overly simplistic or not complex enough to avoid > unwanted looping or halting states. You seem to misunderstand the actual scope of my hammer, but then, I haven't shown you my hammer, so this is obviously my error. I'm not actually coming at this from network configuration land; I'm coming from some place that is somewhat harder in one key aspect: non-commodity software staging. Networks don't change vocabulary as often as bleeding edge new software does. This change stresses configuration generation concepts enormously. I had to go back to the blackboard for a little bit in order to think about what's going on with software staging. But anyway... What I would like to give you should have "well formed" semantics where termination of the base cases is promised by the semantic. If I can't deliver on this, I have nothing. Given such a promise, nothing prevents you from mis-expressing your domain as non-terminating in all or only some conditions. Programming is programming, as always. I would like to give you all is a means of description of semantics and knowledge "issues". Solutions to my own problem requires such a means. However, keep in mind that my code is a very small thing; it isolates a key pattern that will always be, but your problem is still your own. I just give you a framework for the common pattern your problem always falls into and provide means to relate how your program interacts with the broader world. As network operators, you want something that deals in your own domain; this code is not in that domain. You make the domain of networks out of other domains, all of which eventually come down to the domain of domains. What I have in hand is something like a recursion combinator. It's not a recursion combinator, in that a recursion combinator typically enables recursion and no more. This combinator mixes the recursion concept with a multiplexing concept. Logical "today"'s project (which will probably not happen today) is to produce a pair of mutually recursive functions that express this mutual recursion within my framework. Producing this is likely to exercise the multiplexing portion of the combinator in some fashion or another. The only example I've had time to write at this layer only exercises recursion. Obviously, this seems to have little to do with "can I program my cisco router with that?". Like I said, there was a bit of going back to the blackboard involved. Code, examples, prior art refrences, etc, etc available upon request, as long as you keep in mind that it's all a work in progress, and it's very early in the game. I'll mention that asking me "how would you reason with...?" sounds like a fun game to play, and would be helpful for me in finding many people's different examples. From network-automation-owner@greatcircle.com Tue Apr 12 01:20:59 2005 X-Original-To: network-automation@greatcircle.com Received: from gate.epygi.de (gate.epygi.de [212.126.211.241]) by mycroft.greatcircle.com (Postfix) with ESMTP id D20A332C514 for ; Tue, 12 Apr 2005 01:19:16 -0700 (PDT) Received: from NBGIO2 (nb-gio2.epygi.de [10.20.0.21]) by gate.epygi.de (8.13.3/8.13.3) with ESMTP id j3C8K73V021334 for ; Tue, 12 Apr 2005 10:20:09 +0200 (METDST) From: "Georg Magschok" To: Subject: Re: available network automation tools Date: Tue, 12 Apr 2005 10:22:45 +0200 Organization: Epygi Labs DE GmbH Message-ID: <002101c53f38$d186d480$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Archive-Number: 200504/31 X-Sequence-Number: 31 > >Are you all interested in starting an open source project around this? > I don't know about anybody else, but I certainly am. I think that > such a "network database" would then become a platform upon which > much else could and would be built; like you said, though, it's > currently the core missing piece. Coming from network management development for ATM switches and VoIP boxes, I'd like to share an idea that I'm going to implement sooner or later and would like to see approved as "not wrong": "The semantics of a network model should be defined by the network elements!" The reason is rather simple: Either a network management system needs an awful amount of information about a network that it should work on (and this would either need to be standardized into the last little detail or manually entered by admins), or the network must be able to provide information about itself. Currently I'm merely waiting for a standard to support that approach, or a few global players to start using something like it. Examples: a) the stone-age SNMP approach to this: a private MIB is generated from within the sources of device-firmware and distributed by a device to its managers to be compiled and give the admin access to configuration/accounting/security/fault/performance information that exceeds the public MIBs. [no semantics in this approach other than the textual decriptions of Managed Objects] b) in the XML-world the managed entity would be capable of producing a Schema for it's management data (Preferrably precompiled, but on strong, complicated network elements it may be dynamically generated). I hoped that Netconf or CIM would sooner or later define this. Transportation using the Netconf drafts is fine, though. (Yes, NetML could be a syntax to use for this) c) web based management is already quite near this approach, (because it keeps much of the intelligence for device control inside of the devices) but it has far too many proprietary variants, and automating it is messy. (maybe WBEM could help here, but I didn't look into that so far) In other words: I believe that trying to build management software that tries to manage everything is fine for today's applications, but for the future it would be easier to handle this by offloading information from that management software to the devices/elements/CPE, using a standardized approach. Can anybody comment if this is completely stupid or has been done already or may be a useful approach? Thanks, Gio Epygi Labs DE GmbH - Georg 'Gio' Magschok From network-automation-owner@greatcircle.com Tue Apr 12 01:24:11 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8FCAB32C351 for ; Tue, 12 Apr 2005 01:23:02 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id a41so1460846rng for ; Tue, 12 Apr 2005 01:24:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=GA3TtKk1FlcjVClAz6mo2GBqK5S13XhD6P1pnjrMUELqePaaPTTawDPcoewcCtTIrYRpp9Z5miCEeV9w3UMThVbyv/yncOyjlABw4ZBk+wFHORDBeKo/SqldvUvXGNgRWUatl1Bw1cklE+yd36QH+6zF7SLB9YaIn3yXNmv/Zrw= Received: by 10.38.153.43 with SMTP id a43mr4774311rne; Tue, 12 Apr 2005 01:24:06 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Tue, 12 Apr 2005 01:24:06 -0700 (PDT) Message-ID: <7654d9d05041201245c28db72@mail.gmail.com> Date: Tue, 12 Apr 2005 18:24:06 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Daniel Hagerty Subject: Re: available network automation tools Cc: network-automation@greatcircle.com In-Reply-To: <16987.23050.77047.3526@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> <16986.6174.403374.979347@perdition.linnaean.org> <7654d9d05041118057c4ed5fa@mail.gmail.com> <16987.23050.77047.3526@perdition.linnaean.org> X-Archive-Number: 200504/32 X-Sequence-Number: 32 On Apr 12, 2005 3:18 PM, Daniel Hagerty wrote: > Code, examples, prior art refrences, etc, etc available upon > request, as long as you keep in mind that it's all a work in progress, > and it's very early in the game. Prior art sounds good. I've really been enjoying some of the reading (as well as your insight) in this area lately, and I can always add to my reading list. -andrew From network-automation-owner@greatcircle.com Tue Apr 12 05:26:29 2005 X-Original-To: network-automation@greatcircle.com Received: from mail-white.research.att.com (mail-red.research.att.com [192.20.225.110]) by mycroft.greatcircle.com (Postfix) with ESMTP id 9C15132C54C for ; Tue, 12 Apr 2005 05:26:28 -0700 (PDT) Received: from light.research.att.com (light.research.att.com [135.207.27.144]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id j3CCQ9320847; Tue, 12 Apr 2005 08:26:10 -0400 (EDT) Date: Tue, 12 Apr 2005 08:26:09 -0400 From: Albert Greenberg To: Georg Magschok Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <002101c53f38$d186d480$1500140a@EPYGI.DE> Message-ID: References: <002101c53f38$d186d480$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/33 X-Sequence-Number: 33 On Tue, 12 Apr 2005, Georg Magschok wrote: > > Coming from network management development for ATM switches and VoIP > boxes, I'd like to share an idea that I'm going to implement sooner or > later and would like to see approved as "not wrong": > > "The semantics of a network model should be defined by the network > elements!" > I think you are right, though the level of abstraction providedd by the network elements may be quite low if you want network-wide rather than box by box management. For example, ACLs can provide network-wide perimeter defense, with appropriate clauses embedded in the edge routers. It's all there in the routers, but it is not expressed directly as a network-wide constraint (which might help manage ACLs). Albert Greenberg; AT&T Labs-Research; Florham Park, NJ 07932-0971 From network-automation-owner@greatcircle.com Tue Apr 12 05:59:30 2005 X-Original-To: network-automation@greatcircle.com Received: from gate.epygi.de (gate.epygi.de [212.126.211.241]) by mycroft.greatcircle.com (Postfix) with ESMTP id 04C0432C357 for ; Tue, 12 Apr 2005 05:59:29 -0700 (PDT) Received: from NBGIO2 (nb-gio2.epygi.de [10.20.0.21]) by gate.epygi.de (8.13.3/8.13.3) with ESMTP id j3CCxRW3022807; Tue, 12 Apr 2005 14:59:27 +0200 (METDST) From: "Georg Magschok" To: "'Albert Greenberg'" Cc: Subject: Re: available network automation tools Date: Tue, 12 Apr 2005 15:02:04 +0200 Organization: Epygi Labs DE GmbH Message-ID: <002601c53f5f$d62f6340$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Archive-Number: 200504/34 X-Sequence-Number: 34 > > "The semantics of a network model should be defined by the network > > elements!" > I think you are right, though the level of abstraction providedd by the > network elements may be quite low if you want network-wide rather than box > by box management. For example, ACLs can provide network-wide perimeter > defense, with appropriate clauses embedded in the edge routers. It's all > there in the routers, but it is not expressed directly as a network-wide > constraint (which might help manage ACLs). The node would know well about itself, but not too much about the network other than it's direct box by box relations or being part of various kinds of peer groups. The network-wide constraints are not solved by the approach I propose, only supported. Thank you! Gio Epygi Labs DE GmbH - Georg 'Gio' Magschok From network-automation-owner@greatcircle.com Tue Apr 12 07:23:18 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id 2346732C2BC; Tue, 12 Apr 2005 07:23:11 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:22:30 -0500 Message-ID: <425BD965.5020306@gmail.com> Date: Tue, 12 Apr 2005 10:21:25 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brent Chapman Cc: Aaron Glenn , network-automation@greatcircle.com Subject: Re: available network automation tools References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 14:22:30.0854 (UTC) FILETIME=[0FC4E660:01C53F6B] X-Archive-Number: 200504/35 X-Sequence-Number: 35 Brent Chapman wrote on 04/11/2005 07:30 PM: > At 11:01 AM -0400 4/10/05, Kirby Files wrote: >> * An interface for defining this model in network engineering terms > > In other words, an interface that lets you do things like > > - Add Device > - Add Card to Device > - Add Port to Card > - Add Network > - Describe connection from Port to Network Not only that, but also to define new types of devices and connections for the model itself. >> * definition of services in terms of component devices and logical path > > I think I know what Kirby is talking about here, but I can't think of a > simple example. Well, as an example, we offer a VPLS service, which in our network topology consists of a VPLS switching domain described by a VPLS Connection Record; some number of VPLS terminations on Provider Edge (PE) routers, including both a set of ports in the local switching domain, traffic shaping policies, and Forwarding Database (FDB) policies; and a mapping to the Provider (P) router core LSP mesh. The metadata that describes to collection of objects, attributes and relation is the services model for VPLS. > At this point, we move beyond the model to the actual ability to deploy > configurations derived from the model. In other words, I conceptually > separate the problem into two parts: > > 1) What should the configs be for each device? > 2) How do I get those configs onto those devices? And (3) How can we tell if the config *can* be applied to the device (no conflicting assignments; preconditions met); and (4) How can we tell that the configuration was successfully applied, and how to we back out the configuration on all other affected devices if not? >> For us, the key has been to keeps the schema for the model defined not >> in the management software or static database tables, but a NetEng >> modifiable syntax that can be quickly changed to add new concepts, >> hardware, and services. > > Yes, this is important; it's got to be extendable, because you aren't > going to think of everything up front. Yup, and in particular, it has to be easily extensible by non-programmer types. So I created a metadata syntax that Engineers can use to define the model, that is later compiled into an object model. At this point, more than half of the man-hours in the system have come not from the programmers, but from the work of NetEng modifying the network model to suit their needs. This allows rapid change outside of product delivery timelines. --kirby From network-automation-owner@greatcircle.com Tue Apr 12 07:39:32 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5313632C557; Tue, 12 Apr 2005 07:38:04 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:37:24 -0500 Message-ID: <425BDCE3.6010904@gmail.com> Date: Tue, 12 Apr 2005 10:36:19 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Glenn Cc: Brent Chapman , network-automation@greatcircle.com Subject: Re: available network automation tools References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <18f6019405041116371c27f131@mail.gmail.com> In-Reply-To: <18f6019405041116371c27f131@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 14:37:25.0009 (UTC) FILETIME=[24BA2010:01C53F6D] X-Archive-Number: 200504/36 X-Sequence-Number: 36 Aaron Glenn wrote on 04/11/2005 07:37 PM: > On Apr 11, 2005 4:30 PM, Brent Chapman wrote: > >>Yes, this is important; it's got to be extendable, because you aren't >>going to think of everything up front. > > Can one model a network in such a way ontop of SQL, or is there a > better (easier/more extensible/effecient) way? Well, you can store the model in an RDBMS, but the model itself, as Brent says, should not be constrained by SQL semantics. What I've done here is define a set of primitives that can be expressed in relational terms, and built a model on top of that, using our own high-level schema language. So, for example, some of the primitives are: META_VERSION TYPE (classification: router, port, interface) ELEMENT (specific object: core router, 100BT port, T1) \---> ELEMENT ATTRIBUTES \---> ELEMENT TEMPLATES \---> ELEMENT SCRIPTS RELATIONSHIP (t1-1 child of card0; e0.rtr1, e1.sw2 parents of VLAN1) SERVICES \---> SERVICE RELATIONSHIPS ASSEMBLY (how to arrange a number of ELEMENTS, ATTRIBUTEs, RELATIONSHIPs, etc. to deploy a standard Alcatel SR-7 Provider Edge (PE) Router for one-click deployment) Then the Engineering team defines the TYPEs, ELEMENTs, RELATIONSHIPs and important fields (ATTRIBUTEs) to track for each in the metadata editor. When they're done, we have a custom model for *our* network. If a different Engineering team used it, they'd end up with their own custom model. THis is the part where no tool can just be bought and dropped into a provider; there would always be lots of customization to your specific needs. My guidance to Engineers is: only define the minimal fields to describe the unique characteristics of the configuration. This greatly simplifies the design, use, and validation. By contrast, many COTS software collects *all* possible attributes of the network, leading to sloppy data entry, low accuracy, and debatable verifyability. --kirby From network-automation-owner@greatcircle.com Tue Apr 12 07:42:24 2005 X-Original-To: network-automation@greatcircle.com Received: from gate.epygi.de (gate.epygi.de [212.126.211.241]) by mycroft.greatcircle.com (Postfix) with ESMTP id 71C8932C551; Tue, 12 Apr 2005 07:42:23 -0700 (PDT) Received: from NBGIO2 (nb-gio2.epygi.de [10.20.0.21]) by gate.epygi.de (8.13.3/8.13.3) with ESMTP id j3CEfqG1023585; Tue, 12 Apr 2005 16:41:53 +0200 (METDST) From: "Georg Magschok" To: "'Kirby Files'" , "'Brent Chapman'" Cc: "'Aaron Glenn'" , Subject: Re: available network automation tools Date: Tue, 12 Apr 2005 16:44:30 +0200 Organization: Epygi Labs DE GmbH Message-ID: <003401c53f6e$26059660$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <425BD965.5020306@gmail.com> Importance: Normal X-Archive-Number: 200504/37 X-Sequence-Number: 37 > > In other words, an interface that lets you do things like > > > > - Add Device > > - Add Card to Device > > - Add Port to Card > > - Add Network > > - Describe connection from Port to Network > Not only that, but also to define new types of devices and connections > for the model itself. To me that is very much what all management platform dinosaurs provide (e.g. HP OpenView NNM), in most cases it takes far too much manual interaction to define a model of that type. > > At this point, we move beyond the model to the actual ability to deploy > > configurations derived from the model. In other words, I conceptually > > separate the problem into two parts: > > > > 1) What should the configs be for each device? > > 2) How do I get those configs onto those devices? > And (3) How can we tell if the config *can* be applied to the device > (no conflicting assignments; preconditions met); and (4) How can we > tell that the configuration was successfully applied, and how to we > back out the configuration on all other affected devices if not? What about a standard requiring that devices need to perform a 2 or 3 phase commit of automated configuration requests, 2 is sufficient for conflict-free local assignments, 3 is sufficient for network-wide conflict-free assignments. > >> For us, the key has been to keeps the schema for the model defined not > >> in the management software or static database tables, but a NetEng > >> modifiable syntax that can be quickly changed to add new concepts, > >> hardware, and services. > > > > Yes, this is important; it's got to be extendable, because you aren't > > going to think of everything up front. > Yup, and in particular, it has to be easily extensible by > non-programmer types. So I created a metadata syntax that Engineers > can use to define the model, that is later compiled into an object > model. At this point, more than half of the man-hours in the system > have come not from the programmers, but from the work of NetEng > modifying the network model to suit their needs. This allows rapid > change outside of product delivery timelines. This is a superb point. So at least one view onto the model must be syntactically usable for the NetEng. A _very_ limited approach (just linux firewalling) to this can be found in http://firehol.sourceforge.net/ Such a type of overall definition language (and be it XML-based) could cope with the requirement you named. NetML does it in a more general way. So we just need tools around that? bye, Gio Epygi Labs DE GmbH - Georg 'Gio' Magschok From network-automation-owner@greatcircle.com Tue Apr 12 07:48:37 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id E4BF632C1D0; Tue, 12 Apr 2005 07:48:34 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 1C58E19344; Tue, 12 Apr 2005 10:48:32 -0400 (EDT) Message-ID: <16987.57280.24606.129390@perdition.linnaean.org> Date: Tue, 12 Apr 2005 10:48:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kirby Files Cc: Brent Chapman , Aaron Glenn , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <425BD965.5020306@gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <425BD965.5020306@gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/38 X-Sequence-Number: 38 > Not only that, but also to define new types of devices and connections > for the model itself. And in doing this, you start to approach the realm of the semantic problem. The give away words in what you say are "new types". What is a new type? > And (3) How can we tell if the config *can* be applied to the device > (no conflicting assignments; preconditions met); and (4) How can we > tell that the configuration was successfully applied, and how to we > back out the configuration on all other affected devices if not? 3 is effectively the semantic/knowledge representation problem. 4 is an operation you can construct given a good calculus of semantics and representation. > Yup, and in particular, it has to be easily extensible by > non-programmer types. So I created a metadata syntax that Engineers What that usually translates to is that programmer types provide a restricted language for working with your problem. My present employer hands out lisp macros to end users who are mostly blissfully unaware of what goes on under the hood. From network-automation-owner@greatcircle.com Tue Apr 12 08:08:37 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id 184E532C550; Tue, 12 Apr 2005 08:08:35 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:07:54 -0500 Message-ID: <425BE409.6030206@gmail.com> Date: Tue, 12 Apr 2005 11:06:49 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hagerty Cc: Brent Chapman , Aaron Glenn , network-automation@greatcircle.com Subject: Re: available network automation tools References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <425BD965.5020306@gmail.com> <16987.57280.24606.129390@perdition.linnaean.org> In-Reply-To: <16987.57280.24606.129390@perdition.linnaean.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 15:07:55.0005 (UTC) FILETIME=[677D5AD0:01C53F71] X-Archive-Number: 200504/39 X-Sequence-Number: 39 Daniel Hagerty wrote on 04/12/2005 10:48 AM: > > Not only that, but also to define new types of devices and connections > > for the model itself. > > And in doing this, you start to approach the realm of the semantic > problem. The give away words in what you say are "new types". What > is a new type? It is only a semantic problem if you're looking for a one-size-fits-all universal taxonomy of networking. I believe in a system with a small set of primitives with well-defined semantics, which can be used to define a network model of anything from an X.25 financial system to a Tier1 backbone provider, to a heterogeneous mesh network. In my use of it here, a "type", or "element type" is a grouping of elements that share common attributes, functions, and similar roles in the network hierarchy. We have "types" that include "interface", "card", "connection" (sub-typed by vlan, lsp, etc.), and even higher-level constructs of "qos policy" and "edge router". Each of these types has well-defined semantics (interfaces can be connected to one or more interfaces via connnections; cards can be interchanged in slots, etc.) that are true despite vendor or model differences. Thanks, --kirby files From network-automation-owner@greatcircle.com Tue Apr 12 08:10:52 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id DB78732C18A for ; Tue, 12 Apr 2005 08:10:50 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 28CFF19344; Tue, 12 Apr 2005 11:10:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.58618.69954.74133@perdition.linnaean.org> Date: Tue, 12 Apr 2005 11:10:50 -0400 To: Andrew Fort Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041201245c28db72@mail.gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <7654d9d05041021497c88c860@mail.gmail.com> <16986.6174.403374.979347@perdition.linnaean.org> <7654d9d05041118057c4ed5fa@mail.gmail.com> <16987.23050.77047.3526@perdition.linnaean.org> <7654d9d05041201245c28db72@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/40 X-Sequence-Number: 40 > Prior art sounds good. I've really been enjoying some of the reading > (as well as your insight) in this area lately, and I can always add to > my reading list. These references I'm sending to the list on the theory that I was asked here, and these references may be generally useful. Some of them you've probably seen before, a few of them maybe not. For completeness, I'll mention Tom Limoncelli's "The Practice and Art of System and Network Administration" and the original infrastructure papers by Steve Traugott. I'm sure if I digged, I could come up with more canonical references, but you can probably find those as well as I can. Something further afield that was very useful to me in tracking down my problems was "Workflow Modeling", ISBN 1580530214. I learned a number of useful methods from here, and still apply them (should re-read the book soon). The stuff that is further afield I will handle as offline requests. From network-automation-owner@greatcircle.com Tue Apr 12 08:17:13 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id B2B2C32C3E7; Tue, 12 Apr 2005 08:17:12 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 34CDF19344; Tue, 12 Apr 2005 11:17:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16987.59000.137524.6530@perdition.linnaean.org> Date: Tue, 12 Apr 2005 11:17:12 -0400 To: Kirby Files Cc: Brent Chapman , Aaron Glenn , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <425BE409.6030206@gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <425BD965.5020306@gmail.com> <16987.57280.24606.129390@perdition.linnaean.org> <425BE409.6030206@gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/41 X-Sequence-Number: 41 > It is only a semantic problem if you're looking for a You miss my point, but I'm sure I spoke it poorly. > one-size-fits-all universal taxonomy of networking. I believe in a > system with a small set of primitives with well-defined semantics, > which can be used to define a network model of anything from an X.25 > financial system to a Tier1 backbone provider, to a heterogeneous mesh > network. > > In my use of it here, a "type", or "element type" is a grouping of > elements that share common attributes, functions, and similar roles in > the network hierarchy. We have "types" that include "interface", > "card", "connection" (sub-typed by vlan, lsp, etc.), and even > higher-level constructs of "qos policy" and "edge router". > > Each of these types has well-defined semantics (interfaces can be > connected to one or more interfaces via connnections; cards can be > interchanged in slots, etc.) that are true despite vendor or model > differences. That you can do this is not in question; I'm aware of the tractability of the approach. What is this ontology in which you define your new types within, and how does it limit you? From network-automation-owner@greatcircle.com Tue Apr 12 08:39:23 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id 027A632C330 for ; Tue, 12 Apr 2005 08:39:22 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:38:41 -0500 Message-ID: <425BEB40.9010401@gmail.com> Date: Tue, 12 Apr 2005 11:37:36 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hagerty Cc: network-automation@greatcircle.com Subject: Re: available network automation tools References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <425BD965.5020306@gmail.com> <16987.57280.24606.129390@perdition.linnaean.org> <425BE409.6030206@gmail.com> <16987.59000.137524.6530@perdition.linnaean.org> In-Reply-To: <16987.59000.137524.6530@perdition.linnaean.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 15:38:41.0704 (UTC) FILETIME=[B4354280:01C53F75] X-Archive-Number: 200504/42 X-Sequence-Number: 42 Daniel Hagerty wrote on 04/12/2005 11:17 AM: > > Each of these types has well-defined semantics (interfaces can be > > connected to one or more interfaces via connnections; cards can be > > interchanged in slots, etc.) that are true despite vendor or model > > differences. > > What is this ontology in which you define your new types within, > and how does it limit you? That's the point: the ontology, if it deals with primitive networking concepts, does not impose limits on the taxonomy. So, in the preceeding example, the ontology of the metadata that defines our element types includes concepts of location and relationship such as "connects to", "belongs in", "max parents", "uniqueness scope", "name sequencing", "inherits attributes from", etc. If a new concept needs to be added, then the ontology is merely extended to support the new semantics. New properties can be added to the parser definition file and be compiled to the schema without DB modification; implementation of the constraints imposed by the new imperatives is the only required change to the software. New containers, element types, element implementations and instances can all be created withing the existing vocabulary. It's been about 2 years since the last time I came up with a good reason to extend the ontology. Thanks, --kirby From network-automation-owner@greatcircle.com Tue Apr 12 12:50:14 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5A00E32C2CF for ; Tue, 12 Apr 2005 12:50:13 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id E397919344; Tue, 12 Apr 2005 15:50:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16988.9839.831091.938642@perdition.linnaean.org> Date: Tue, 12 Apr 2005 15:50:07 -0400 To: Kirby Files Cc: network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <425BEB40.9010401@gmail.com> References: <42573546.7050503@gmail.com> <18f60194050409174575ada600@mail.gmail.com> <42593FE4.7030901@gmail.com> <425BD965.5020306@gmail.com> <16987.57280.24606.129390@perdition.linnaean.org> <425BE409.6030206@gmail.com> <16987.59000.137524.6530@perdition.linnaean.org> <425BEB40.9010401@gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/43 X-Sequence-Number: 43 > That's the point: the ontology, if it deals with primitive networking > concepts, does not impose limits on the taxonomy. Define the term "primitive networking concepts", or, if "concept" is annoying, simply explain what is denoted by the component term "primitive networking". > New containers, element types, element implementations and instances > can all be created withing the existing vocabulary. It's been about 2 > years since the last time I came up with a good reason to extend the > ontology. Your ability to do this is not a point of contention. I'm trying to point you at a very deep circle in your reasoning. It has *only* been two years since you had to change the ontology. Why is changing your ontology in this way needed? If "your" ontology was "correct", you could write one and be done with it. This is not a precisely correct expression of my meaning however; you'll always have to be changing ontology at some level: that's the point after all. The more precisely correct expression is that you could write a so called "top level ontology" or "ontology in the domain of domains". Use this top level ontology (or things derived from it) to describe your (changing) network ontology in. If you specify top level correctly, it is timeless, even when the ontologies within it are not. The ability to produce this top level ontology is an area of open debate. I appear to fall firmly within the camp that says "this is possible, want to see how?". What you appear to have for your network ontology bears strong resemblance to the usual "top levelish" ontology languages (see for example the wikipedia article on "ontology, computer science sense"). It appears that these are not considered satisfactory to some. I am probably a member of this camp. For myself, I would say that the concepts you speak of in your ontology, as well as those of wikipedia's ontology article, are entirely too derived looking for my comfort. In the primitive math world I have, these concepts have not been invented yet. To pick something out of your ontology, consider "name sequencing". You speak of it as if it were a top level concept. If I understand what you mean, where I'm from, such a thing would be a derived concept that shouldn't be part of the top level; you're speaking of a successor concept from the realm of the integers. If you have some other domain masquerading as the integers, use the existing concepts from the integers. We're all interested in solutions to our configuration problems. I'm quite happy to hear that you've produced a model that works for you. The model I need is a much bigger hammer. If you've ever written a semantic for a "novel" language before, you probably understand that the recursion case is where the hard work is. I've got that part already, and now it's mostly a matter of Simple Matter of Implementation (which there is a lot of, but relatively doable compared to reifying a recursion fixpoint). From network-automation-owner@greatcircle.com Tue Apr 12 17:06:45 2005 X-Original-To: network-automation@greatcircle.com Received: from mail1.optus.com.au (mail1.optus.com.au [203.13.126.129]) by mycroft.greatcircle.com (Postfix) with ESMTP id C3B0932C40F for ; Tue, 12 Apr 2005 17:06:44 -0700 (PDT) Received: from chow2ke002.optus.com.au ([161.43.32.103]) by mail1.optus.com.au with InterScan Messaging Security Suite; Wed, 13 Apr 2005 10:06:17 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: Re: available network automation tools Date: Wed, 13 Apr 2005 10:06:16 +1000 Message-ID: <9976E136B745D511B82C00508BB23E090D96D4B5@shqnte002.optus.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: available network automation tools thread-index: AcU/mOOzr20KEKDBSuOBYq06IDCzUQAIsSPA From: "Francis Liu" To: "Daniel Hagerty" Cc: X-Archive-Number: 200504/44 X-Sequence-Number: 44 > If "your" ontology was "correct", you could write one and be done > with it. This is not a precisely correct expression of my meaning > however; you'll always have to be changing ontology at some level: > that's the point after all. >=20 > The more precisely correct expression is that you could write a so > called "top level ontology" or "ontology in the domain of domains". > Use this top level ontology (or things derived from it) to describe > your (changing) network ontology in. If you specify top level > correctly, it is timeless, even when the ontologies within it are not. >=20 > The ability to produce this top level ontology is an area of open > debate. I appear to fall firmly within the camp that says "this is > possible, want to see how?". If there exists a current body of work that is sufficient and necessary, we, the practitioners in the field, will work with it. We don't necessarily want/need something that is "complete" (and possibly more complex). Workable is great. Flaws can be fixed later, in a revision somewhere. > We're all interested in solutions to our configuration problems. > I'm quite happy to hear that you've produced a model that works for > you. The model I need is a much bigger hammer. Not a math scientist, just an admin, Francis From network-automation-owner@greatcircle.com Tue Apr 12 18:02:17 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mycroft.greatcircle.com (Postfix) with ESMTP id 2B9F232C1D9 for ; Tue, 12 Apr 2005 18:02:12 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so19870rna for ; Tue, 12 Apr 2005 18:02:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=psuANVUwdfWIC6DrJkrDMWGEqMbxfql+VsLiX52+cA7AyTbRfpuqmRxHz7zdEngQ5d0bFz8WGOSxPEHfEMxwfpIkWINfEifACSmNKOo6by9q3Jj3CbsceEA6Fu4Fq/a27JQkWwSndaL4b5PtgfYgWYCeFXa/qdb3JxEOx4bpqNg= Received: by 10.38.153.43 with SMTP id a43mr73271rne; Tue, 12 Apr 2005 18:02:11 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Tue, 12 Apr 2005 18:02:11 -0700 (PDT) Message-ID: <7654d9d05041218025152a9e5@mail.gmail.com> Date: Wed, 13 Apr 2005 11:02:11 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Georg Magschok Subject: Re: available network automation tools Cc: network-automation@greatcircle.com In-Reply-To: <002101c53f38$d186d480$1500140a@EPYGI.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002101c53f38$d186d480$1500140a@EPYGI.DE> X-Archive-Number: 200504/45 X-Sequence-Number: 45 On 4/12/05, Georg Magschok wrote: > > >Are you all interested in starting an open source project around this? > > I don't know about anybody else, but I certainly am. I think that > > such a "network database" would then become a platform upon which > > much else could and would be built; like you said, though, it's > > currently the core missing piece. >=20 > Coming from network management development for ATM switches and VoIP > boxes, I'd like to share an idea that I'm going to implement sooner or > later and would like to see approved as "not wrong": >=20 > "The semantics of a network model should be defined by the network elemen= ts!" >=20 > The reason is rather simple: > Either a network management system needs an awful amount of information > about a network that it should work on (and this would either need to > be standardized into the last little detail or manually entered by > admins), or the network must be able to provide information about itself. I think the 'answer' lies somewhere in the middle - if you can't/won't/don't-need-to produce an uber-model, then you need to 'trust' the devices to some extent. A common point I've noticed in recent replies to this thread is "yeah so maybe we don't need to store/manage every last minute detail centrally. But, we need to know enough to _configure the network_".=20 And that's the important point. We have to be able to configure it this time, configure it from scratch should we need to port the entire configuration to a new device (perhaps your stored copy in RANCID/etc is sufficient, but what happens after restore?), and it has to do the same thing to the device every time we ask for it, no matter the existing device state (i.e., pre-requisites and halting problems need to be considered). Actually the last statement there is really a general form of the first two... Personally, I don't trust device configuration, but I do trust devices to maintain shared state, like IGP tables. Thus, I'd still like to manage 'the entire configuration' centrally. -andrew From network-automation-owner@greatcircle.com Tue Apr 12 21:30:07 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 63D9B32C58B for ; Tue, 12 Apr 2005 21:30:06 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id A570619346; Wed, 13 Apr 2005 00:29:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16988.41028.596683.783207@perdition.linnaean.org> Date: Wed, 13 Apr 2005 00:29:56 -0400 To: Andrew Fort Cc: Georg Magschok , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041218025152a9e5@mail.gmail.com> References: <002101c53f38$d186d480$1500140a@EPYGI.DE> <7654d9d05041218025152a9e5@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/46 X-Sequence-Number: 46 > A common point I've noticed in recent replies to this thread is "yeah > so maybe we don't need to store/manage every last minute detail > centrally. But, we need to know enough to _configure the network_". > And that's the important point. We have to be able to configure it One of the evil details that shows up in this part, at least for more generalized system administration, is that what is and is not minute detail changes from day to day. As I said on lssconf at one point: Today, me having to explictly model every chunk of my syslog.conf would be massive overspecification. Tommorow, I have to explictly model every chunk of my syslog.conf so that I can prove that I'm meeting my logging conformance requirements to my auditors. From network-automation-owner@greatcircle.com Tue Apr 12 22:21:28 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mycroft.greatcircle.com (Postfix) with ESMTP id 254FC32C18A for ; Tue, 12 Apr 2005 22:21:27 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so67211rna for ; Tue, 12 Apr 2005 22:21:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EIHKZloOem3Miu53uphoJSMUvoacpaQtE7F222kK+IzAyLNnWlbxzF5hzlmvCHyOZPEjATH17zJfjnsFX7M+oIcNW+6+IkTdnj50EMFYQspfRhfREVq8KzfuvFx1hYYbsaTe2O6Ei9RvLvkf8mP8bmEV1N4ABpP1jdwvD6QIFOg= Received: by 10.38.68.14 with SMTP id q14mr267301rna; Tue, 12 Apr 2005 22:21:27 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Tue, 12 Apr 2005 22:21:27 -0700 (PDT) Message-ID: <7654d9d05041222215edd32a1@mail.gmail.com> Date: Wed, 13 Apr 2005 15:21:27 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Daniel Hagerty Subject: Re: available network automation tools Cc: Georg Magschok , network-automation@greatcircle.com In-Reply-To: <16988.41028.596683.783207@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002101c53f38$d186d480$1500140a@EPYGI.DE> <7654d9d05041218025152a9e5@mail.gmail.com> <16988.41028.596683.783207@perdition.linnaean.org> X-Archive-Number: 200504/47 X-Sequence-Number: 47 On 4/13/05, Daniel Hagerty wrote: > > A common point I've noticed in recent replies to this thread is "yeah > > so maybe we don't need to store/manage every last minute detail > > centrally. But, we need to know enough to _configure the network_". > > And that's the important point. We have to be able to configure it >=20 > One of the evil details that shows up in this part, at least for > more generalized system administration, is that what is and is not > minute detail changes from day to day. Of course! I would therefore argue that complete specification is necessary if you have a requirement to meet changing requirements retrospectively. If your requirements are less formal (or less paranoid), you can probably do without it. What other problems am I missing? -andrew From network-automation-owner@greatcircle.com Wed Apr 13 08:35:03 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id 20EA232C15A for ; Wed, 13 Apr 2005 08:35:01 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3DFZks3002044 for ; Wed, 13 Apr 2005 08:35:46 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3DFZc67002041 for ; Wed, 13 Apr 2005 08:35:46 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Wed, 13 Apr 2005 08:35:38 -0700 (PDT) From: Paxton To: Subject: Re: available network automation tools In-Reply-To: <7654d9d05041222215edd32a1@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/48 X-Sequence-Number: 48 >> Today, me having to explictly model every chunk of my syslog.conf would be massive overspecification. Tommorow, I have to explictly model every chunk of my syslog.conf so that I can prove that I'm meeting my logging conformance requirements to my auditors. this is an excellent point. I've seen a lot of "I dont want to use [x] because you don't flesh out [n]" and then "I don't want to use [x] because there's too much emphasis on [n] which I dont use and dont want the overhead". The problem with not providing all the details is someone will say, I need to use this for [something you didn't think of that requires a lot of odds and ends] - if you capture 90% of the required data, you can solve 0% of their problem. When you do this for one company, the odds are you can do a reasonable job of estimating what those needs are, but you can never guess the needs of all other unknown companies. I'd like to see an extensible model that can be partially implemented, based on your choice. So maybe syslog (for example) is a drop-in module that you can choose to use or leave off if you don't want it. A model element such as syslog could also exist in multiple modular components, so you can implement a simple syslog model or an advanced extension that gives you all the details, your choice. It should also be easily extensible (by network guys), so that if a fully detailed syslog model doesn't exist, you can define it and share it with the community. So, one other thing that I'm trying to absorb from other posts - what are the pros and cons for (1) let the network elements/devices specify the model - which would be different for different devices/vendors, or (2) make a general model into which all devices/vendors can be fit. I think I'm reading some preferences one way or the other, but what is the logic for one over the other? It seems to me that: (1) is good because your model can be more explicit, less confusing, probably easier to automate from; but is bad because you lose the ability to do comparisons between different devices/vendors (2) is good because you can do across the network audits/comparisons/reporting, regardless of device type/vendor, but is bad because you end up force-fitting some devices into your model, which complicates automation for those devices down the road On Wed, 13 Apr 2005, Andrew Fort wrote: > On 4/13/05, Daniel Hagerty wrote: > > > A common point I've noticed in recent replies to this thread is "yeah > > > so maybe we don't need to store/manage every last minute detail > > > centrally. But, we need to know enough to _configure the network_". > > > And that's the important point. We have to be able to configure it > > > > One of the evil details that shows up in this part, at least for > > more generalized system administration, is that what is and is not > > minute detail changes from day to day. > > Of course! I would therefore argue that complete specification is > necessary if you have a requirement to meet changing requirements > retrospectively. If your requirements are less formal (or less > paranoid), you can probably do without it. What other problems am I > missing? > > -andrew > > From network-automation-owner@greatcircle.com Wed Apr 13 09:05:22 2005 X-Original-To: network-automation@greatcircle.com Received: from gate.epygi.de (gate.epygi.de [212.126.211.241]) by mycroft.greatcircle.com (Postfix) with ESMTP id 029BE32C22D for ; Wed, 13 Apr 2005 09:05:21 -0700 (PDT) Received: from NBGIO2 (nb-gio2.epygi.de [10.20.0.21]) by gate.epygi.de (8.13.3/8.13.3) with ESMTP id j3DG5Bci029994; Wed, 13 Apr 2005 18:05:12 +0200 (METDST) From: "Georg Magschok" To: "'Paxton'" , Subject: Re: available network automation tools Date: Wed, 13 Apr 2005 18:07:49 +0200 Organization: Epygi Labs DE GmbH Message-ID: <004901c54042$f3dddd70$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-Archive-Number: 200504/49 X-Sequence-Number: 49 > (1) is good because your model can be more explicit, less confusing, > probably easier to automate from; but is bad because you lose the ability > to do comparisons between different devices/vendors > (2) is good because you can do across the network > audits/comparisons/reporting, regardless of device type/vendor, but is bad > because you end up force-fitting some devices into your model, which > complicates automation for those devices down the road (1) would lead to a lot of propriatory management information for (2) to work you need a good base of standards for many different applications/devices/network types/layers, defining the management information! This is easy to achieve for a network of pure IPv4 routers with nothing else. It is hard to achieve though if the network is truly heterogenous in the technologies used :( (Somebody wrote it already, but: of course we need the right mixture of that) bye, Gio Epygi Labs DE GmbH - Georg 'Gio' Magschok From network-automation-owner@greatcircle.com Wed Apr 13 18:32:17 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8360F32C5D2 for ; Wed, 13 Apr 2005 18:32:11 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id C09321934B; Wed, 13 Apr 2005 21:32:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.51217.665900.561231@perdition.linnaean.org> Date: Wed, 13 Apr 2005 21:32:01 -0400 To: Andrew Fort Cc: Georg Magschok , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041222215edd32a1@mail.gmail.com> References: <002101c53f38$d186d480$1500140a@EPYGI.DE> <7654d9d05041218025152a9e5@mail.gmail.com> <16988.41028.596683.783207@perdition.linnaean.org> <7654d9d05041222215edd32a1@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/50 X-Sequence-Number: 50 > Of course! I would therefore argue that complete specification is > necessary if you have a requirement to meet changing requirements > retrospectively. If your requirements are less formal (or less Actually, not always. In the case of something like syslog, you can actually assume that whatever your vendor gave you is reasonable, and then when the time to care comes, you just replace the configuration wholesale with your generated configuration (cp generated-file /etc/syslog.conf && /etc/rc.d/syslog restart or whatever). Your domain may vary. Stoping the caring is a little more annoying, as you'll suddenly have two sets of machines: those that had their syslog side effected from vendor default, and newer machines that still have vendor default. This may be undesirable. > paranoid), you can probably do without it. What other problems am I > missing? Well, I'd like it if you could help me find my marbles, but I'll admit that it's not terribly likely at this point. From network-automation-owner@greatcircle.com Wed Apr 13 18:50:20 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mycroft.greatcircle.com (Postfix) with ESMTP id 1C5FE32C5D7 for ; Wed, 13 Apr 2005 18:50:19 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so294781rna for ; Wed, 13 Apr 2005 18:50:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YP6maDjqBvHePje8dGMzqdIqtf7+5r41evFBeGGzuC55+jDwFFt4uMRZc9/yYrjgfhPi3e+z2t15/vlrcTZZeOaIDPujuzHZruqryBVaMEFLmXcLV9gF/9HQ2VGRMoPBKUTEF/J0KgCiAwdmsrx0zYF8Ok3YfciNheO8q+pOhYs= Received: by 10.38.153.43 with SMTP id a43mr1243002rne; Wed, 13 Apr 2005 18:50:18 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Wed, 13 Apr 2005 18:50:17 -0700 (PDT) Message-ID: <7654d9d05041318501d783233@mail.gmail.com> Date: Thu, 14 Apr 2005 11:50:18 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Daniel Hagerty Subject: Re: available network automation tools Cc: Georg Magschok , network-automation@greatcircle.com In-Reply-To: <16989.51217.665900.561231@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <002101c53f38$d186d480$1500140a@EPYGI.DE> <7654d9d05041218025152a9e5@mail.gmail.com> <16988.41028.596683.783207@perdition.linnaean.org> <7654d9d05041222215edd32a1@mail.gmail.com> <16989.51217.665900.561231@perdition.linnaean.org> X-Archive-Number: 200504/51 X-Sequence-Number: 51 On 4/14/05, Daniel Hagerty wrote: > Stoping the caring is a little more annoying, as you'll suddenly > have two sets of machines: those that had their syslog side effected > from vendor default, and newer machines that still have vendor > default. This may be undesirable. If this is the case and it is undesirable, would you use _any_ defaults? I have a feeling this is a circular discussion.. > Well, I'd like it if you could help me find my marbles, but I'll > admit that it's not terribly likely at this point. Not that we don't care.... -andrew From network-automation-owner@greatcircle.com Wed Apr 13 19:30:51 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 794A332C34C for ; Wed, 13 Apr 2005 19:30:50 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id A6B531934B; Wed, 13 Apr 2005 22:30:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.54745.557449.233104@perdition.linnaean.org> Date: Wed, 13 Apr 2005 22:30:49 -0400 To: Andrew Fort Cc: Georg Magschok , network-automation@greatcircle.com Subject: Re: available network automation tools In-Reply-To: <7654d9d05041318501d783233@mail.gmail.com> References: <002101c53f38$d186d480$1500140a@EPYGI.DE> <7654d9d05041218025152a9e5@mail.gmail.com> <16988.41028.596683.783207@perdition.linnaean.org> <7654d9d05041222215edd32a1@mail.gmail.com> <16989.51217.665900.561231@perdition.linnaean.org> <7654d9d05041318501d783233@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/52 X-Sequence-Number: 52 > If this is the case and it is undesirable, would you use _any_ > defaults? I have a feeling this is a circular discussion.. I'll declare halt if we appear to be truly circular, which is to say we would be producing expressions to no apparent effect. This does not appear to be the case yet. Audience, you have veto power here. As I have done so in the real world, it would appear that a reasonable statement would be "yes, I do and would do so again". What makes my original statement tangental, at least in my case, is that once I went to the trouble of specifying syslog.conf, I would *probably* always go to the trouble of specifying it, even if I hid the detail such that it was effectively a linguistic constant after I specified it the once. I can see gotchas in here, but nothing truly awful. An example gotcha case is "what happens when you add some new type of system that specifies the syslog.conf like concept in a different way?". From network-automation-owner@greatcircle.com Wed Apr 13 19:41:58 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 9437B32C5E2 for ; Wed, 13 Apr 2005 19:41:57 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 526451934B; Wed, 13 Apr 2005 22:41:48 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16989.55404.246390.834886@perdition.linnaean.org> Date: Wed, 13 Apr 2005 22:41:48 -0400 To: Paxton Cc: Subject: Re: available network automation tools In-Reply-To: References: <7654d9d05041222215edd32a1@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/53 X-Sequence-Number: 53 > I'd like to see an extensible model that can be partially implemented, > based on your choice. So maybe syslog (for example) is a [...] > > So, one other thing that I'm trying to absorb from other posts - what are > the pros and cons for (1) let the network elements/devices specify the > model - which would be different for different devices/vendors, or (2) > make a general model into which all devices/vendors can be fit. I think The "extensible model" that you really want makes the difference between 1 and 2 irrelevent. A "good extensible model" is a sufficient tool to relate models to one another. If your vendor gives you a model, cool! They just make your job much easier. In general, a good extensible model encourages you to produce a lightweight "your version of theirs" if the vendor doen't give you anything reasonable. This is easier than trying to smash something with too much irrelevant information directly into the correct form. If the vendor gives you something reasonable, assimilate it. From network-automation-owner@greatcircle.com Wed Apr 13 20:30:29 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id 9B4DB32C5DA for ; Wed, 13 Apr 2005 20:30:28 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3E3VFs3002957; Wed, 13 Apr 2005 20:31:15 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3E3VFfO002954; Wed, 13 Apr 2005 20:31:15 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Wed, 13 Apr 2005 20:31:15 -0700 (PDT) From: Paxton To: Daniel Hagerty Cc: Subject: Re: available network automation tools In-Reply-To: <16989.55404.246390.834886@perdition.linnaean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/54 X-Sequence-Number: 54 to some extent, I disagree - lets say you have 2 different router vendors and want to manage acls across the network, for both vendors combined. You want to know that a given access list (based on content) is implemented regardless of the vendor. Both vendors provide you with a model (in some fashion, it may be implied rather than they hand you uml or an xml schema or something). Those 2 models are different. If you apply those models to your database, each vendors acls are stored in different tables - the attributes are named differently, some exist in one model but not the other, maybe relationships exist in one that don't exist in the other. This makes doing comparative analysis Hard. Not impossible, but more difficult and time consuming than if they were in the same model. Like cisco's acl manager doesn't cover Pix access lists, only IOS - they would have to change the data model to handle the pix differences, or handle the pix separately, both of which were non-trivial after the fact, apparently. And that's pix vs IOS access lists which are not all that different, compared to some other vendors. So, I like the idea of using each vendors model for that vendors equipment. You definitely have a cleaner data implementation that's more comprehensible to the user. But it doesn't eliminate the problem in a multivendor environment, it shifts it around. Maybe its a more manageable problem in an already-modeled state though? Meaning, its better to write the translation between a (say) pix acl model and an IOS acl model than to create one model to rule them all. <-- gratuitous tolkien reference On Wed, 13 Apr 2005, Daniel Hagerty wrote: > > I'd like to see an extensible model that can be partially implemented, > > based on your choice. So maybe syslog (for example) is a > [...] > > > > So, one other thing that I'm trying to absorb from other posts - what are > > the pros and cons for (1) let the network elements/devices specify the > > model - which would be different for different devices/vendors, or (2) > > make a general model into which all devices/vendors can be fit. I think > > The "extensible model" that you really want makes the difference > between 1 and 2 irrelevent. A "good extensible model" is a sufficient > tool to relate models to one another. If your vendor gives you a > model, cool! They just make your job much easier. > > In general, a good extensible model encourages you to produce a > lightweight "your version of theirs" if the vendor doen't give you > anything reasonable. This is easier than trying to smash something > with too much irrelevant information directly into the correct form. > > If the vendor gives you something reasonable, assimilate it. > From network-automation-owner@greatcircle.com Wed Apr 13 23:41:07 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 4200C32C152 for ; Wed, 13 Apr 2005 23:41:05 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 3073C1934B; Thu, 14 Apr 2005 02:40:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16990.4216.101453.855016@perdition.linnaean.org> Date: Thu, 14 Apr 2005 02:40:56 -0400 To: Paxton Cc: Subject: Re: available network automation tools In-Reply-To: References: <16989.55404.246390.834886@perdition.linnaean.org> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/55 X-Sequence-Number: 55 > to some extent, I disagree - lets say you have 2 different router vendors I am not sure I see the point of disagreement, which usually means I spoke poorly. > You want to know that a given access list (based on content) is > implemented regardless of the vendor. Both vendors provide you with a > model (in some fashion, it may be implied rather than they hand you uml or > an xml schema or something). Those 2 models are different. If you apply > those models to your database, each vendors acls are stored in different > tables - the attributes are named differently, some exist in one model > but not the other, maybe relationships exist in one that don't exist in > the other. This makes doing comparative analysis Hard. Not impossible, > but more difficult and time consuming than if they were in the same model. > Like cisco's acl manager doesn't cover Pix access lists, only IOS - they > would have to change the data model to handle the pix differences, or > handle the pix separately, both of which were non-trivial after the fact, > apparently. And that's pix vs IOS access lists which are not all that > different, compared to some other vendors. Generically, this problem you speak is called "semantic distance". There are probably other names, but this is one I know. The idea is that models may not map well onto one another. Examples of issues in the area you cite include things like ios reflective acls (no such concept in the pix last I knew), pix grouping (expressable by expansion on ios, but no representation of the group within ios), and no doubt many other concepts that don't translate well. I don't have an ios & pix boxes in front of me to compare today. > So, I like the idea of using each vendors model for that vendors > equipment. You definitely have a cleaner data implementation that's more > comprehensible to the user. But it doesn't eliminate the problem in a > multivendor environment, it shifts it around. Maybe its a more > manageable problem in an already-modeled state though? Meaning, its > better to write the translation between a (say) pix acl model and an > IOS acl model than to create one model to rule them all. <-- gratuitous > tolkien reference "Uber model" versus "use the vendors models and translate" converge on one another, as you crank to infinity. The math looks something like this: When you write "translate from vendor a model to vendor b model", it *looks* like you're writing one function, but you're really writing two that happened to be smashed together. When you write "translate from uber model to vendor a model", you're writing one function. What you're really doing when you write "translate from vendor a model to vendor b model" is "translate from vendor a model to uber model to vendor b model". To jump back down to the concrete, by all means use the vendors model -- if you don't, you'll just end up inventing something that looks remarkably like the vendors model as part of what you need as you require increasing specification. The end game gets hard to predict, but let's worry about the basics first -- one of those basics is establishing a basis of communication. From network-automation-owner@greatcircle.com Thu Apr 14 11:24:08 2005 X-Original-To: network-automation@greatcircle.com Received: from kanga.nu (alice.kanga.nu [198.144.204.211]) by mycroft.greatcircle.com (Postfix) with ESMTP id 894F932C165 for ; Thu, 14 Apr 2005 11:24:07 -0700 (PDT) Delivery-date: Thu, 14 Apr 2005 11:24:07 -0700 Received: from ocker.kanga.nu ([198.144.204.213] helo=kanga.nu) by kanga.nu with asmtp (Exim 4.34 #1 (Debian)) id 1DM90T-0005ii-PC for ; Thu, 14 Apr 2005 11:24:01 -0700 Delivery-date: Thu, 14 Apr 2005 11:24:01 -0700 Received: from localhost ([127.0.0.1]:46413 helo=kanga.nu) by kanga.nu with esmtp (Exim 4.50 #1 (Debian)) id 1DM90T-0000Pa-AH for ; Thu, 14 Apr 2005 11:24:01 -0700 To: network-automation@greatcircle.com Subject: GMane? X-face: ?^_yw@fA`CEX&}--=*&XqXbF-oePvxaT4(kyt\nwM9]{]N!>b^K}-Mb9 YH%saz^>nq5usBlD"s{(.h'_w|U^3ldUq7wVZz$`u>MB(-4$f\a6Eu8.e=Pf\ X-image-url: http://www.kanga.nu/~claw/kanga.face.tiff X-url: http://www.kanga.nu/~claw/ Date: Thu, 14 Apr 2005 11:24:01 -0700 Message-ID: <1585.1113503041@kanga.nu> From: J C Lawrence X-Archive-Number: 200504/56 X-Sequence-Number: 56 Would there be any problem with having this list carried by GMane? -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From network-automation-owner@greatcircle.com Thu Apr 14 11:58:44 2005 X-Original-To: network-automation@greatcircle.com Received: from [66.92.48.19] (localhost [127.0.0.1]) by mycroft.greatcircle.com (Postfix) with ESMTP id 9502F32C1C3; Thu, 14 Apr 2005 11:58:42 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <1585.1113503041@kanga.nu> References: <1585.1113503041@kanga.nu> Date: Thu, 14 Apr 2005 11:58:26 -0700 To: J C Lawrence , network-automation@greatcircle.com From: Brent Chapman Subject: Re: GMane? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Archive-Number: 200504/57 X-Sequence-Number: 57 At 11:24 AM -0700 4/14/05, J C Lawrence wrote: >Would there be any problem with having this list carried by GMane? I've just requested it from GMane; I don't know how long it will take them to process the request. -Brent -- Brent Chapman -- Great Circle Associates, Inc. Specializing in network infrastructure for Silicon Valley since 1989 For info about us and our services, please see http://www.greatcircle.com/ Network Automation blog: http://www.greatcircle.com/blog/network_automation From network-automation-owner@greatcircle.com Fri Apr 15 08:19:54 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id C358B32C2A8 for ; Fri, 15 Apr 2005 08:19:52 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 10:19:11 -0500 Message-ID: <425FDB2E.8080502@gmail.com> Date: Fri, 15 Apr 2005 11:18:06 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Network Automation List Subject: CLI transactions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 15:19:11.0448 (UTC) FILETIME=[79EB9D80:01C541CE] X-Archive-Number: 200504/58 X-Sequence-Number: 58 Since we seem to have beaten the last topic to death, I'd like to solicit the feedback of folks on the list to describe the transactional capabilities of various equipment vendors. One of the first things I look for in a vendor's configuration interface is the ability to use transactions (2-phase or 3-phase commits) to batch configuration statements. The gold standard among equipment manufacturers I use is Juniper, which supports 2-phase commits through its CLI and JunoScript (XML over SSL) interfaces. With commit-check, you can even get a 3-phase commit (config -> commit-check, [compare to other devices] -> rollback/commit). The major impediment to decent transactions seems to have been the usage of "cisco-like" CLIs, and in particular the RapidLogic engine for CLI design, so popular among startups, that has the capabilities of Cisco IOS circa 1998. We've seen a number of devices using this engine to get product to market quickly, and all report an inability to usefully modify the interaction to support transactions. I'd love to hear from anyone who has spoken recently to RapidLogic engineers as to whether atomic commits are on their roadmap. So, please respond with any equipment you know of, whether it supports transactions, either on its CLI or through an API, or even with a vendor-supplied NMS-system. I'll start with equipment I've seen come through the lab: Juniper JunOS: 2- and 3-phase commits on CLI and JunoScript Tasman Networks: none Alcatel 7750 SR: none on CLI; 3-phase transactions allegedly through expensive NMS Extreme: none ANDA Etherrearch: menu-based; no transactions Redback SMS: none Cisco IOS: In some situations, the very intrusive use of configuration archive could give you rollback. Yuk! Thanks, --kirby files From network-automation-owner@greatcircle.com Fri Apr 15 12:55:02 2005 X-Original-To: network-automation@greatcircle.com Received: from mtxexch01.add0.masergy.com (unknown [64.47.104.21]) by mycroft.greatcircle.com (Postfix) with ESMTP id 965EA32C334 for ; Fri, 15 Apr 2005 12:55:01 -0700 (PDT) Received: from [64.47.15.109] ([64.47.15.109]) by mtxexch01.add0.masergy.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 14:54:18 -0500 Message-ID: <42601BA9.5000203@gmail.com> Date: Fri, 15 Apr 2005 15:53:13 -0400 From: Kirby Files User-Agent: Mozilla Thunderbird 1.0.1 (X11/20050309) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Min Qiu Cc: Network Automation List Subject: Re: CLI transactions References: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com> In-Reply-To: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 19:54:18.0819 (UTC) FILETIME=[E9148930:01C541F4] X-Archive-Number: 200504/59 X-Sequence-Number: 59 Min Qiu wrote on 04/15/2005 02:26 PM: > This may bring us back to the previous modeling discussion... > Since the goal is automation, the NMS will be the system > talk to the device via CLI, SNMP or API. Well, in the cases I've seen, the vendor's $$$ NMS is the only system that is able to do transactions, so I think we're back to the discussion of vendor systems versus a vendor-neutral central system. > The 3 phase commits can be in the NMS or router, it does not > matter. Of cause, implement it in NMS will make it more genernal(a > modeling topic) If we're still talking vendor NMS here, the problem is that they generally only support a limited subset of the router capabilities -- usually just simple tasks like subscriber management or service management (adding an LSP, etc.). I've yet to be able to usefully integrate with a vendor NMS. They all talk about open "northbound APIs", but in practice, this is usually more like, "here's our schema; good luck," or, "we use undocumented EJBs (version 1.1 on proprietary app-server)." So, beyond the cost of these add-on systems, I'd generally prefer to just deal with the routers themselves, rather than trying to figure out how to interface with the vendor NMS; how to cram their idea of a network model into my own; and how to deal with the lag between router OS upgrades and NMS version upgrades that can control the new features. --kirby From network-automation-owner@greatcircle.com Fri Apr 15 13:27:47 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id A40E932C38E for ; Fri, 15 Apr 2005 13:27:46 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 69CE21934D; Fri, 15 Apr 2005 16:27:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16992.9148.316331.987016@perdition.linnaean.org> Date: Fri, 15 Apr 2005 16:27:40 -0400 To: Kirby Files Cc: Network Automation List Subject: CLI transactions In-Reply-To: <425FDB2E.8080502@gmail.com> References: <425FDB2E.8080502@gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/60 X-Sequence-Number: 60 > Since we seem to have beaten the last topic to death, I'd like to > solicit the feedback of folks on the list to describe the > transactional capabilities of various equipment vendors. This topic has the ability to curve back to the last. The only thing I'll mention here is that I already wrote some stuff on rollback in the context of general system administration: http://mailman.terraluna.org/pipermail/infrastructures/2005-April/001567.html From network-automation-owner@greatcircle.com Fri Apr 15 13:35:59 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (I9c5c.i.pppool.de [85.73.156.92]) by mycroft.greatcircle.com (Postfix) with ESMTP id 6408332C17D for ; Fri, 15 Apr 2005 13:35:57 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id 3755127E25C; Fri, 15 Apr 2005 22:35:54 +0200 (CEST) Date: Fri, 15 Apr 2005 22:35:54 +0200 From: Juergen Schoenwaelder To: Kirby Files Cc: Network Automation List Subject: Re: CLI transactions Message-ID: <20050415203554.GA567@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <425FDB2E.8080502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425FDB2E.8080502@gmail.com> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/61 X-Sequence-Number: 61 On Fri, Apr 15, 2005 at 11:18:06AM -0400, Kirby Files wrote: > So, please respond with any equipment you know of, whether it supports > transactions, either on its CLI or through an API, or even with a > vendor-supplied NMS-system. > > I'll start with equipment I've seen come through the lab: > > Juniper JunOS: 2- and 3-phase commits on CLI and JunoScript > Tasman Networks: none > Alcatel 7750 SR: none on CLI; 3-phase transactions allegedly through > expensive NMS > Extreme: none > ANDA Etherrearch: menu-based; no transactions > Redback SMS: none > Cisco IOS: In some situations, the very intrusive use of configuration > archive could give you rollback. Yuk! A rather frustrating collection. Without proper support by the devices, one will never to be able to create a robust and adaptable piece of a network configuration system. Putting the rollback logic on the NMS is a broken concept as it requires that the NMS knows quite a bit about the internals of the device. The lack of proper primitives on the devices is probably the reason why NMS software is so bloated, device specific and does provide so little functionality (since writing all the rollback code to make things somewhat robust and interoperable is a big pain). /js P.S. The rollback capability in NetConf is optional and the list above explains quite well why. -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Fri Apr 15 13:36:19 2005 X-Original-To: network-automation@greatcircle.com Received: from asl.mypop2pop.com (mail.pop2pop.com [64.200.94.98]) by mycroft.greatcircle.com (Postfix) with ESMTP id EDAB732C364 for ; Fri, 15 Apr 2005 11:26:07 -0700 (PDT) Received: from [10.10.10.4] (helo=gicorp0.gicorp.mypop2pop.com) by asl.mypop2pop.com with esmtp (Exim 4.43) id 1DMVVx-0007vo-Se for network-automation@greatcircle.com; Fri, 15 Apr 2005 14:26:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: CLI transactions Date: Fri, 15 Apr 2005 14:26:01 -0400 Message-ID: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLI transactions Thread-Index: AcVBzp8JbYksWldYQhGjZyGPmauBsgAA7AGw From: "Min Qiu" To: "Kirby Files" , "Network Automation List" X-Spam-Score: -2.8 (--) X-Spam-Report: -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Archive-Number: 200504/62 X-Sequence-Number: 62 This may bring us back to the previous modeling discussion...=20 Since the goal is automation, the NMS will be the system=20 talk to the device via CLI, SNMP or API. The 3 phase commits=20 can be in the NMS or router, it does not matter. Of cause, implement it in NMS will make it more genernal(a modeling=20 topic) Right? Min > -----Original Message----- > From: Kirby Files [mailto:ksfiles@gmail.com]=20 > Sent: Friday, April 15, 2005 11:18 AM > To: Network Automation List > Subject: CLI transactions >=20 > Since we seem to have beaten the last topic to death, I'd like to > solicit the feedback of folks on the list to describe the > transactional capabilities of various equipment vendors. >=20 > One of the first things I look for in a vendor's configuration > interface is the ability to use transactions (2-phase or 3-phase > commits) to batch configuration statements. >=20 > The gold standard among equipment manufacturers I use is Juniper, > which supports 2-phase commits through its CLI and JunoScript (XML > over SSL) interfaces. With commit-check, you can even get a 3-phase > commit (config -> commit-check, [compare to other devices] -> > rollback/commit). >=20 > The major impediment to decent transactions seems to have been the > usage of "cisco-like" CLIs, and in particular the RapidLogic engine > for CLI design, so popular among startups, that has the capabilities > of Cisco IOS circa 1998. We've seen a number of devices using this > engine to get product to market quickly, and all report an inability > to usefully modify the interaction to support transactions. I'd love > to hear from anyone who has spoken recently to RapidLogic engineers as > to whether atomic commits are on their roadmap. >=20 > So, please respond with any equipment you know of, whether it supports > transactions, either on its CLI or through an API, or even with a > vendor-supplied NMS-system. >=20 > I'll start with equipment I've seen come through the lab: >=20 > Juniper JunOS: 2- and 3-phase commits on CLI and JunoScript > Tasman Networks: none > Alcatel 7750 SR: none on CLI; 3-phase transactions allegedly through > expensive NMS > Extreme: none > ANDA Etherrearch: menu-based; no transactions > Redback SMS: none > Cisco IOS: In some situations, the very intrusive use of configuration > archive could give you rollback. Yuk! >=20 > Thanks, > --kirby files >=20 From network-automation-owner@greatcircle.com Sat Apr 16 09:43:20 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (I9c62.i.pppool.de [85.73.156.98]) by mycroft.greatcircle.com (Postfix) with ESMTP id 80B6932C448 for ; Sat, 16 Apr 2005 09:43:15 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id B495027E612; Sat, 16 Apr 2005 18:43:11 +0200 (CEST) Date: Sat, 16 Apr 2005 18:43:10 +0200 From: Juergen Schoenwaelder To: David Magda Cc: Network Automation List , Kirby Files Subject: Re: CLI transactions Message-ID: <20050416164310.GA1602@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <425FDB2E.8080502@gmail.com> <20050415203554.GA567@boskop.local> <2b4d88af5c8d0b78a64d40a72adda9ac@ee.ryerson.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b4d88af5c8d0b78a64d40a72adda9ac@ee.ryerson.ca> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/63 X-Sequence-Number: 63 On Sat, Apr 16, 2005 at 10:59:35AM -0400, David Magda wrote: > > On Apr 15, 2005, at 16:35, Juergen Schoenwaelder wrote: > > >P.S. The rollback capability in NetConf is optional and the list above > > explains quite well why. > > Does the current draft have it as a MAY or as a SHOULD? (Really have to > go through the draft, but only so many hours in a day.) Rollback is a capability. NetConf has a core set of features and capabilities. The idea is that additional capabilities may be added over time and perhaps even by vendors. > Perhaps if they made it a MUST it would spur companies to actually deal > with this. I would hope that the writers of the RFC would at least look > to the future on where you want to go in addition to simply where we > are now. (Yes I am being idealistic here. :) Making rollback a mandatory core feature means that many vendors will not implement it since adding rollback may mean a big investment, depending on your internal architecture. At the end, it boils down to market decisions and what customers ask for. If customers are willing to pay some extra $$ to get rollback support, vendors will put it in. If customers do not care about the management interfaces when they make investment decisions, the state of the art will not improve. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Sat Apr 16 11:20:52 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id E98D932C18D for ; Sat, 16 Apr 2005 11:20:51 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 830ED1934F; Sat, 16 Apr 2005 14:20:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16993.22398.416364.322731@perdition.linnaean.org> Date: Sat, 16 Apr 2005 14:20:46 -0400 To: "Min Qiu" Cc: "Kirby Files" , "Network Automation List" Subject: Re: CLI transactions In-Reply-To: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com> References: <9BD20C9B8D21C04FA661826D202E631F01E2983A@gicorp0.gicorp.mypop2pop.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/64 X-Sequence-Number: 64 > This may bring us back to the previous modeling discussion... > Since the goal is automation, the NMS will be the system > talk to the device via CLI, SNMP or API. The 3 phase commits > can be in the NMS or router, it does not matter. Of cause, > implement it in NMS will make it more genernal(a modeling > topic) > > Right? Certainly as you get to extremes, sure. I'm guessing pure network administration doesn't need to go there very often tho. In some kinds of large systems, deeply nested transactions are the norm. For example, if I write a message driven EJB that accepts messages from a transactional queue system and somehow puts them in a transactional database, both the queue system and the database system see themselves as "the transaction manager". But to the larger system, these two transactions are nested and controlled by another transaction manager that actually ensures that both transactions behave as one. From network-automation-owner@greatcircle.com Sat Apr 16 20:55:38 2005 X-Original-To: network-automation@greatcircle.com Received: from tomts36-srv.bellnexxia.net (tomts36-srv.bellnexxia.net [209.226.175.93]) by mycroft.greatcircle.com (Postfix) with ESMTP id 4554632C42D for ; Sat, 16 Apr 2005 07:59:26 -0700 (PDT) Received: from number6.magda.ca ([64.229.234.240]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050416145925.FLHL16985.tomts36-srv.bellnexxia.net@number6.magda.ca>; Sat, 16 Apr 2005 10:59:25 -0400 Received: from [192.168.1.132] (gandalf.magda.ca [192.168.1.132]) by number6.magda.ca (8.13.1/8.13.1) with ESMTP id j3GE0JGk000480; Sat, 16 Apr 2005 10:00:19 -0400 (EDT) (envelope-from dmagda@ee.ryerson.ca) In-Reply-To: <20050415203554.GA567@boskop.local> References: <425FDB2E.8080502@gmail.com> <20050415203554.GA567@boskop.local> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2b4d88af5c8d0b78a64d40a72adda9ac@ee.ryerson.ca> Content-Transfer-Encoding: 7bit Cc: Network Automation List , Kirby Files Reply-To: David Magda From: David Magda Subject: Re: CLI transactions Date: Sat, 16 Apr 2005 10:59:35 -0400 To: j.schoenwaelder@iu-bremen.de X-Mailer: Apple Mail (2.619.2) X-Archive-Number: 200504/65 X-Sequence-Number: 65 On Apr 15, 2005, at 16:35, Juergen Schoenwaelder wrote: > P.S. The rollback capability in NetConf is optional and the list above > explains quite well why. Does the current draft have it as a MAY or as a SHOULD? (Really have to go through the draft, but only so many hours in a day.) Perhaps if they made it a MUST it would spur companies to actually deal with this. I would hope that the writers of the RFC would at least look to the future on where you want to go in addition to simply where we are now. (Yes I am being idealistic here. :) From network-automation-owner@greatcircle.com Sun Apr 17 19:37:13 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mycroft.greatcircle.com (Postfix) with ESMTP id 5E05A32C471 for ; Sun, 17 Apr 2005 19:37:11 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1039314rna for ; Sun, 17 Apr 2005 19:37:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=imOt1ZzWePHL1PpKYQHg81SG4N1SOWi+R6z7Oufdep3fPWwKNl9r9blFTWAaR4afG0MoQnWCuKEsaRuYcYJF5jGQUnopftbaFktzTmFgvQEYVyJn+1OOJ1tYPi7EQPn627buX1VjxeMsz7NUIYIRuoXo+9QrJ4yF9Dzgk0IMRnQ= Received: by 10.38.74.31 with SMTP id w31mr5420349rna; Sun, 17 Apr 2005 19:37:10 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Sun, 17 Apr 2005 19:37:10 -0700 (PDT) Message-ID: <7654d9d05041719376de82fb9@mail.gmail.com> Date: Mon, 18 Apr 2005 12:37:10 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Kirby Files Subject: Re: CLI transactions Cc: Network Automation List In-Reply-To: <425FDB2E.8080502@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425FDB2E.8080502@gmail.com> X-Archive-Number: 200504/66 X-Sequence-Number: 66 On 4/16/05, Kirby Files wrote: > So, please respond with any equipment you know of, whether it supports > transactions, either on its CLI or through an API, or even with a > vendor-supplied NMS-system. Alteon: none Foundry: none Enterasys/Riverstone: none ... Need we go on. Obviously, for us to build a tool people will feel comfortable using, we need some method of backing out of changes. We have devices which don't support anything, and we have Juniper.. (or the alcatel api).. What then? Do we support levels of "default blah" on cisco? For the cisco-like CLIs that don't provide any way to get a known state (i.e., you can "no" things, but the semantics of "no" are not always the same, e.g. across version changes, etc), what do we do? The way I see it, our base level becomes "transaction failed, (don't save the config) then reload every device?". If device types support transactions, we use them. Any other options? -andrew From network-automation-owner@greatcircle.com Sun Apr 17 19:53:15 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mycroft.greatcircle.com (Postfix) with ESMTP id 2FC1532C472 for ; Sun, 17 Apr 2005 19:41:16 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1039710rna for ; Sun, 17 Apr 2005 19:41:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VXKjEk25/zJq/VzbXX7c8IzVPJVrsIcsI4TsqaBJFaxboWyb2BF2NyIuzUZUY80hfWZdP4q+IQWcgAwS2m+wRUgGCPgtJk8k/qkFP8V0MLQ6lNbyI93GVfkPGYK1Gw8i83ZM4k7EOyEuPcUUKWf2iedATFCPRFp1fpR4D8KEmSQ= Received: by 10.38.160.52 with SMTP id i52mr4663630rne; Sun, 17 Apr 2005 19:41:14 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Sun, 17 Apr 2005 19:41:14 -0700 (PDT) Message-ID: <7654d9d0504171941341b2d2c@mail.gmail.com> Date: Mon, 18 Apr 2005 12:41:14 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Kirby Files Subject: Re: CLI transactions Cc: Network Automation List In-Reply-To: <7654d9d05041719376de82fb9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <425FDB2E.8080502@gmail.com> <7654d9d05041719376de82fb9@mail.gmail.com> X-Archive-Number: 200504/67 X-Sequence-Number: 67 On 4/18/05, Andrew Fort wrote: > Enterasys/Riverstone: none I should correct myself here... to say "none" is only half the picture. Enterasys EOS and Riverstone OS (i.e., in the SSR8000/RS8000 type of product) provide a "scratchpad" concept, where you make changes to the config, which go into the scratchpad (the scratchpad is shared between all users currently logged in, incidentally). You can then "show scratchpad", and "save active" to apply the scratchpad changes, and "save startup" does what it sounds like. The problem is that there's no real rollback facility once you have shot yourself in the foot, so for our purpose the effective result is "none". -andrew From network-automation-owner@greatcircle.com Sun Apr 17 22:40:04 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (I83ee.i.pppool.de [85.73.131.238]) by mycroft.greatcircle.com (Postfix) with ESMTP id ECB5232C46B for ; Sun, 17 Apr 2005 22:40:03 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id 9D88029A76C; Mon, 18 Apr 2005 07:39:58 +0200 (CEST) Date: Mon, 18 Apr 2005 07:39:58 +0200 From: Juergen Schoenwaelder To: Andrew Fort Cc: Kirby Files , Network Automation List Subject: Re: CLI transactions Message-ID: <20050418053958.GA2161@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <425FDB2E.8080502@gmail.com> <7654d9d05041719376de82fb9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7654d9d05041719376de82fb9@mail.gmail.com> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/68 X-Sequence-Number: 68 On Mon, Apr 18, 2005 at 12:37:10PM +1000, Andrew Fort wrote: > The way I see it, our base level becomes "transaction failed, (don't > save the config) then reload every device?". If device types support > transactions, we use them. Reloading is rather painful but seems the only way out. Of course, in some environments, reloading is really really painful. Perhaps another thing to consider is to print out a very clear warning somewhere about the device capabilities and its consequences ("sorry, your devices xxx does not properly support configuration transactions and may need to be reloaded in case a configuration transaction fails"). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 11:18:49 2005 X-Original-To: network-automation@greatcircle.com Received: from asl.mypop2pop.com (mail.pop2pop.com [64.200.94.98]) by mycroft.greatcircle.com (Postfix) with ESMTP id 8C4CD32C16A for ; Mon, 18 Apr 2005 08:37:37 -0700 (PDT) Received: from [10.10.10.4] (helo=gicorp0.gicorp.mypop2pop.com) by asl.mypop2pop.com with esmtp (Exim 4.43) id 1DNYJQ-0005b4-S6 for network-automation@greatcircle.com; Mon, 18 Apr 2005 11:37:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: CLI transactions Date: Mon, 18 Apr 2005 11:37:24 -0400 Message-ID: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLI transactions Thread-Index: AcVD2R2LgaE6niyWTUesltzfDkANSgAUN5eA From: "Min Qiu" To: , "Andrew Fort" Cc: "Kirby Files" , "Network Automation List" X-Spam-Score: -2.8 (--) X-Spam-Report: -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Archive-Number: 200504/69 X-Sequence-Number: 69 If the system is automated as suggested by the mailing list, warning message will be ignored at least.... there is no way=20 to know critical configuration changes vs. routines tasks. So far, our discussion is device centric. The way I see NMS=20 is it should be network centric. That is, if I perform a change to the network, deploy a VPN or an access list, lets=20 say I need to touch 5 devices and failed at 3rd device, I=20 would like to know what "rollback" realy means. Min > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Monday, April 18, 2005 1:40 AM > To: Andrew Fort > Cc: Kirby Files; Network Automation List > Subject: Re: CLI transactions >=20 > On Mon, Apr 18, 2005 at 12:37:10PM +1000, Andrew Fort wrote: >=20=20 > > The way I see it, our base level becomes "transaction failed, (don't > > save the config) then reload every device?". If device=20 > types support > > transactions, we use them. >=20 > Reloading is rather painful but seems the only way out. Of course, in > some environments, reloading is really really painful. Perhaps another > thing to consider is to print out a very clear warning=20 > somewhere about=20 > the device capabilities and its consequences ("sorry, your=20 > devices xxx=20 > does not properly support configuration transactions and may=20 > need to be=20 > reloaded in case a configuration transaction fails"). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany > From network-automation-owner@greatcircle.com Mon Apr 18 12:35:48 2005 X-Original-To: network-automation@greatcircle.com Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mycroft.greatcircle.com (Postfix) with ESMTP id 1962732C4FD for ; Mon, 18 Apr 2005 12:26:01 -0700 (PDT) Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 18 Apr 2005 12:26:01 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j3IJPvpR002042; Mon, 18 Apr 2005 12:25:57 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp473.cisco.com [10.61.65.217]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j3IJH33H014807; Mon, 18 Apr 2005 12:17:03 -0700 Message-ID: <426409C3.5090507@cisco.com> Date: Mon, 18 Apr 2005 21:25:55 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Min Qiu Cc: j.schoenwaelder@iu-bremen.de, Andrew Fort , Kirby Files , Network Automation List Subject: Re: CLI transactions References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> In-Reply-To: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1113851825.637411"; x:"432200"; a:"rsa-sha1"; b:"nofws:487"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"UG9mqHVuJu2cj+SqK/a/fmVVXsBwrOqLDDb5k4LTRdyssEgDk2LtEiV+/le6/z+m1y3m1skW" "h0EjVm8nITYqZFV08xs95rNoTEQZnnl+XpO2fkJ3n/8skMS76UcCZaoh3G35l104ByHPjMmlBUq" "e8x8mDsyWZwzuOuzKEz/rg3I="; c:"Date: Mon, 18 Apr 2005 21:25:55 +0200"; c:"From: Eliot Lear "; c:"Subject: Re: CLI transactions" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Archive-Number: 200504/70 X-Sequence-Number: 70 Min Qiu wrote: > So far, our discussion is device centric. The way I see NMS > is it should be network centric. That is, if I perform a > change to the network, deploy a VPN or an access list, lets > say I need to touch 5 devices and failed at 3rd device, I > would like to know what "rollback" realy means. Thus far I believe the discussion has been around device functionality necessary to deliver certain network behavior . Your question of what rollback really means is a good one. To me it means a return to a configured state prior to one or more configuration changes (see checkpoints ;-) Eliot From network-automation-owner@greatcircle.com Mon Apr 18 13:15:45 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (Ia267.i.pppool.de [85.73.162.103]) by mycroft.greatcircle.com (Postfix) with ESMTP id E975232C22D for ; Mon, 18 Apr 2005 13:15:44 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id D252C29CFD9; Mon, 18 Apr 2005 18:41:44 +0200 (CEST) Date: Mon, 18 Apr 2005 18:41:44 +0200 From: Juergen Schoenwaelder To: Min Qiu Cc: Andrew Fort , Kirby Files , Network Automation List Subject: Re: CLI transactions Message-ID: <20050418164144.GA12530@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/71 X-Sequence-Number: 71 On Mon, Apr 18, 2005 at 11:37:24AM -0400, Min Qiu wrote: > So far, our discussion is device centric. The way I see NMS > is it should be network centric. That is, if I perform a > change to the network, deploy a VPN or an access list, lets > say I need to touch 5 devices and failed at 3rd device, I > would like to know what "rollback" realy means. Juniper supports confirmed commits. After a change has been put into action, you have to get back to the device to commit the change or otherwise the box rolls back. This is very cool since in case of a broken transaction, you simply wait for the boxes to roll back into the previous state. This is especially cool if the change locks you out of the network. Confirmed commits are another optional capability of the netconf protocol. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 14:04:12 2005 X-Original-To: network-automation@greatcircle.com Received: from smtp1.enomia.com (smtp1.enomia.com [66.194.55.11]) by mycroft.greatcircle.com (Postfix) with ESMTP id A61A732C1C8 for ; Mon, 18 Apr 2005 14:04:10 -0700 (PDT) Received: from mail24.eNomia.com ([10.160.16.12]) by smtp1.enomia.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 17:04:08 -0400 Received: from 10.160.16.1 ([10.160.16.1]) by mail24.eNomia.com ([10.160.16.12]) via Exchange Front-End Server imail.enomia.com ([10.160.16.14]) with Microsoft Exchange Server HTTP-DAV ; Mon, 18 Apr 2005 21:04:07 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Apr 2005 16:04:07 -0500 Subject: Re: CLI transactions From: James Dollar To: , Min Qiu Cc: Andrew Fort , Kirby Files , Network Automation List Message-ID: In-Reply-To: <20050418164144.GA12530@boskop.local> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3196685048_41477767" X-OriginalArrivalTime: 18 Apr 2005 21:04:08.0683 (UTC) FILETIME=[29AC4BB0:01C5445A] X-Archive-Number: 200504/72 X-Sequence-Number: 72 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3196685048_41477767 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Guys, My company=B9s network management appliance (The Uplogix Envoy) builds that kind of transactional wrapper around ad-hoc changes made via the device=B9s console for Cisco, Tasman, and Nortel. It takes a snapshot of the running environment before and after a user makes a change and creates a rollback procedure necessary to return the running configuration back to the previous state. It subtracts the additions and adds back the subtractions to minimize the impact on other device functions. (For Juniper we use Juniper=B9s built-in functionality) It applies this =B3rollback configuration=B2 if the user does not commit the change within a definable timeout (default 75 seconds) - automatically restoring changes that otherwise may have isolated the device from the user management session. It may also be applied at any time after a commit, as we store 20 versions of the rollback. j$ GM, Products Uplogix From: Juergen Schoenwaelder Reply-To: Date: Mon, 18 Apr 2005 12:41:44 -0400 To: Min Qiu Cc: Andrew Fort , Kirby Files , Network Automation List Subject: Re: CLI transactions On Mon, Apr 18, 2005 at 11:37:24AM -0400, Min Qiu wrote: > So far, our discussion is device centric. The way I see NMS > is it should be network centric. That is, if I perform a > change to the network, deploy a VPN or an access list, lets > say I need to touch 5 devices and failed at 3rd device, I > would like to know what "rollback" realy means. Juniper supports confirmed commits. After a change has been put into action, you have to get back to the device to commit the change or otherwise the box rolls back. This is very cool since in case of a broken transaction, you simply wait for the boxes to roll back into the previous state. This is especially cool if the change locks you out of the network. Confirmed commits are another optional capability of the netconf protocol. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --B_3196685048_41477767 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: CLI transactions G= uys,

My company’s network management appliance (The Uplogix Envoy) builds = that kind of transactional wrapper around ad-hoc changes made via the devic= e’s console for Cisco, Tasman, and Nortel.  It takes a snapshot = of the running environment before and after a user makes a change and creat= es a rollback procedure necessary to return the running configuration back = to the previous state. It subtracts the additions and adds back the subtrac= tions to minimize the impact on other device functions.  (For Juniper = we use Juniper’s built-in functionality)

It applies this “rollback configuration” if the user does not c= ommit the change within a definable timeout (default 75 seconds) - automati= cally restoring changes that otherwise may have isolated the device from th= e user management session.  It may also be applied at any time after a= commit, as we store 20 versions of the rollback.

j$
GM, Products
Uplogix


From: Juergen Schoenwael= der <j.schoenwaelder@iu-bremen.de>
Reply-To: <j.schoenwaelder@iu-bremen.de>
Date: Mon, 18 Apr 2005 12:41:44 -0400
To: Min Qiu <mqiu@pop2pop.com>
Cc: Andrew Fort <andrew.fort@gmail.com>, Kirby Files <ksfil= es@gmail.com>, Network Automation List <network-automation@greatcircl= e.com>
Subject: Re: CLI transactions

On Mon, Apr 18, 2005 at 11:37:24AM -0400, Min Qiu wrote:

> So far, our discussion is device centric.  The way I see NMS
> is it should be network centric.  That is, if I perform a
> change to the network, deploy a VPN or an access list, lets
> say I need to touch 5 devices and failed at 3rd device, I
> would like to know what "rollback" realy means.

Juniper supports confirmed commits. After a change has been put
into action, you have to get back to the device to commit the change
or otherwise the box rolls back. This is very cool since in case of
a broken transaction, you simply wait for the boxes to roll back
into the previous state. This is especially cool if the change locks
you out of the network. Confirmed commits are another optional
capability of the netconf protocol.

/js

--
Juergen Schoenwaelder          = ;     International University Bremen
<http://www.eecs.iu-bremen.de/= >     P.O. Box 750 561, 28725 Bremen, Germany

 --B_3196685048_41477767-- From network-automation-owner@greatcircle.com Mon Apr 18 14:55:27 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id A342A32C1DD for ; Mon, 18 Apr 2005 14:55:26 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 3C33E1934F; Mon, 18 Apr 2005 17:55:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.11469.138111.346637@perdition.linnaean.org> Date: Mon, 18 Apr 2005 17:55:25 -0400 To: Eliot Lear Cc: Min Qiu , j.schoenwaelder@iu-bremen.de, Andrew Fort , Kirby Files , Network Automation List Subject: Re: CLI transactions In-Reply-To: <426409C3.5090507@cisco.com> References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/73 X-Sequence-Number: 73 > Thus far I believe the discussion has been around device functionality > necessary to deliver certain network behavior . Your question of what > rollback really means is a good one. To me it means a return to a > configured state prior to one or more configuration changes (see > checkpoints ;-) Databases need rollback explictly because there are external factors that can not possibly be statically managed that will generate a rollback. Databases are often made from disk drives that themselves have no "commit" concept beyond "write this disk block thusly". Nonetheless, the database can present "rollback". The real question about rollback is one of defining when you do and don't need it. We can return to what it really means in a moment. Suppose we have a fully configured network in some state. We will envision that this network was created with the help of some oracle that helps us describe our overall network. Further suppose that this oracle is actually working on "data" of some sort, as opposed to being an inseperable whole. Imagine that we can change the data that our oracle works with, and that this oracle has a mode that produces configuration statements for our network one at a time, until it we have exhausted the font of configuration -- when we have uttered all of these statements, we have achieved a desired new state of the network as specified by the data we gave to the oracle. Suppose also that we have a boolean valued function. This function will somehow examine the state of the network and determine if we should rollback or not. We could call this function after we uttered each configuration statement, and use it to decide if we should start a rollback. We will not worry about how to execute the rollback operation; given an oracle of the power described above, "simple matter of programming". In what conditions will this rollback-needed predicate return true? What information does the rollback predicate need from the network that, in particular, is not actually derivable from our oracle? If all of the information that could ever possibly play into your rollback-needed predicate is a result of your oracle, you do not need a rollback operation. You can statically detect when you would rollback before you got to the dynamic situation where you needed the rollback. Don't speak what would cause you to need to rollback. There probably are real problems in a typical network that will require dynamic rollback. Here's one that is perhaps contrived; those of you with more real networking needs can probably come up with better ones: Perhaps I assert as part of my configuration that my BGP filters will have certain effects. One such predicate I could assert is that post-filtered ASN1 will inject no less than some number N prefixes into my RIB at each point where I peer with ASN1. If the number is below this value, than "something is wrong with the configuration", and a rollback should ensue. Sound reasonable enough? Making an actual rollback operation isn't that hard. As before, it's really a modeling problem. A good model trivially enables an oracle that can produce delta statements for the network pretty readily. As long as you can talk to the device, you can roll it back. You may in fact have to wipe the config to do it, but why do you care? Your relational database has to do much more evil things within itself to make rollback appear on its surface: the user is usually talking rows, but the database is talking blocks. The model that Kirby was talking about a few days ago probably has enough information for him to produce a rollback operation if he felt he needed it. James Dollar also mentions that his company does something to produce a rollback concept. This is all doable. If you want rollback, you're going to discover that it starts to curve back on the modeling questions: how do you explain the rollback capabilities of a juniper versus those of a cisco, and how does we use these capabiltiies within a larger, more platonic notion of rollback? From network-automation-owner@greatcircle.com Mon Apr 18 15:28:27 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mycroft.greatcircle.com (Postfix) with ESMTP id 00A9232C1C2 for ; Mon, 18 Apr 2005 15:28:26 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1227886rna for ; Mon, 18 Apr 2005 15:28:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yi6b+ReYK8kQWbjdMl1i5WoaxMjppm1tsP/so4mmBlijv9HKSBp6mzV6Cucb9rsw7u4auJOJVSqsbTdf9ZSVw1/nr25iLy8i710NR8GKclP7g3qiOF2EfKxOWVKDUC6Fjy2GzQFlyFqPrvEBpCRe5ejWGeJ/CMEnKDTTCpMk9GQ= Received: by 10.38.152.65 with SMTP id z65mr4483631rnd; Mon, 18 Apr 2005 15:28:25 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Mon, 18 Apr 2005 15:28:25 -0700 (PDT) Message-ID: <7654d9d05041815282770bf8a@mail.gmail.com> Date: Tue, 19 Apr 2005 08:28:25 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Daniel Hagerty Subject: Re: CLI transactions Cc: Network Automation List In-Reply-To: <16996.11469.138111.346637@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> X-Archive-Number: 200504/74 X-Sequence-Number: 74 On 4/19/05, Daniel Hagerty wrote: > This is all doable. If you want rollback, you're going to > discover that it starts to curve back on the modeling questions: how > do you explain the rollback capabilities of a juniper versus those of > a cisco, and how does we use these capabiltiies within a larger, more > platonic notion of rollback? I only see the concept of a revision number in the model (and what the currently enacted revision is) - is anything else required?. As long as you can diff between the "current enacted configuration" (last transaction ACK) and the "to be applied configuration", you can produce configuration statements that will roll forward and roll backward (if supported by your device configuration language), or you can produce the whole configuration for rollback. The lurking assumption in that is "produce the whole configuration".=20 Surely this implies a congruent tool (i.e., it is the GOD of its minions/devices). We can probably do equally well with simply reloading a previously known good configuration and reloading.=20 However, if your tool is not congruent, and you implicitly change state (by reloading existing configuration), is there a danger of increasing entropy through such recoveries? I think this is going to be OK, but is this system what you might call a strong axiomatic system? (if so, we can't know for sure if it is going to be OK). I'm guessing this is "the problem" with rollback. As for building a device's configuration from a limited amount of overall 'state'... Could this be as simple as defining the device's role (or roles, in smaller networks cash is much more limited). Each of these defines pre-requisites, which gives you order, e.g. you must configure your IGP before you configure BGP, you must configure crypto keys before IPsec, and so on. But as always, syntax (i'm most familiar with IOS) is rolling back on the semantics. Is this type of text-template pre-requisite approach suitable for all device configuration languages? What about overlaps between roles.. This is probably where the tool relies on the implementor to avoid the implications of occam's razor. -andrew From network-automation-owner@greatcircle.com Mon Apr 18 15:41:36 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (I953c.i.pppool.de [85.73.149.60]) by mycroft.greatcircle.com (Postfix) with ESMTP id 9A1E232C1C8 for ; Mon, 18 Apr 2005 15:41:35 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id 02BA729D2B8; Tue, 19 Apr 2005 00:41:31 +0200 (CEST) Date: Tue, 19 Apr 2005 00:41:31 +0200 From: Juergen Schoenwaelder To: Daniel Hagerty Cc: Network Automation List Subject: Re: CLI transactions Message-ID: <20050418224131.GA12946@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16996.11469.138111.346637@perdition.linnaean.org> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/75 X-Sequence-Number: 75 On Mon, Apr 18, 2005 at 05:55:25PM -0400, Daniel Hagerty wrote: > Making an actual rollback operation isn't that hard. As before, > it's really a modeling problem. A good model trivially enables an > oracle that can produce delta statements for the network pretty > readily. As long as you can talk to the device, you can roll it back. > You may in fact have to wipe the config to do it, but why do you care? > Your relational database has to do much more evil things within itself > to make rollback appear on its surface: the user is usually talking > rows, but the database is talking blocks. I tend to disagree with your view of the world. a) Database rollbacks are simple because data objects (at least in the pure relational world) just carry data and no side effects. Network configuration changes however do impact devices and cause resources to be allocated/deallocated. So it is not always trivial to rollback from state B into state A since you have to take such side effects into account. (And one not totally uncommon side effect is in fact that you loose connectivity.) b) Reloading whole device configurations because a network-wide transaction failed would be a desaster in some environments. Operators love stability and some devices actually take quite some noticable time to load an old configuration and some even loose dynamic state which you really like to keep. c) SNMP, the turing machine of network management, requires oracles to do anything useful and after more than 15 years of experience we know that the lack of proper primitives does make it difficult to write smart oracles since the costs of "trivially" coding things such as rollback support seem to be non-trivial. d) Several vendors seem to oppose the idea of making rollback capabilities mandatory in NetConf. This is another indicator that the simple programming exercise is not simple at all to add if a box was not designed to support such rollbacks. While in a pure abstract view an oracle can solve all these problems, I believe that the proper devision of work requires that devices do their share of work to support robust network wide configuration transactions. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 15:56:21 2005 X-Original-To: network-automation@greatcircle.com Received: from asl.mypop2pop.com (mail.pop2pop.com [64.200.94.98]) by mycroft.greatcircle.com (Postfix) with ESMTP id B688932C1BF for ; Mon, 18 Apr 2005 15:56:19 -0700 (PDT) Received: from [10.10.10.4] (helo=gicorp0.gicorp.mypop2pop.com) by asl.mypop2pop.com with esmtp (Exim 4.43) id 1DNfA7-00087K-7x for network-automation@greatcircle.com; Mon, 18 Apr 2005 18:56:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: CLI transactions Date: Mon, 18 Apr 2005 18:56:14 -0400 Message-ID: <9BD20C9B8D21C04FA661826D202E631F01E29A5B@gicorp0.gicorp.mypop2pop.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLI transactions Thread-Index: AcVEZf20DNTrNVWBTCOZHsS5PG/SOAAArOUg From: "Min Qiu" To: "Andrew Fort" , "Daniel Hagerty" Cc: "Network Automation List" X-Spam-Score: -2.8 (--) X-Spam-Report: -2.8 ALL_TRUSTED Did not pass through any untrusted hosts X-Archive-Number: 200504/76 X-Sequence-Number: 76 Revision control is not always work well, e.g: 1) some vendors have their config db in binary format 2) OS/firmware upgrade. Min > -----Original Message----- > From: Andrew Fort [mailto:andrew.fort@gmail.com]=20 > Sent: Monday, April 18, 2005 6:28 PM > To: Daniel Hagerty > Cc: Network Automation List > Subject: Re: CLI transactions >=20 > On 4/19/05, Daniel Hagerty wrote: >=20 > > This is all doable. If you want rollback, you're going to > > discover that it starts to curve back on the modeling questions: how > > do you explain the rollback capabilities of a juniper=20 > versus those of > > a cisco, and how does we use these capabiltiies within a=20 > larger, more > > platonic notion of rollback? >=20 > I only see the concept of a revision number in the model (and what the > currently enacted revision is) - is anything else required?. As long > as you can diff between the "current enacted configuration" (last > transaction ACK) and the "to be applied configuration", you can > produce configuration statements that will roll forward and roll > backward (if supported by your device configuration language), or you > can produce the whole configuration for rollback. >=20 > The lurking assumption in that is "produce the whole configuration".=20 > Surely this implies a congruent tool (i.e., it is the GOD of its > minions/devices). We can probably do equally well with simply > reloading a previously known good configuration and reloading.=20 > However, if your tool is not congruent, and you implicitly change > state (by reloading existing configuration), is there a danger of > increasing entropy through such recoveries? I think this is going to > be OK, but is this system what you might call a strong axiomatic > system? (if so, we can't know for sure if it is going to be OK). I'm > guessing this is "the problem" with rollback. >=20 > As for building a device's configuration from a limited amount of > overall 'state'... >=20 > Could this be as simple as defining the device's role (or roles, in > smaller networks cash is much more limited). Each of these defines > pre-requisites, which gives you order, e.g. you must configure your > IGP before you configure BGP, you must configure crypto keys before > IPsec, and so on. But as always, syntax (i'm most familiar with IOS) > is rolling back on the semantics. Is this type of text-template > pre-requisite approach suitable for all device configuration > languages? What about overlaps between roles.. This is probably where > the tool relies on the implementor to avoid the implications of > occam's razor. >=20 > -andrew >=20 From network-automation-owner@greatcircle.com Mon Apr 18 17:38:59 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id E00E332C1AE for ; Mon, 18 Apr 2005 17:38:58 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 7E21E19356; Mon, 18 Apr 2005 20:38:49 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.21273.400025.376696@perdition.linnaean.org> Date: Mon, 18 Apr 2005 20:38:49 -0400 To: j.schoenwaelder@iu-bremen.de Cc: Network Automation List Subject: Re: CLI transactions In-Reply-To: <20050418224131.GA12946@boskop.local> References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/77 X-Sequence-Number: 77 > I tend to disagree with your view of the world. The problem you have with my world view boils down to the fact that it hinges on "magic". There is a key technology needed that does not actually exist yet, and so my world view doesn't work. My role here is to remind you that there are two ways to solve the newtonion motion problem, and the way in which you invent calculus first is easier that the other way (namely, all the other brute force ways). Your problem is not newtonion motion, but it may as well be. My actual copious free time hacking is to make my world possible. You can see this particular piece of missing magic missing, and you are quite rightfully saying "excuse me, show me some bloody proof!". You need a "magic" denotational semantic approach that is more powerful and general than Scott Strachey. Such a thing does not exist on earth yet. Scott Strachey (and denotational semantics in general) has fallen out of favor due to some corner cases (non-determism and concurrency) that existing models don't handle well, as well as the fact that doing it well is Hard. I am suggesting that denotational semantics doesn't have to be this way. > a) Database rollbacks are simple because data objects (at least in the > pure relational world) just carry data and no side effects. Network Preaching to the choir. Search the archives of this list and infrastructures and you will see me saying the same thing. I will also point out that mathematical reasoning on languages with side-effects is old hat; see R5RS section 7.2 for a denotational semantic of scheme that includes treatment of side-effects in the language. > b) Reloading whole device configurations because a network-wide > transaction failed would be a desaster in some environments. Then let's break the problem in two, shall we? 1. You have devices that can possibly be moved between states short of "reconfigure from scratch". If so, "simple matter of programming". Most things I've seen on a cisco fall into this category. 2. The only way you can possibly implement a rollback involves the "disasterous total reload". If you *have* to implement rollback on such a device, it sounds like you have a hard problem that is out of scope for "simple configuration magic". If you can somehow build a meta level to hide the rollback (common in system administration), help can be provided here. But how to be clever is your problem. Anyway, borderline out of scope since we can't automate human creativity. > c) SNMP, the turing machine of network management, requires oracles > to do anything useful and after more than 15 years of experience I'm aware of this. I can't immediately offer you anything to soothe your concerns here other than "that's not hard". The side effect issues you mention early are much closer to generalized "hard". > d) Several vendors seem to oppose the idea of making rollback I am not here to convince your vendors to do the right thing. If some vendors have clue and some vendors do not, vote with your pocketbook. > While in a pure abstract view an oracle can solve all these problems, > I believe that the proper devision of work requires that devices do > their share of work to support robust network wide configuration > transactions. That is the joy of abstraction. Who said that the oracle is centralized? You did. Such an oracle is a concept. Oracle implementation is a detail we wish to work out. I don't actually see how the concept of an oracle fundamentally disagrees with your assertion that their is a division of labor. If anything, I would strongly agree. From network-automation-owner@greatcircle.com Mon Apr 18 18:10:11 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (Iac31.i.pppool.de [85.73.172.49]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7F3B732C50B for ; Mon, 18 Apr 2005 18:10:09 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id 02ECE29D474; Tue, 19 Apr 2005 03:10:05 +0200 (CEST) Date: Tue, 19 Apr 2005 03:10:05 +0200 From: Juergen Schoenwaelder To: Daniel Hagerty Cc: Network Automation List Subject: Re: CLI transactions Message-ID: <20050419011005.GA13334@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16996.21273.400025.376696@perdition.linnaean.org> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/78 X-Sequence-Number: 78 On Mon, Apr 18, 2005 at 08:38:49PM -0400, Daniel Hagerty wrote: > > I tend to disagree with your view of the world. > > The problem you have with my world view boils down to the fact > that it hinges on "magic". There is a key technology needed that does > not actually exist yet, and so my world view doesn't work. I thought this list was about building network wide configuration management systems today rather than inventing a new key technology that solves "magic" to implement "oracles" tomorrow. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 18:21:13 2005 X-Original-To: network-automation@greatcircle.com Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by mycroft.greatcircle.com (Postfix) with ESMTP id 18DA732C1C8 for ; Mon, 18 Apr 2005 18:21:12 -0700 (PDT) Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k2.research.att.com [135.207.21.32]) by mail-green.research.att.com (Postfix) with ESMTP id 3E17BA7BED; Mon, 18 Apr 2005 21:21:12 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: Re: CLI transactions Date: Mon, 18 Apr 2005 21:21:12 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLI transactions Thread-Index: AcVEfJJgIJLBEKg/SzqdjtXV0m6MjQAAYBiZ From: To: Cc: X-Archive-Number: 200504/79 X-Sequence-Number: 79 Hi Juergen, Other than the castrophic cases you called attention to (and o= thers we can think of where you lose the router or the ability to reset the= router), could you elaborate on the cases you worry about where the simple= policy of rollback to the last known good config does not converge to an a= cceptable state? -- Albert Albert Greenberg -----Original Message----- From: network-automation-owner@greatcircle.com To: Daniel Hagerty CC: Network Automation List Sent: Mon Apr 18 21:10:05 2005 Subject: Re: CLI transactions On Mon, Apr 18, 2005 at 08:38:49PM -0400, Daniel Hagerty wrote: > > I tend to disagree with your view of the world. >=20 > The problem you have with my world view boils down to the fact > that it hinges on "magic". There is a key technology needed that does > not actually exist yet, and so my world view doesn't work. I thought this list was about building network wide configuration management systems today rather than inventing a new key technology that solves "magic" to implement "oracles" tomorrow. /js --=20 Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 18:32:34 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mycroft.greatcircle.com (Postfix) with ESMTP id A91D432C346 for ; Mon, 18 Apr 2005 18:32:33 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so1252454rna for ; Mon, 18 Apr 2005 18:32:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BD8YL8D5yyviDLADkU+tIebVaL3X9aZmiagY7Qi3jo9ciAB+2jnKAIICufM5FJ3kAPhuH+3iRd066Ajcn/a3YpslvGB/GSzU957uTgXyRc3fjWTwsFrBPAbCL8s/UlAcGJDjPhVNNf7dH9U6iLB69UYmtZlXi72mSvbJonGr9Uk= Received: by 10.38.149.73 with SMTP id w73mr6405590rnd; Mon, 18 Apr 2005 18:32:32 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Mon, 18 Apr 2005 18:32:32 -0700 (PDT) Message-ID: <7654d9d0504181832b2994f1@mail.gmail.com> Date: Tue, 19 Apr 2005 11:32:32 +1000 From: Andrew Fort Reply-To: Andrew Fort To: network-automation@greatcircle.com Subject: Re: CLI transactions In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> X-Archive-Number: 200504/80 X-Sequence-Number: 80 On 4/19/05, albert@research.att.com wrote: > Hi Juergen, Other than the castrophic cases you called attention to (and= others we can think of where you lose the router or the ability to reset t= he router), could you elaborate on the cases you worry about where the simp= le policy of rollback to the last known good config does not converge to an= acceptable state? > -- Albert >=20 > Albert Greenberg And given that there are already (large) operators that use the "see you on the other side, hope your configuration updated!" to do major changes with "reload soft" on cisco boxen, are any of these operators on this list and would care to comment on the nature of such changes? -andrew From network-automation-owner@greatcircle.com Mon Apr 18 19:01:29 2005 X-Original-To: network-automation@greatcircle.com Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mycroft.greatcircle.com (Postfix) with ESMTP id 72F0632C515 for ; Mon, 18 Apr 2005 19:01:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DNi3M-000Crs-LN; Tue, 19 Apr 2005 02:01:28 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DNi3H-0007nv-UZ; Mon, 18 Apr 2005 16:01:24 -1000 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.26227.438370.294215@roam.psg.com> Date: Mon, 18 Apr 2005 16:01:23 -1000 To: Andrew Fort Cc: network-automation@greatcircle.com Subject: Re: CLI transactions References: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> <7654d9d0504181832b2994f1@mail.gmail.com> X-Archive-Number: 200504/81 X-Sequence-Number: 81 > And given that there are already (large) operators that use the "see > you on the other side, hope your configuration updated!" to do major > changes with "reload soft" on cisco boxen, are any of these operators > on this list and would care to comment on the nature of such changes? not in polite company randy From network-automation-owner@greatcircle.com Mon Apr 18 19:16:52 2005 X-Original-To: network-automation@greatcircle.com Received: from boskop.local (Ib565.i.pppool.de [85.73.181.101]) by mycroft.greatcircle.com (Postfix) with ESMTP id B581D32C2A7 for ; Mon, 18 Apr 2005 19:16:50 -0700 (PDT) Received: by boskop.local (Postfix, from userid 501) id 3FCB029D4CD; Tue, 19 Apr 2005 04:16:31 +0200 (CEST) Date: Tue, 19 Apr 2005 04:16:30 +0200 From: Juergen Schoenwaelder To: albert@research.att.com Cc: network-automation@greatcircle.com Subject: Re: CLI transactions Message-ID: <20050419021630.GA13506@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de References: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1018566A2@NJFPSRVEXG2KCL.research.att.com> User-Agent: Mutt/1.5.8i X-Archive-Number: 200504/82 X-Sequence-Number: 82 On Mon, Apr 18, 2005 at 09:21:12PM -0400, albert@research.att.com wrote: > Hi Juergen, Other than the castrophic cases you called attention to > (and others we can think of where you lose the router or the ability > to reset the router), could you elaborate on the cases you worry about > where the simple policy of rollback to the last known good config does > not converge to an acceptable state? Networked devices such as switches and routers usually maintain quite some state that is dynamically learned (e.g. link state information or spanning tree information). Some people also call this operational state. The most simplistic solution to rollback is to reinitialize the device with the last saved good configuration. This approach often implies to loose dynamically learned operational state and is thus not really desirable, especially if you do such a reload on a network-wide scale. Suppose you do something like adding/removing acls on your boxes regularily and the reaction to such a failed transaction is that 80% of the boxes involved need to be reloaded and that you loose all the operational state (which usually takes time to build up again). So this approach only works in environments where the # of failed transactions per time is tolerable and the impact of reloading boxes more or less simultaneously is acceptable. The more advanced solution is to figure out what needs to be done to the machine in order to return from the current state (which might be the original transaction carried out half ways) into the original state. My experience is that this is not trivial to get right. Suppose you want to configure a new VLAN across your campus. This requires to send sequences of SNMP sets or CLI commands to the boxes involved. If your network-wide transaction fails, you have to instruct the devices to revert that change by sending another sequence of SNMP sets or CLI commands. On the box that causes the transaction to abort, you may have to roll back a half complete execution of the SNMP sets of CLI commands. This in particular impacts the complexity of the rollback code that you have to write. If you do not get it right, you may leak incomplete VLAN configurations and your network-wide configuration system may hit by this leakage at some later time, causing another transaction to fail. In some sense, you would need a smart garbage collector to remove things in a smart way that should not be there ideally without loosing any operational state. Putting the rollback mechanism on the box pushes the problem to the box vendor. The good news, however, is that the box vendor knows the internals of how the box works and thus he has the means to support rollbacks more efficiently and in a least disruptive manner. Pushing this to the vendors also solves the issue with versioning since the rollback code your write will end up being not only box specific but actually box and version specific. Sure, this approach to push the problem to the vendors requires serious work on the side of the vendor, especially if a rollback capability was not designed into the system. Bottom line: Someone has to pay a price to support robust network wide configuration transactions. Vendors have an opportunity to differentiate themself here. From the system design point of view, I love to make the assumption that rollback support is on the devices. For devices that do not have this capability, introduce proxies that help to provide rollback capability, possibly even by reloading. (TMN people would call these proxies element managers and I am basically proposing to integrate the element manager into the boxes themself.) The network-wide configuration manager should be isolated from these rollback details as much as possible as it should only worry about generating transactions, running transactions and dealing with the reporting/handling of failed logical configuration change transactions. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From network-automation-owner@greatcircle.com Mon Apr 18 20:17:04 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7371532C346 for ; Mon, 18 Apr 2005 20:17:03 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 023C119353; Mon, 18 Apr 2005 23:16:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16996.30757.915955.499291@perdition.linnaean.org> Date: Mon, 18 Apr 2005 23:16:53 -0400 To: j.schoenwaelder@iu-bremen.de Cc: Network Automation List Subject: Re: CLI transactions In-Reply-To: <20050419011005.GA13334@boskop.local> References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/83 X-Sequence-Number: 83 > I thought this list was about building network wide configuration > management systems today rather than inventing a new key technology > that solves "magic" to implement "oracles" tomorrow. You say tomato. I say tomato. Same denoted things, different senses. You object to the terms "magic" and "oracle". Fine. "magic" is strucken from the vocabulary as a nonce, and "oracle" can be replaced by "function of specified range and domain", although you should note that the term "oracle" is often used in subset reasoning like this. In this case, I specified the approximate range of some of the oracle functions in prior mail; I neglected fully specifying domain as "exercise to the reader". If you wish, we could proceed to fully flesh out whatever systems you like: give me top level specification, and I will subset the problem specification and can continue to do so down to very finely granular parts. I'm here to help you with your problem; part of what I'm here to tell you is that "networks" are far from the only places that have this problem with making tractible configuration. You give me concrete examples (as you have), and I will tell you what I see as it relates to what I know of the word "configuration" in all its horror. Perhaps with the help of one another, we can shed light on how to portably communicate, yes? If you want me to show you the so called "magic", I can do that to: present version of the "hard part" is perhaps 80 lines of scheme that still doesn't say what I want, but is getting there. Writing proper recursion combinators is Hard, and I am told that this is a Very Hard recursion combinator to get right. Maybe I can do it. Maybe I can't. My immediate problem is copious free time to think about the hard problems. Getting the hard problems correct is very important for what I want to do. It may be important for what you want to do; I don't know. Let me read the particulars of what you just said; you have good examples. From network-automation-owner@greatcircle.com Tue Apr 19 01:03:59 2005 X-Original-To: network-automation@greatcircle.com Received: from gate.epygi.de (gate.epygi.de [212.126.211.241]) by mycroft.greatcircle.com (Postfix) with ESMTP id 617BD32C16C for ; Tue, 19 Apr 2005 01:03:54 -0700 (PDT) Received: from NBGIO2 (nb-gio2.epygi.de [10.20.0.21]) by gate.epygi.de (8.13.3/8.13.3) with ESMTP id j3J849hw026558 for ; Tue, 19 Apr 2005 10:04:10 +0200 (METDST) From: "Georg Magschok" To: Subject: Re: CLI transactions Date: Tue, 19 Apr 2005 10:06:50 +0200 Organization: Epygi Labs DE GmbH Message-ID: <001701c544b6$c111e800$1500140a@EPYGI.DE> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Archive-Number: 200504/84 X-Sequence-Number: 84 The way of detecting whether a rollback in a network wide automated configuration attempt is needed is a test as invariant to this change request. They need to be suitable paired: if the test, as formulated by the operator or the Uber-NMS fails, the rollback must be performed. Tests can be organized hierarchically, i.e. some testing the basic functionality with each change, and some testing the goal of a change. Furthermore I'd definitely put the rollback to the box, as Juergen wrote. A secure network-wide rollback is only possible if each box invovled provides a safe local rollback. Many networks could exist with not completely save network-wide rollback issued by NMS. The operator MUST decide which one he needs, and the network SHOULD support both :) Thanks for the insight. This thread is interesting to read! bye, Gio Epygi Labs DE GmbH - Georg 'Gio' Magschok From network-automation-owner@greatcircle.com Tue Apr 19 08:08:02 2005 X-Original-To: network-automation@greatcircle.com Received: from darksun.binsh.com (darksun.doomathon.com [64.232.216.23]) by mycroft.greatcircle.com (Postfix) with ESMTP id A436F32C29E for ; Tue, 19 Apr 2005 08:07:21 -0700 (PDT) Received: from darksun.binsh.com (localhost [127.0.0.1]) by darksun.binsh.com (8.12.6/8.12.6) with ESMTP id j3JF88s3008867 for ; Tue, 19 Apr 2005 08:08:08 -0700 (PDT) Received: from localhost (paxton@localhost) by darksun.binsh.com (8.12.6/8.12.6/Submit) with ESMTP id j3JF83dk008864 for ; Tue, 19 Apr 2005 08:08:08 -0700 (PDT) X-Authentication-Warning: darksun.binsh.com: paxton owned process doing -bs Date: Tue, 19 Apr 2005 08:08:03 -0700 (PDT) From: Paxton To: Subject: Re: CLI transactions In-Reply-To: <20050419021630.GA13506@boskop.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/85 X-Sequence-Number: 85 > Networked devices such as switches and routers usually maintain quite some > state that is dynamically learned (e.g. link state information or spanning > tree information). Some people also call this operational state. also with link state, spanning tree and others, its possible that a configuration change modifies not only the local state information, but also for example, which switch is the stp root, which is not necessarily changed back to the original when you roll back the offending switch's configuration. After a rollback, the state of your network has changed even though the configuration files are identical to the original. This is one issue I have with configuration change management tools which only deal with the configuration file - not all relevant data is captured. On Tue, 19 Apr 2005, Juergen Schoenwaelder wrote: > On Mon, Apr 18, 2005 at 09:21:12PM -0400, albert@research.att.com wrote: > > > Hi Juergen, Other than the castrophic cases you called attention to > > (and others we can think of where you lose the router or the ability > > to reset the router), could you elaborate on the cases you worry about > > where the simple policy of rollback to the last known good config does > > not converge to an acceptable state? > > Networked devices such as switches and routers usually maintain quite some > state that is dynamically learned (e.g. link state information or spanning > tree information). Some people also call this operational state. > > The most simplistic solution to rollback is to reinitialize the device > with the last saved good configuration. This approach often implies > to loose dynamically learned operational state and is thus not really > desirable, especially if you do such a reload on a network-wide scale. > Suppose you do something like adding/removing acls on your boxes > regularily and the reaction to such a failed transaction is that 80% > of the boxes involved need to be reloaded and that you loose all the > operational state (which usually takes time to build up again). So > this approach only works in environments where the # of failed > transactions per time is tolerable and the impact of reloading > boxes more or less simultaneously is acceptable. > > The more advanced solution is to figure out what needs to be done to > the machine in order to return from the current state (which might be > the original transaction carried out half ways) into the original state. > My experience is that this is not trivial to get right. Suppose you > want to configure a new VLAN across your campus. This requires to > send sequences of SNMP sets or CLI commands to the boxes involved. > If your network-wide transaction fails, you have to instruct the > devices to revert that change by sending another sequence of SNMP > sets or CLI commands. On the box that causes the transaction to > abort, you may have to roll back a half complete execution of the > SNMP sets of CLI commands. This in particular impacts the complexity > of the rollback code that you have to write. If you do not get it > right, you may leak incomplete VLAN configurations and your > network-wide configuration system may hit by this leakage at > some later time, causing another transaction to fail. In some > sense, you would need a smart garbage collector to remove things > in a smart way that should not be there ideally without loosing > any operational state. > > Putting the rollback mechanism on the box pushes the problem to > the box vendor. The good news, however, is that the box vendor knows > the internals of how the box works and thus he has the means to > support rollbacks more efficiently and in a least disruptive manner. > Pushing this to the vendors also solves the issue with versioning > since the rollback code your write will end up being not only box > specific but actually box and version specific. Sure, this approach > to push the problem to the vendors requires serious work on the > side of the vendor, especially if a rollback capability was not > designed into the system. > > Bottom line: Someone has to pay a price to support robust network > wide configuration transactions. Vendors have an opportunity to > differentiate themself here. From the system design point of view, > I love to make the assumption that rollback support is on the > devices. For devices that do not have this capability, introduce > proxies that help to provide rollback capability, possibly even > by reloading. (TMN people would call these proxies element managers > and I am basically proposing to integrate the element manager into > the boxes themself.) The network-wide configuration manager should > be isolated from these rollback details as much as possible as > it should only worry about generating transactions, running > transactions and dealing with the reporting/handling of failed > logical configuration change transactions. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > From network-automation-owner@greatcircle.com Tue Apr 19 08:53:33 2005 X-Original-To: network-automation@greatcircle.com Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by mycroft.greatcircle.com (Postfix) with ESMTP id 58A4332C1AE for ; Tue, 19 Apr 2005 08:53:32 -0700 (PDT) Received: from NJFPSRVEXG2KCL.research.att.com (njfpsrvexg2k2.research.att.com [135.207.21.32]) by mail-green.research.att.com (Postfix) with ESMTP id 78C80A7AD8; Tue, 19 Apr 2005 11:53:29 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: Re: CLI transactions Date: Tue, 19 Apr 2005 11:53:29 -0400 Message-ID: <387B5A9BF31B5D43A2B18DD9F326B8E1018566AD@NJFPSRVEXG2KCL.research.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CLI transactions Thread-Index: AcVEf7DTV9UdMGf3Rj+88HPaeDTymgAd+Yog From: To: , X-Archive-Number: 200504/86 X-Sequence-Number: 86 Hi Andrew, I don't quite follow the example and the point, and would you mind elaborating? -- Albert > -----Original Message----- > From: network-automation-owner@greatcircle.com [mailto:network-automation- > owner@greatcircle.com] On Behalf Of Andrew Fort > Sent: Monday, April 18, 2005 9:33 PM > To: network-automation@greatcircle.com > Subject: Re: CLI transactions >=20 > On 4/19/05, albert@research.att.com wrote: > > Hi Juergen, Other than the castrophic cases you called attention to > (and others we can think of where you lose the router or the ability to > reset the router), could you elaborate on the cases you worry about where > the simple policy of rollback to the last known good config does not > converge to an acceptable state? > > -- Albert > > > > Albert Greenberg >=20 > And given that there are already (large) operators that use the "see > you on the other side, hope your configuration updated!" to do major > changes with "reload soft" on cisco boxen, are any of these operators > on this list and would care to comment on the nature of such changes? >=20 > -andrew From network-automation-owner@greatcircle.com Tue Apr 19 14:18:42 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mycroft.greatcircle.com (Postfix) with ESMTP id 1CF3C32C19D for ; Tue, 19 Apr 2005 14:18:40 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so55970rna for ; Tue, 19 Apr 2005 14:18:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=flg0J4ckNYl4PUBQbkHRKktYBZoUhKtvn7acIry4ToRZfAkjAG/8O86ePrv7D/tKjHMRN2rwuSOLj7f5SraulEpsmli1cJ8ABE00UVYW/K+Mc6ETJSTcYwTmd6h7OnHfbvVfZWD/I5sJpZ5lUoK9uoIyKTXnoWXakeG9o1aWBMo= Received: by 10.38.149.35 with SMTP id w35mr257152rnd; Tue, 19 Apr 2005 14:18:39 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Tue, 19 Apr 2005 14:18:38 -0700 (PDT) Message-ID: <7654d9d050419141871682c75@mail.gmail.com> Date: Wed, 20 Apr 2005 07:18:38 +1000 From: Andrew Fort Reply-To: Andrew Fort To: "albert@research.att.com" Subject: Re: CLI transactions Cc: network-automation@greatcircle.com In-Reply-To: <387B5A9BF31B5D43A2B18DD9F326B8E1018566AD@NJFPSRVEXG2KCL.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <387B5A9BF31B5D43A2B18DD9F326B8E1018566AD@NJFPSRVEXG2KCL.research.att.com> X-Archive-Number: 200504/87 X-Sequence-Number: 87 On 4/20/05, albert@research.att.com wrote: > > And given that there are already (large) operators that use the "see > > you on the other side, hope your configuration updated!" to do major > > changes with "reload soft" on cisco boxen, are any of these operators > > on this list and would care to comment on the nature of such changes? > > > > -andrew > Hi Andrew, I don't quite follow the example and the point, and would > you mind elaborating? -- Albert Lets say you build your configurations with m4 and data in some repository (ldap, sql, whatever), as some folks do (I find this a quite reasonable approach here). For consistency and congruence, you're building an entire configuration file, making liberal use of includes for your network-wide stuff, like AAA, standard access-lists, and so on. Say also you have a large scale network change to enact across a large number of boxes. It's a pretty large change to the configuration, and the network in question is IOS devices. So you choose to load the configuration to startup-config and reload the devices. Since staff from large providers talked about the "reload soft" feature in some fora, my assumption is that this method of major change is quite alive inside some networks since "it's probably better to reboot the IOS box than change its configuration too much" (assumption based on experience). So you reload soft and hope for the best, that all the configuration comes up and is loaded successfully by the device, and that any network-derived state comes good also (c.f., the stp, igp, egp state). I was hoping people could talk about how they cope with the cases where the configurations are not in sync after the change; not war stories so much as insight we can learn from. My approach is to make sure working OOB access is available to such devices and ops will rectify conditions as appropriate; reloading again from the existing configuration can be scripted through this network, so this could also enacted upon a rollback requirement. In the perhaps more realistic case where you are rebooting CPE or far-flung devices and you have no asynchronous access, what then? Randy's quip was perhaps highlighting that this is not the most pleasant way to have to enact such changes, or perhaps that I just shouldn't ask :). -andrew From network-automation-owner@greatcircle.com Tue Apr 19 18:35:47 2005 X-Original-To: network-automation@greatcircle.com Received: from throat.webalive.biz (throat.webalive.biz [69.93.211.26]) by mycroft.greatcircle.com (Postfix) with SMTP id A8AE332C5B0 for ; Tue, 19 Apr 2005 18:35:46 -0700 (PDT) Received: (qmail 3371 invoked from network); 20 Apr 2005 02:34:48 -0000 Received: from unknown (HELO ?10.0.1.254?) (203.222.142.146) by 0 with SMTP; 20 Apr 2005 02:34:48 -0000 Date: Wed, 20 Apr 2005 11:37:28 +1000 (EST) From: Tim Nelson X-X-Sender: tnelson@tnelson.webalive.biz To: Daniel Hagerty Cc: j.schoenwaelder@iu-bremen.de, Network Automation List Subject: Magic and Oracles (was: Re: CLI transactions) In-Reply-To: <16996.30757.915955.499291@perdition.linnaean.org> Message-ID: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200504/88 X-Sequence-Number: 88 On Mon, 18 Apr 2005, Daniel Hagerty wrote: > > I thought this list was about building network wide configuration > > management systems today rather than inventing a new key technology > > that solves "magic" to implement "oracles" tomorrow. > > You say tomato. I say tomato. Same denoted things, different > senses. > > You object to the terms "magic" and "oracle". Fine. "magic" is > strucken from the vocabulary as a nonce, and "oracle" can be replaced > by "function of specified range and domain", although you should note > that the term "oracle" is often used in subset reasoning like this. Just so we're talking about the same thing, I think Daniel is saying: Magic: Unwritten functionality Oracle: Authoritative source Let me know if I'm wrong. The thing that makes it hard to get at what he's saying is that he's mixing the language of mathematics and mysticism :). I don't always understand him either (due to lack of time :) ) but the bits I understand seem right. Just another question; I love the content of this list, but I'm not so keen on sorting through 30 messages with the subject "CLI" or "available network automation tools". If others agree, it might be nice if we changed the subject line when the subject changes. :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim.nelson@webalive.biz http://www.webalive.biz/ "Your Business, Your Web, Your Control" From network-automation-owner@greatcircle.com Tue Apr 19 22:51:31 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 07DBB32C153 for ; Tue, 19 Apr 2005 22:51:24 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 89D3B19357; Wed, 20 Apr 2005 01:51:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16997.60883.453122.285903@perdition.linnaean.org> Date: Wed, 20 Apr 2005 01:51:15 -0400 To: Tim Nelson Cc: Network Automation List Subject: Magic, Oracles, tomatos, and meaning questions not to ask In-Reply-To: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/89 X-Sequence-Number: 89 > Just so we're talking about the same thing, I think Daniel is > saying: > Magic: Unwritten functionality Well, I was actually thinking about my usage of this term recently due to another context. Usually, I seem to mean something where somebody had to stare at the system the right way and have the right knowledge in hand to say "tweak here, here, and here, and it will behave better". The thing I was thinking of was TCP congestion control: the algorithms involved are simple enough to describe, but there is interesting emergent behavior when you put a bunch of them together. Van Jacobson et al's work here is what I would call "magic", even though it exists in a reified executable form. > Oracle: Authoritative source Eh, don't know that I like this one. The overall structural description of a few days works better for me, but doesn't have a two word label other than "oracle function", and we don't like that. More expansively, "the oracle" is really a small semantic processing tool coupled with semantics for many, many systems small and large (these semantics being written by us). The tool enables composing semantic information together in different ways for reasoning purposes towards asking questions like "configuration" and more generally "meaning": if I emit the utterance "no router bgp" to a particular router in my network, just what is the effect on the world? If I wanted to perform the "rollback" operation after speaking such a statement with minimal effect, what must I really say, and what am I really asking for anyway? When you have semantic tools, meaning is just another expressible thing, typically in the form of a function value of some sort; the domain and range of the function value are specific to the realm of the semantic. In programming language semantics, the domain and range often relate to the state of a very abstract machine -- this sort of thing produces the ability to reason with the meaning of side effects, for example. Our worlds are larger. > The thing that makes it hard to get at what he's saying is that > he's mixing the language of mathematics and mysticism :). I don't always > understand him either (due to lack of time :) ) but the bits I understand > seem right. You say mathematics, I say tomato. You say mysticism, I say tomato. :) I can't speak for your lack of time, but I can speak for my poor use of the nominal language of discourse. I shall continue towards that nebulous halfway point. I will mostly try to avoid the issues that reek of myticsm to you. But they aren't *entirely* seperable you see unless you are careful with your engineering. Network configuration can probably avoid these issues readily, but some of the configuration spaces I've shown up in have created some interesting edge cases... The edge cases that reek of mysticm are the interesting ones to use to break a model. Pick an absolutely ridiculous infinity point for your model, and see what happens when you try to express this fairly infinite concept in it. What does it look like? Is it clumsy? Does the model completely fall apart in some way? Let me synthesize an example based on some of Juergen's objections about side effects and rollback. Remember how I said the other day that treatment of side effects is "perfectly doable", and cited the denotational semantic of scheme embedded in R5RS as an example? Well, it's not *entirely* truthful, because "side effect" can be more or less complicated depending on precisely what we said, and its context. The semantic for scheme presents meaning functions for side effects within the world of scheme. Side effects crossing the world of scheme into the broader world are your problem. Side effects within the world of scheme that are expressed are things like "what does '(set! foo 25)' mean?". Side effects crossing from scheme to the broader world that are not expressed in the semantic would include statements like: what does (begin (display "what time is it?") (newline)) mean? The reason why such a case isn't handled is that it's "just a little bit harder" than the case of in language side-effects. One way of shedding more light on the difference between the two is the degree of closure we can provide over the two, and our ability to observe the side effect. Side effects that happen "within scheme" are fairly "closable" -- we can write down a world of "scheme interpreter" mathematically (as the semantic of scheme does) and show what the side effect means soley within the context of that world readily. But these side effects can't be observed from outside the world of scheme. Side effects crossing from scheme to the broader world have closure problems: you have to define what the broader world is in order to define a meaning function for the side effect. As far as visibility goes, naturally the point of such a side effect is to provide a window of observation from our broader world into realms like our scheme interpreter. Definining this broader world can get dangerous if we aren't careful: I suppose you could call it mysticsm past a point, or asking annoying theological questions, or any number of things. To give you some idea of what you can do if you aren't careful, consider the scheme program "(begin ..." from above again. I can run this program and insert its output in the next line: what time is it? as I have done above. Consider the program output for a moment, and reconsider the question of: what does (begin (display "what time is it?") (newline)) mean? given that you, dear reader, have been specified as a part of this system. You are human, and any and all responses any and all of you could possibly imagine to make this meaning function as uncomputable as possible are fair game. I will assert that infinity is a good tool for abusing your models. Anyway, we seem to be drifting a little bit, other than the fact that having such extreme examples of "here are questions not to ask" written down is useful. Where are we on "specification, specification, specification?" I've heard: * The usual semantic/knowledge representation problems. * You want a rollback operator in the resultant calculus to hang arbitrarily complicated rollback functions from. * Very distributed realization to provide proper robustness properties, etc. From network-automation-owner@greatcircle.com Wed Apr 20 20:49:02 2005 X-Original-To: network-automation@greatcircle.com Received: from throat.webalive.biz (throat.webalive.biz [69.93.211.26]) by mycroft.greatcircle.com (Postfix) with SMTP id 537B732C19B for ; Wed, 20 Apr 2005 20:48:57 -0700 (PDT) Received: (qmail 32051 invoked from network); 21 Apr 2005 04:47:50 -0000 Received: from unknown (HELO ?10.0.1.254?) (203.222.142.146) by 0 with SMTP; 21 Apr 2005 04:47:50 -0000 Date: Thu, 21 Apr 2005 13:50:29 +1000 (EST) From: Tim Nelson X-X-Sender: tnelson@tnelson.webalive.biz To: Daniel Hagerty Cc: Network Automation List Subject: Re: Magic, Oracles, tomatos, and meaning questions not to ask In-Reply-To: <16997.60883.453122.285903@perdition.linnaean.org> Message-ID: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> <16997.60883.453122.285903@perdition.linnaean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200504/90 X-Sequence-Number: 90 On Wed, 20 Apr 2005, Daniel Hagerty wrote: > > Just so we're talking about the same thing, I think Daniel is > > saying: > > Magic: Unwritten functionality > > Well, I was actually thinking about my usage of this term recently > due to another context. Usually, I seem to mean something where > somebody had to stare at the system the right way and have the right > knowledge in hand to say "tweak here, here, and here, and it will > behave better". The thing I was thinking of was TCP congestion So magic is saying: - The map is not the territory - Here, use my map and see if that helps ? > > Oracle: Authoritative source > > Eh, don't know that I like this one. The overall structural > description of a few days works better for me, but doesn't have a two > word label other than "oracle function", and we don't like that. > > More expansively, "the oracle" is really a small semantic > processing tool coupled with semantics for many, many systems small > and large (these semantics being written by us). The tool enables So the oracle includes the items below: - Language X (for want of a better term) which is standard, and specifies the config you want - The implementation of Language X which takes language X and makes it happen on hardware a, b, and c - Our own configuration in language X Yes? [snipped examples; I like examples :) ] > In programming language semantics, the domain and range often > relate to the state of a very abstract machine -- this sort of thing > produces the ability to reason with the meaning of side effects, for > example. Our worlds are larger. By which you mean that networks don't fit the abstract machine model? > > The thing that makes it hard to get at what he's saying is that > > he's mixing the language of mathematics and mysticism :). I don't always > > understand him either (due to lack of time :) ) but the bits I understand > > seem right. > > You say mathematics, I say tomato. You say mysticism, I say > tomato. :) > > I can't speak for your lack of time, but I can speak for my poor > use of the nominal language of discourse. I shall continue towards > that nebulous halfway point. You could instead speak for the fact that some of your content is actual hard content :). If I don't make the time to grapple with it, that's not your problem :). But I do when I can. > I will mostly try to avoid the issues that reek of myticsm to you. I'm not complaining about the mysticism (I have more trouble with the maths :) ). After all, I am: - A perl programmer (Magic variables, DWIMmery) - A Christian (see theology/mysticism link in your e-mail) - A role-playing game player (well, not for years, but I *was*) So magic is fine by me, as long as it's *well-defined* magic :). [snipped lovely example which I think I managed to understand :) ] > I will assert that infinity is a good tool for abusing your > models. s/abusing/stress-testing/ as well :). -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim.nelson@webalive.biz http://www.webalive.biz/ "Your Business, Your Web, Your Control" From network-automation-owner@greatcircle.com Thu Apr 21 00:42:29 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id F33BD32C201 for ; Thu, 21 Apr 2005 00:42:26 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 879791935C; Thu, 21 Apr 2005 03:42:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16999.22874.961322.806821@perdition.linnaean.org> Date: Thu, 21 Apr 2005 03:42:18 -0400 To: Tim Nelson Cc: Network Automation List Subject: Re: Magic, Oracles, tomatos, and meaning questions not to ask In-Reply-To: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> <16997.60883.453122.285903@perdition.linnaean.org> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/91 X-Sequence-Number: 91 > So magic is saying: > - The map is not the territory > - Here, use my map and see if that helps > > ? That could be magic. What you just said could read to me as "there is an abstraction underlying my concrete; apply this abstraction to your concrete and see if it helps" or similar (perhaps that isn't what I said originally, but it's certainly a useful expression here). There will no doubt be other things in the world that I would consign to "magic" if I wasn't careful. > So the oracle includes the items below: > - Language X (for want of a better term) which is standard, and > specifies the config you want > - The implementation of Language X which takes language X and makes > it happen on hardware a, b, and c > - Our own configuration in language X > > Yes? Took several attempts to parse, but if I see what you meant, yes. I can't be sure, due to the nature of communication. In particular, when we get to the point of needing precision, we need to examine key words like "language" and "configuration" to give them "proper" definitions. "Configuration" is *definitely* a problem word. > By which you mean that networks don't fit the abstract machine > model? No; it's more that programming language semantics typically gets to dismiss a lot of cases we end up caring about as not very interesting or not worth chasing, whereas we *need* to chase this kind of stuff a little more closely. Also, programming semantics usually don't think of "configure" as a seperate thing. It turns out that when you *do*, you discover that the math problem on your hands was a little bigger than you thought. "Configure" inherently means closure problems. If there were no closure problems, you wouldn't offer "configure". You can still do abstract machines, they just need to be pretty big abstract machines. And they have to give you tools for dealing with the closure problem in a way that nothing I've seen really does. To build an example of what I mean by the previous, consider the evil scheme program that asked you what time it was, and its meaning before: it is actually possible to provide some degree of reasoning with such a program (short of the point where you wire it up to the humans and start asking unclosable questions). You *want* to be able to express a semantic of scheme that includes expressing "what will happen when I say '(newline)'?"; the questions in the realm of "is the output wired up to /dev/null" versus "is the output going to humans?" need to be seperable from the scheme semantic (or whatever the foobar is). Also, just to point in the direction of some obligatory prior art, it's not as if math isn't "somewhere" here in the realm of big systems; see for example "Communicating Sequential Processes" (CSP), "Calculus of Communicating Systems" (CCS), The Z Specification Language, Pi calculus, and way too much other stuff that I haven't had the time to try to digest all of myself either. > You could instead speak for the fact that some of your content is > actual hard content :). If I don't make the time to grapple with it, > that's not your problem :). But I do when I can. Well, I appreciate you taking the effort involved to debug my horrific content generator -- getting debugging time on this stuff anywhere has been, um, "difficult". We're all busy. > So magic is fine by me, as long as it's *well-defined* magic :). As we shall see, getting to "well defined" is complex here: we are dealing with questions of meaning of language and such. As you said, the topic at hand is actual hard content -- there is a great deal of circularity involved in breaking definitions apart. > [snipped lovely example which I think I managed to understand :) ] Good. Knowing that my writing is getting better if I focus on providing the right examples does help. > s/abusing/stress-testing/ as well :). Yup, yup. Now, I'm going to hit the fast forward button a bit here; this will look a little blurry if only because I'm making this stuff up as opposed to having been taught it. Denotational semantic approaches boil down to producing some function such that denoted = f(sense) where "sense" could perhaps be a scheme program like "(set! foo 25)", or a perl program, or what have you. Magic is in figuring out the function f (and thus, denoted) for your language (scheme was intended to be "easy". Don't try to figure out f for perl.) Part of what is implied by the form above is that it is possible for the semantic to have a platonic, context free meaning. In the real world, it almost never works like that. I can run the "evil scheme program" that asks about the time, and depending on where I run it, different things will happen. If I send it out in mail to you as I have, that's one thing to the world's state; if I direct its output to /dev/null, that's another. "Configuration" is pretty much by definition dealing with questions of the form denoted = f(sense, context) where the concept of context becomes increasingly complicated. I could say more on the subject of context, but that would be getting ahead of myself. To justify the previous, consider the perl program: while($ARGV[0]){} This obviously is a "complete" perl program. However, its termination behavior is dependant upon "configuration"; there is state drawn from the broader world that affects what happens. Most any kind of interesting question we're likely to deal with is more likely to be specified in this form of a context, rather than the other form where the program is complete. As we're talking about producing languages (in this list, we're talking about "Network Management Systems" that can, for example "rollback") with well defined semantics, you should be noting the mathematical flames licking at the tension between trying to say denoted = f(sense) to our established mathematical tools, but asking questions of the form denoted = f(sense, context) in a fairly general fashion within the smaller expression. Anyway, much more that could be said to perhaps clarify the above, or further muddy it with "so what do you do about this problem?". From network-automation-owner@greatcircle.com Thu Apr 21 22:26:22 2005 X-Original-To: network-automation@greatcircle.com Received: from throat.webalive.biz (throat.webalive.biz [69.93.211.26]) by mycroft.greatcircle.com (Postfix) with SMTP id BCBCA32C1A1 for ; Thu, 21 Apr 2005 22:26:20 -0700 (PDT) Received: (qmail 13628 invoked from network); 22 Apr 2005 06:25:21 -0000 Received: from unknown (HELO ?10.0.1.254?) (203.222.142.146) by 0 with SMTP; 22 Apr 2005 06:25:21 -0000 Date: Fri, 22 Apr 2005 15:27:56 +1000 (EST) From: Tim Nelson X-X-Sender: tnelson@tnelson.webalive.biz To: Daniel Hagerty Cc: Network Automation List Subject: Re: Magic, Oracles, tomatos, and meaning questions not to ask In-Reply-To: <16999.22874.961322.806821@perdition.linnaean.org> Message-ID: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> <16997.60883.453122.285903@perdition.linnaean.org> <16999.22874.961322.806821@perdition.linnaean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Archive-Number: 200504/92 X-Sequence-Number: 92 On Thu, 21 Apr 2005, Daniel Hagerty wrote: > > So magic is saying: > > - The map is not the territory > > - Here, use my map and see if that helps > > > > ? > > That could be magic. What you just said could read to me as > "there is an abstraction underlying my concrete; apply this > abstraction to your concrete and see if it helps" or similar (perhaps > that isn't what I said originally, but it's certainly a useful > expression here). There will no doubt be other things in the world > that I would consign to "magic" if I wasn't careful. Ok. To summarise, "magic" is the above plus other, yet-to-be-defined stuff :). Yes? No? > > So the oracle includes the items below: > > - Language X (for want of a better term) which is standard, and > > specifies the config you want > > - The implementation of Language X which takes language X and makes > > it happen on hardware a, b, and c > > - Our own configuration in language X > > > > Yes? > > Took several attempts to parse, but if I see what you meant, yes. > > I can't be sure, due to the nature of communication. In > particular, when we get to the point of needing precision, we need to > examine key words like "language" and "configuration" to give them > "proper" definitions. "Configuration" is *definitely* a problem word. By language, I mean a programming or configuration language (poor definition) eg. cfengine or perl. By configuration, I mean a "program" written in the above language. Although in a networks context, program usually specifies desired state rather than a series of actions (sorry, proceduralist here :) ). [Bits snipped; I think I got them] > Now, I'm going to hit the fast forward button a bit here; this > will look a little blurry if only because I'm making this stuff up as > opposed to having been taught it. > > > Denotational semantic approaches boil down to producing some function > such that > > denoted = f(sense) > > where "sense" could perhaps be a scheme program like "(set! foo 25)", > or a perl program, or what have you. Magic is in figuring out the > function f (and thus, denoted) for your language (scheme was intended > to be "easy". Don't try to figure out f for perl.) Ok, so I guess my "Language X" above is equivalent to a definition of f(), my "implementation" above is an implementation of f(), and my "configuration" above is equivalent to "sense". I'm glad to hear my configuration makes sense :-} (<-- evil grin). > Part of what is implied by the form above is that it is possible for > the semantic to have a platonic, context free meaning. In the real > world, it almost never works like that. I can run the "evil scheme > program" that asks about the time, and depending on where I run it, > different things will happen. If I send it out in mail to you as I > have, that's one thing to the world's state; if I direct its output to > /dev/null, that's another. > > "Configuration" is pretty much by definition dealing with questions of > the form > > denoted = f(sense, context) > > where the concept of context becomes increasingly complicated. I > could say more on the subject of context, but that would be getting > ahead of myself. > > To justify the previous, consider the perl program: > > while($ARGV[0]){} > > This obviously is a "complete" perl program. However, its termination > behavior is dependant upon "configuration"; there is state drawn from > the broader world that affects what happens. Most any kind of > interesting question we're likely to deal with is more likely to be > specified in this form of a context, rather than the other form where > the program is complete. > > As we're talking about producing languages (in this list, we're > talking about "Network Management Systems" that can, for example > "rollback") with well defined semantics, you should be noting the > mathematical flames licking at the tension between trying to say > > denoted = f(sense) > > to our established mathematical tools, but asking questions of the > form > > denoted = f(sense, context) > > in a fairly general fashion within the smaller expression. Ok, I'm missing these last two bits. What are our "established mathematical tools"? Are they currently existing languages like Cisco's IOS config language? :) -- Tim Nelson Server Administrator WebAlive Technologies Global Level 1 Innovation Building, Digital Harbour 1010 LaTrobe Street Docklands, Melbourne, Vic, 3008 Phone: +61 3 9934 0812 Fax: +61 3 9934 0899 E-mail: tim.nelson@webalive.biz http://www.webalive.biz/ "Your Business, Your Web, Your Control" From network-automation-owner@greatcircle.com Thu Apr 21 23:05:59 2005 X-Original-To: network-automation@greatcircle.com Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mycroft.greatcircle.com (Postfix) with ESMTP id 597A732C482 for ; Thu, 21 Apr 2005 23:04:23 -0700 (PDT) Received: by rproxy.gmail.com with SMTP id r35so510226rna for ; Thu, 21 Apr 2005 23:04:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=C/386jDOg7JVuRIVGzJIMeevTKuKWcAREYz7+Ojxyuc6qfwk1Mvh1RyGcHUV84FgKbUsUEgooZJ0hj7WQO9UmIRdW7ob92p7D9arBVNEzUKDv0Mb5TDraeFPZHCNyC8LHCYjVcus0JM7aDm1PZVwh75f6u+8yH3NGkYZsPATAuA= Received: by 10.38.125.45 with SMTP id x45mr3211548rnc; Thu, 21 Apr 2005 23:04:23 -0700 (PDT) Received: by 10.39.1.43 with HTTP; Thu, 21 Apr 2005 23:04:22 -0700 (PDT) Message-ID: <7654d9d050421230473da49af@mail.gmail.com> Date: Fri, 22 Apr 2005 16:04:23 +1000 From: Andrew Fort Reply-To: Andrew Fort To: Network Automation List Subject: objects and relationships Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Archive-Number: 200504/93 X-Sequence-Number: 93 Essentially, what I want to see is the ability to define a service on the network, from port A to port B. We run a metro ethernet network. It's a simple one, there a little EoMPLS, there is some 1483-bridging for some ATM paths. As we also do IP offerings, I'd like to be able to say "build an IP (static) service terminating on switch X, port Y. add block blah of address space", which would then bring along with it the commands necessary to build the layer 2 service across the network, and then build the IP interface and necessary static routes. So, I see we need the following in such a specification: - Objects (switches, ports, routes, BGP neighbors, etc).=20=20 - Relationships between these objects. - Identifying what a service means in terms of relationships between objec= ts. - A way of instantiating the commands used to make the service active on each device involved (lets avoid the use of the word "configuration"). This last point has been largely covered with the exception of some of the particulars of rollback. So, as Daniel Hagerty suggests, this is largely the problem of knowledge representation. The relationships between the objects will end up defining the commands for each device that cause them to either establish a connection to share state (say, an IGP) or pass traffic due to implied state (VLANs attached to a tagged interface at either end).=20 Explicitly, services have pre-requisite services (service objects are related to other service objects, in a precedence order?), e.g. I need a tail to build that IP interface. At the present I've been playing with the idea of building this with template manipulation and pre-requisites built by make (so I have a target which requires pre-requisites which are built using m4). This is a straight-forward way to build lists of vendor specific commands (configuration files), but it is a per-device approach. For individual devices, it works well (dependencies are handled, so things work). I think this should work well where some of the state is managed by network protocols (RADIUS, for example), because in that case the service is defined by AAA configuration along with an account on the server. I'm fairly clear on an approach for the bits other than the low level model to create network services out of individual devices and their connections. I think an ER type of approach would be general enough to solve the problem. What material should I be reading to get a better handle on this? :-) -andrew From network-automation-owner@greatcircle.com Fri Apr 22 15:32:48 2005 X-Original-To: network-automation@greatcircle.com Received: from linweb1.bitpusher.com (ns1.bitpusher.com [64.127.99.248]) by mycroft.greatcircle.com (Postfix) with ESMTP id 3555C32C393 for ; Fri, 22 Apr 2005 15:32:46 -0700 (PDT) Received: from localhost (mhalligan@localhost) by linweb1.bitpusher.com (8.9.3/8.8.7) with ESMTP id PAA26040 for ; Fri, 22 Apr 2005 15:32:46 -0700 Date: Fri, 22 Apr 2005 15:32:44 -0700 (PDT) From: "Michael T. Halligan" To: network-automation@greatcircle.com Subject: Basics of router automation. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Archive-Number: 200504/94 X-Sequence-Number: 94 My focus has long been more geared towards managing large server infrastructures. I've only been doing any significant work on networking devices for the past couple of years. Brent's starting of this list was very well-timed for me. I've got kickstart/jumpstart, cfengine/Pikt/ISConf down somewhat well at this point. I'm lacking a good base to start from on all the network devices I manage. I've recently discovered RANCID, and have found it to be a useful tool, and am rather familiar with setting up the more popular opensource monitoring systems (opennms, cricket, cacti, ntop, ossim). I see OSSIM as being a good potential for culminating the mass amount of monitoring data. What I'm finding to be missing from my networking knowledge is network device best practices. Maybe some of you can enlighten me. For example, what are the best ways to manage IOS images and configurations. I run several dozen switches/routers/pix's (ignoring all of the non-cisco gear we maintain) at this point, and have developed a kludgy, but effective template system with perl for maintaining the different configurations. As for applying changes, it's still a far more manual process than I would like to apply new IOS updates, make broad sweeping network config changes, etc. What would be nice, and is probably common place, would be network booting all of our devices via tftp & dhcp/bootp. Is everybody rolling their own systems for this type of device management, or are their some more common open-source tools for this more basic process of network management? From network-automation-owner@greatcircle.com Fri Apr 22 16:31:37 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 1BF3B32C1CF for ; Fri, 22 Apr 2005 16:31:36 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id D13BC199DE; Fri, 22 Apr 2005 19:31:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.35159.678864.412311@perdition.linnaean.org> Date: Fri, 22 Apr 2005 19:31:35 -0400 To: Andrew Fort Cc: Network Automation List Subject: objects and relationships In-Reply-To: <7654d9d050421230473da49af@mail.gmail.com> References: <7654d9d050421230473da49af@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/95 X-Sequence-Number: 95 > - Objects (switches, ports, routes, BGP neighbors, etc). > - Relationships between these objects. Just remember that many things that may seem "relationship" are often object, depending on what your reasoning is. A CAT5 4 twisted pair wire running between two of your switches is often an object in many systems, not a relationship. (Maybe obvious, but I thought I'd mention it). > "configuration"). This last point has been largely covered with the > exception of some of the particulars of rollback. If the last points have been largely covered, but some of the particulars of rollback haven't, then the last points haven't really been covered. Rollback ought to be crystal clear given the last points, and if it isn't, something is missing. Tell me what you see as unclear in rollback. > I'm fairly clear on an approach for the bits other than the low level > model to create network services out of individual devices and their > connections. I think an ER type of approach would be general enough > to solve the problem. What material should I be reading to get a > better handle on this? :-) Dunno. One thing I remember from a cube mate several jobs ago was that he was having a lot of trouble with the fact that naive network questions can require huge self-joins (what't the diameter of your network when you count all the managaged objects?), but I suspect a lot of those problems can be solved with some cleverness: you can build a one way join of some sort (pre-computing a layer 3 world, for instance) to avoid having to join twenty things to get to how 192.168.1.1 and 192.168.1.2 are related across a complex point to point link with up and down muxing along the way. From network-automation-owner@greatcircle.com Fri Apr 22 16:41:21 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 7BF1D32C320 for ; Fri, 22 Apr 2005 16:41:20 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id AD5EF193BF; Fri, 22 Apr 2005 19:41:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.35739.630082.558146@perdition.linnaean.org> Date: Fri, 22 Apr 2005 19:41:15 -0400 To: Andrew Fort Cc: Network Automation List Subject: objects and relationships In-Reply-To: <7654d9d050421230473da49af@mail.gmail.com> References: <7654d9d050421230473da49af@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/96 X-Sequence-Number: 96 > I'm fairly clear on an approach for the bits other than the low level > model to create network services out of individual devices and their > connections. I think an ER type of approach would be general enough > to solve the problem. What material should I be reading to get a > better handle on this? :-) Oh yes, one other vague "helpful" (hah!) comment: As you have your m4/make layer figured out, try to figure out the mathematical version of what it's doing. The set of problems that the union of your m4/make layer has determines what you really require of your low level model. E/R is just another language of expressing the boundary between these parts; it isn't the only way. You can always invent your own language, and then invent means of mapping it onto established languages like E/R. Doing it this way has the benefit of helping you figure out what you're really asking of your low level layer, and just what it is you lose when you try to fit it in a particular model that wasn't designed to be more general at the cost of some sacrifice (e.g. E/R). Really, note how much of a market their is for object/relational mapping products. A lot of people don't actually want to work in a relational model, despite it having nice solutions to their problems. It is more convenient to them to work in an object representation, and have software work out the impedence matching. From network-automation-owner@greatcircle.com Fri Apr 22 19:52:32 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 2220632C41F for ; Fri, 22 Apr 2005 19:52:30 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id AB15919364; Fri, 22 Apr 2005 22:52:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.47213.591471.467730@perdition.linnaean.org> Date: Fri, 22 Apr 2005 22:52:29 -0400 To: Tim Nelson Cc: Network Automation List Subject: Re: Magic, Oracles, tomatos, and meaning questions not to ask In-Reply-To: References: <9BD20C9B8D21C04FA661826D202E631F01E2996F@gicorp0.gicorp.mypop2pop.com> <426409C3.5090507@cisco.com> <16996.11469.138111.346637@perdition.linnaean.org> <20050418224131.GA12946@boskop.local> <16996.21273.400025.376696@perdition.linnaean.org> <20050419011005.GA13334@boskop.local> <16996.30757.915955.499291@perdition.linnaean.org> <16997.60883.453122.285903@perdition.linnaean.org> <16999.22874.961322.806821@perdition.linnaean.org> X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/97 X-Sequence-Number: 97 > Ok. To summarise, "magic" is the above plus other, > yet-to-be-defined stuff :). Yes? No? "Yes". We will avoid the "other" category as irrelevant for now. > By configuration, I mean a "program" written in the above > language. Although in a networks context, program usually specifies > desired state rather than a series of actions (sorry, proceduralist here > :) ). You allude to the difference between imperitive and declaritive forms of communication. "Stand up!" versus perhaps "Proper people stand up in this situation. You are a proper person." Math is the land of the declarative. I don't care if you chose to speak an imperitive language if your problem is better said as such. HOWEVER, we must be able to express your imperitive as the declaration of a side effect within a mathematical world if I have any hope of reasoning with it. This is what the scheme semantic does, for example. There are expressible side effects, but the result of a side effects is a value, not a side effect. As to questions like "does some oracle approach require a full semantic of perl", no, that would be hopeless. The non-tractability of things like full perl interpreters or human beings is something you go out of your way to *avoid* explaining. If your system requires you explain such a thing, your system is probably wrong. Of course, sometimes you can't avoid explaining something ridiculous, like the various hideous scenarious brought up in rollback of devices with no real support of it. Sometimes, it sucks to be you. Would you rather hide the semantic implied by your program within a general purpose language, or would you like to expose the horror of the semantic in all its unglory and use this information as data within your program? I would ask that you do the latter if you want to share this information with me. A program in foobar is good too, but not as good. > Ok, so I guess my "Language X" above is equivalent to a > definition of f(), my "implementation" above is an implementation of f(), > and my "configuration" above is equivalent to "sense". I'm glad to hear > my configuration makes sense :-} (<-- evil grin). Semantic approaches use more seperation than you seem to indicate. You speak of a single function application, when in a denotational world of the sort I'm speaking of, your desired effect involves more than one application (perhaps many more). In a world such as my own, your Language X example as originally used probably looks something like: denoted = f(sense-in-X, language-X) cisco-cfg = f(denoted, reify-cisco-config) juniper-cfg = f(denoted, reify-juniper-config) where the key point in what I do is that I only write f once. It could be said that what this "really" says (I'm handwaving away a lot) is: denoted = language-X(sense-in-X, language-X) cisco-cfg = reify-cisco-config(denoted, language-X) juniper-cfg = reify-juniper-config(denoted, reify-juniper-config) It is important to note that functions like language-X and reify-cisco-config are written by users. I write f and supporting infrastructure. A real process will probably involve a great deal many more applications of f, in parts like language-X, reify-cisco-config, and how you put all these parts together into still broader things to produce "and configure my cisco router please". If what you do needs config fragments sometimes rather than whole configs, nothing prevents you from factoring thusly. If fact, denotational semantic approaches encourage such factoring. And now for the "fine print": The last "program" I wrote as a "proof" of f was: denoted = f((5, 7), greatest-common-denominator) This is *much* simpler than the others, but then, that's the point. If I can't make gcd, I can't possibly make bigger things like a network, or a generalized language to deploy a distributed system into development, staging, and producting systems, or any number of other tools I desperately want (*). Build small, and work up. I'm limited by copious free time (**). At this level of primitive, the "models" we like to speak of here don't exist. Such models are something you make from the more primitive mathematics we have on hand. You need a few magic primitives: * eval (aka f) * a denoted locator language * a denoted definer language * a bunch of locatable denoted primitives, like arithmetic operators, etc. There are no doubt some more key parts, but that what's playing with the basics as I am is for. Once you have a good basis, you try to build upward. > Ok, I'm missing these last two bits. What are our "established > mathematical tools"? Are they currently existing languages like Cisco's > IOS config language? Sadly, no, we're at a much higher order of "the tools don't seem to be there". I speak of the Scott Strachey semantic approach, as an example. It expects that your question is of the form denoted = f(sense) and as I've demonstrated, our questions are not. Scott Strachey is the most rigorous and general denotational semantic system I am aware of, and it isn't sufficient to do what we seem to need in any graceful way. We have hammers & chisels, and we can always make our problem fit in it, but, um... I would like to tell you that the mathematical background was better than this. A point can certainly be against my lack of qualifications to speak of the math: I've got an american public high school degree of sub-spectacular performance to speak of. I did not arrive at being able to speak of what I speak of by choice. I've been wandering around many places, include what is now MIT CSAIL for a long time now, and the smart people there can't tell me good news as my questions become ever more pointed. I'm obviously a net.kook, but despite this, the welcome matt is out for me in many such places barring copious free time. (*) There will be a lot of magic to work out, but one of the gratuitous tricks that's "perfectly tractable" is to: 1. Write the "level 0" denoted interpreter in scheme. 2. Write the system again in denoted. (probably required sooner or later for "long story" reasons) 3. write a "denoted->perl" compiler in denoted. 4. Apply the denoted->perl compiler to denoted. and what you get is a denoted interpreter, in perl. This is down there on the list, but is supposed to be doable; if this isn't doable, something is supposed to be wrong with the math (as this doesn't involve asking about the meaning of perl, but unparsing into it, perfectly doable). As I've said before, if you want to talk to me offline, especially to see actual code or whatever, feel free to ask. I haven't made much code, but your specifics are always wonderful to think about. (**) But I obviously have time to blather on this mailing list. It could be said that writing on mailing lists thusly is actually part of the process of writing f. From network-automation-owner@greatcircle.com Fri Apr 22 20:07:57 2005 X-Original-To: network-automation@greatcircle.com Received: from perdition.linnaean.org (dsl092-073-217.bos1.dsl.speakeasy.net [66.92.73.217]) by mycroft.greatcircle.com (Postfix) with ESMTP id 213CB32C201 for ; Fri, 22 Apr 2005 20:07:57 -0700 (PDT) Received: by perdition.linnaean.org (Postfix, from userid 31013) id 778B219360; Fri, 22 Apr 2005 23:07:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17001.48140.412526.130342@perdition.linnaean.org> Date: Fri, 22 Apr 2005 23:07:56 -0400 To: Network Automation List Subject: "limit ordinal" X-Mailer: VM 7.19 under Emacs 20.7.1 Reply-To: Daniel Hagerty From: Daniel Hagerty X-Archive-Number: 200504/98 X-Sequence-Number: 98 I mentioned a few weeks ago the notion of treating the generation of the addresses in a subnet as akin to the integers, except for the problem of the broadcast address. Math already has a name for systems that have this behavior. If we were pretending that our subnet to allocate addresses from was a number, then the first "special" "you can't get there from here" number is called the "limit ordinal". In pseudo-scheme (pardon the paren happy language), the result of: (let* ((zero "192.168.0.1/24") (broadcast? (make-broadcast-test zero)) (successor (lambda (x) (cond ((broadcast? x) (error "no more room")) (else (+ x 1)))))) (successor "192.168.0.255/24")) is the error "no more room". Thus, 192.168.0.255 is the limit ordinal of this system.