[48715] in North American Network Operators' Group
RE: What's wrong with provisioning tools?
daemon@ATHENA.MIT.EDU (Daniska Tomas)
Thu Jun 13 09:17:17 2002
Date: Thu, 13 Jun 2002 15:15:23 +0200
From: "Daniska Tomas" <tomas@tronet.com>
To: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
This is a multi-part message in MIME format.
------_=_NextPart_001_01C212DC.603F5122
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
by the way - those speech-synthesis terminals were a just joke or is =
anyone really using them? :))
=20
=20
--
=20
Tomas Daniska
systems engineer
Tronet Computer Networks
Plynarenska 5, 829 75 Bratislava, Slovakia
tel: +421 2 58224111, fax: +421 2 58224199
=20
A transistor protected by a fast-acting fuse will protect the fuse by =
blowing first.
-----Original Message-----
From: Mathew Lodge [mailto:mathew@cplane.com]=20
Sent: 12. j=FAna 2002 23:25
To: David Daley; nanog@trapdoor.merit.edu
Subject: Re: What's wrong with provisioning tools?
David,
Almost all of what you're talking about is network device configuration =
file management -- there are several solutions out there today that do =
this. The rest is template-based configuration provisioning tools, which =
typically have no operational model of the network -- so it should be no =
surprise that they generate the wrong configurations. So there are two =
questions:
The first is why aren't operators using even simple config management =
tools (Is every single one lacking somehow, or is it operational =
intertia?)
The more interesting one, IMHO, concerns operational complexity. It =
seems that complexity is really what makes it hard to operate an IP =
network -- even with highly skilled engineers -- and is also the barrier =
to writing useful network provisioning and configuration software. What =
abstractions would make it easier to understand the network and hence =
figure out the right configuration changes to make, so software wouldn't =
generate config changes that are broken?
Regards,
Mathew
At 01:38 PM 6/12/2002 -0400, David Daley wrote:
A couple of times during NANOG25, from the floor and from the podium, =
it was identified that the tools available for managing networks were =
garbage. I was surprised to hear that even real basics, such as change =
control and configuration management, weren't widely adopted. There =
definitely seemed to be an acceptance (and perhaps this is only true at =
some carriers) that many problems facing providers today are as a result =
of a dearth of decent tools to configure 'best common practices' into =
the routers - and as a result of this, the 'problems' with the networks =
were not with the h/w and/or the protocols they support, but with the =
people, and their lack of experience and/or ability to properly =
configure the boxes.
=20
A couple of comments that I heard over the last few days:
1) User interfaces are horrible and counter intuitive - I want 'xyz' out =
of my GUI
2) Systems blindly apply bad configurations to routers - they should be =
able to do 'some' verification before crashing my network - and can't =
roll back after they wreck things
3) Change control either doesn't exist, isn't usable, or isn't granular =
enough
4) There isn't anything to track non sanctioned changes to the network =
(i.e.: hacker induced re-configurations)
=20
I would very much like to hear about "specific" needs for (provisioning) =
tools that would satisfy your needs - needs that are either being poorly =
met to today, or not at all. In the hopes of preventing a vendor-bash =
extravaganza, I would suggest as a point of reference, that the NMS =
recommendations presented by Avi Freedman during the conference =
("Industry/Government Infrastructure Vulnerability Assessment: =
Background and Recommendations". Of the recommendations pertinent to =
network management, many refer to future-features. As an additional =
attempt to constraint the discussion, I would recommend that the needs =
identified be realistic (i.e.: supportable on current equipment, the =
cost of the solution would be less than the cost of the problem, etc).
=20
Cheers,
David
=20
-
David Daley=20
+1.905.922.6560 (global)=20
daley@montagueriver.com=20
www.montagueriver.com <http://www.montagueriver.com/> =20
Montague River Networks Inc.=20
=20
------_=_NextPart_001_01C212DC.603F5122
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2716.2200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D882511413-13062002><FONT face=3DArial color=3D#0000ff =
size=3D2>by the=20
way - those speech-synthesis terminals were a just joke or is anyone =
really=20
using them? :))</FONT></SPAN></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>--</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tomas Daniska</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>systems =
engineer</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Tronet Computer =
Networks</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Plynarenska 5, 829 75 =
Bratislava,=20
Slovakia</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>tel: +421 2 58224111, fax: =
+421 2=20
58224199</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV align=3Dleft><EM><FONT size=3D2><FONT size=3D2>
<P>A transistor protected by a fast-acting fuse will protect the fuse by =
blowing=20
first.</P></FONT></FONT></EM></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Mathew Lodge=20
[mailto:mathew@cplane.com] <BR><B>Sent:</B> 12. j=FAna 2002 =
23:25<BR><B>To:</B>=20
David Daley; nanog@trapdoor.merit.edu<BR><B>Subject:</B> Re: What's =
wrong with=20
provisioning tools?<BR><BR></FONT></DIV>David,<BR><BR>Almost all of =
what=20
you're talking about is network device configuration file management =
-- there=20
are several solutions out there today that do this. The rest is =
template-based=20
configuration provisioning tools, which typically have no operational =
model of=20
the network -- so it should be no surprise that they generate the =
wrong=20
configurations. So there are two questions:<BR><BR>The first is why =
aren't=20
operators using even simple config management tools (Is every single =
one=20
lacking somehow, or is it operational intertia?)<BR><BR>The more =
interesting=20
one, IMHO, concerns operational complexity. It seems that complexity =
is really=20
what makes it hard to operate an IP network -- even with highly =
skilled=20
engineers -- and is also the barrier to writing useful network =
provisioning=20
and configuration software. What abstractions would make it easier to=20
understand the network and hence figure out the right configuration =
changes to=20
make, so software wouldn't generate config changes that are=20
broken?<BR><BR>Regards,<BR><BR>Mathew<BR><BR><BR><BR><BR>At 01:38 PM =
6/12/2002=20
-0400, David Daley wrote:<BR>
<BLOCKQUOTE class=3Dcite cite=3D"" type=3D"cite"><FONT face=3Darial =
size=3D2>A couple=20
of times during NANOG25, from the floor and from the podium, =
it was=20
identified that the tools available for managing networks were =
garbage. I=20
was surprised to hear that even real basics, such as change =
control=20
and configuration management, weren't widely adopted. There =
definitely=20
seemed to be an acceptance (and perhaps this is only true at some =
carriers)=20
that many problems facing providers today are as a result of a =
dearth of=20
decent tools to configure 'best common practices' into the routers - =
and as=20
a result of this, the 'problems' with the networks were not with the =
h/w=20
and/or the protocols they support, but with the people, and their =
lack of=20
experience and/or ability to properly configure the =
boxes.</FONT><BR><FONT=20
face=3Darial size=3D2> <BR>A couple of comments that I heard =
over the last=20
few days:<BR>1) User interfaces are horrible and counter intuitive - =
I want=20
'xyz' out of my GUI<BR>2) Systems blindly apply bad configurations =
to=20
routers - they should be able to do 'some' verification before =
crashing my=20
network - and can't roll back after they wreck things<BR>3) Change =
control=20
either doesn't exist, isn't usable, or isn't granular enough<BR>4) =
There=20
isn't anything to track non sanctioned changes to the network (i.e.: =
hacker=20
induced re-configurations)<BR> <BR>I would very much like to =
hear about=20
"specific" needs for (provisioning) tools that would satisfy your =
needs -=20
needs that are either being poorly met to today, or not at all. In =
the hopes=20
of preventing a vendor-bash extravaganza, I would suggest as a point =
of=20
reference, that the NMS recommendations presented by Avi Freedman =
during the=20
conference ("Industry/Government Infrastructure Vulnerability =
Assessment:=20
Background and Recommendations". Of the recommendations pertinent to =
network=20
management, many refer to future-features. As an additional attempt =
to=20
constraint the discussion, I would recommend that the needs =
identified be=20
realistic (i.e.: supportable on current equipment, the cost of the =
solution=20
would be less than the cost of the problem, =
etc).</FONT><BR> <BR><FONT=20
face=3Darial size=3D2>Cheers,</FONT><BR><FONT face=3Darial=20
size=3D2>David</FONT><BR> <BR><FONT face=3Darial =
size=3D2>-</FONT><BR>David=20
Daley <BR>+1.905.922.6560 (global) <BR>daley@montagueriver.com =
<BR><A=20
href=3D"http://www.montagueriver.com/"=20
eudora=3D"autourl">www.montagueriver.com</A> <BR>Montague River =
Networks Inc.=20
<BR> </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C212DC.603F5122--
