RE: Reload
"McDonald, Ira" <imcdonald@sharplabs.com> Thu, 17 August 2006 17:45 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDlvv-0005Ns-JM for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:45:31 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDlvq-0007gB-QL for netconf-archive@lists.ietf.org; Thu, 17 Aug 2006 13:45:31 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-netconf@ops.ietf.org>) id 1GDlqN-000EvD-2d for netconf-data@psg.com; Thu, 17 Aug 2006 17:39:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [216.65.151.51] (helo=mail2.sharplabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <imcdonald@sharplabs.com>) id 1GDlqJ-000Eut-T3 for netconf@ops.ietf.org; Thu, 17 Aug 2006 17:39:44 +0000
Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 603E31E15C5; Thu, 17 Aug 2006 10:39:43 -0700 (PDT)
Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <QSC4HPDX>; Thu, 17 Aug 2006 10:39:43 -0700
Message-ID: <789E617C880666438EDEE30C2A3E8D10EEC6@mailsrvnt05.enet.sharplabs.com>
From: "McDonald, Ira" <imcdonald@sharplabs.com>
To: 'Andy Bierman' <ietf@andybierman.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: netconf@ops.ietf.org
Subject: RE: Reload
Date: Thu, 17 Aug 2006 10:39:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1
Hi Andy, Agreed that <exec> as you describe it below is a non-feature. But suppose <exec> had better features: (1) MUST have an input parameter of dataModelIdentifier (2) MUST return an output parameter of status like <get> (3) etc. Why not try to make <exec> a better-than-strictly-opaque operation? Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On > Behalf Of Andy Bierman > Sent: Thursday, August 17, 2006 1:23 PM > To: Balazs Lengyel > Cc: netconf@ops.ietf.org > Subject: Re: Reload > > > Hi, > > I am going to buy in for a nickel and consider > what a standard <exec> operation would entail. > > Most of the details fall out for free because we have > the NETCONF session to "wrapper" the security aspects. > > I strongly support the use of "special" RPCs when appropriate. > IMO, the data-driven 'buttons' in SMI/SNMP need to be nuked, > and a direct RPC method used instead (granularity up to the designer). > So there is no existing RPC operation that could or should be > hacked/extended to provide this feature. A new RPC operation > is clearly the best option. > > > However, this is what the WG describes as <exec in the past: > > <exec> > > Takes 0 - N parameters of an opaque nature, and returns > zero or more unspecified elements, and has zero or more > unspecified side effects. > > IMO there is no point in this 'feature'. > > Unless there was more to it than this, the <exec> node > has no real value. > > > Andy > > > > > > > My point is only: I would see clear advantages for an > <exec> operation > > in the netconf-protocol draft/rfc. > > Balazs > > > > Andy Bierman wrote: > >> Hi, > >> > >> A couple points: > >> > >> 1) The term 'standard' is being used rather loosely here. > >> IMO, standards are produced by independent SDOs and > >> independently implemented in an interoperable manner > >> by many vendors. > > BALAZS: Sorry, I meant the netconf-protocol draft or some > similar IETF > > draft/RFC. > >> > >> 2) The prot document clearly states how to add your own > RPC operations > >> in your own namespace. Hijacking the <get> operation is just > >> about as "wrong" as you can get (from a standards POV). > > BALAZS: I agree that this is a misuse of get, I see it as a > strictly > > temporary hack. > >> > >> Andy > >> > >> > >>> Hello, > >>> I don't want to restart a debate that happened before I > joined the > >>> mail group, so just as > >>> an observation: > >>> > >>> Ericsson widely uses standard <exec> operations; both on > netconf and > >>> also on other similar > >>> hierarchical configuration interfaces. > >>> All custom commands share some common specifics that > could be part of > >>> a standard, and > >>> their standard format would greatly help management > tools. This is > >>> much more then just an > >>> extra XML layer as we (only) standardize the common > features. Common > >>> features include: > >>> - all generic <exec> calls are executed on a specific > managed object > >>> e.g. on interface=eth0, > >>> - have parameters that can be defined in the data model and type > >>> checked during execution > >>> - have return types and sometimes generic exception methods > >>> > >>> By defining a generic <exec> method you don't need to update > >>> capabilities and protocol > >>> mechanisms (new RPCs) just the data model for a new > proprietary command. > >>> Most management tools will anyway be able to handle model based > >>> execution which can be > >>> easily formalized, but few will be able to handle extra > capabilities. > >>> > >>> What Ericsson has done is to misuse the <get> operation which can > >>> take input parameters > >>> and can supply back data. Later we will hopefully make our own > >>> generic <exec> RPC as it is > >>> missing in the standard. > >>> > >>> Some other protocols like LDAP also have a generic <exec> method > >>> (Extended operations). > >>> > >>> Balazs > >>> > >>> Andy Bierman wrote: > >>>> > >>>> Hi, > >>>> > >>>> The <rpc> method itself can be a reload operation: > >>>> > >>>> <rpc message-id="101" xmlns="netconf-blah"> > >>>> <reload xmlns="example.com/blah"/> > >>>> </rpc> > >>>> > >>>> There is no value in a standard <exec> operation > >>>> using proprietary CLI commands. > >>>> > >>>> It justs adds a layer of XML with no real purpose. > >>>> > >>>> The reload operation is actually much harder to standardize > >>>> than it appears. In any case, this is a data model issue, > >>>> and out of current WG scope. > >>>> > >>>> > >>>> Andy > >>>> > >>>> > >>>> >... > >>>>> > >>>>> I have been reading the NETCONF standard and think you > people have > >>>>> done= > >>>>> a=20 > >>>>> great job! As I was reading, I thought of a question > for which I > >>>>> haven= > >>>>> 't=20 > >>>>> found an answer. (I did find some posts that mentioned > >>>>> 'operational'=20= > >>>>> > >>>>> commands when talking about what the WG should work on > >>>>> next---notificat= > >>>>> ions,=20 > >>>>> or whatever---I hope my question doesn't just re-kindle an > >>>>> unrelated=20= > >>>>> > >>>>> discussion topic and my question is left un-answered!) > Please help > >>>>> me=20= > >>>>> > >>>>> understand how this use case should work: > >>>>> > >>>>> There are commands in network devices, like "sdm prefer > routing" on > >>>>> a C= > >>>>> isco=20 > >>>>> 3750, that require a reload. However, I didn't see any > built-in > >>>>> operat= > >>>>> ion=20 > >>>>> for rebooting a device. How should this interaction > with a device, > >>>>> whe= > >>>>> n the=20 > >>>>> configuration option requires a reboot, work using NETCONF=3F > >>>>> > >>>>> I thought of a few options: > >>>>> > >>>>> 0. NETCONF does only configuration--operational commands like > >>>>> "reload" = > >>>>> are=20 > >>>>> outside the scope. > >>>>> > >>>>> 1. Ooops, we forgot about reload (not likely!) or just > haven't got > >>>>> to i= > >>>>> t=20 > >>>>> yet. > >>>>> > >>>>> 2. It's left to the data model--devices can expose a > configuration > >>>>> elem= > >>>>> ent=20 > >>>>> that results in a reload. Something like: > >>>>> > >>>>> <rpc message-id=3D"101" > >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= > >>>>> 0"> > >>>>> <edit-config> > >>>>> <target> > >>>>> <running/> > >>>>> </target> > >>>>> <config> > >>>>> <cli > xmlns=3D=94http://example.com/schema/1.0/config/=94> > >>>>> reload > >>>>> </cli> > >>>>> </config> > >>>>> </edit-config> > >>>>> </rpc> > >>>>> > >>>>> The device would respond with a reply of <ok/>, close > the NETCONF=20 > >>>>> connection, and then reload. (After typing this in, it seems > >>>>> really ho= > >>>>> key.) > >>>>> > >>>>> 3. A device manufacturer can add a capability that adds a new > >>>>> operation= > >>>>> . =20 > >>>>> Something like this: > >>>>> > >>>>> <hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > >>>>> <capabilities> > >>>>> <capability> > >>>>> urn:ietf:params:netconf:base:1.0 > >>>>> </capability> > >>>>> <capability> > >>>>> http:/example.com/schema/1.0/reload > >>>>> </capability> > >>>>> </capabilities> > >>>>> <session-id>4</session-id> > >>>>> </hello> > >>>>> > >>>>> And then you could send the device a NETCONF rpc with this new > >>>>> "reload"= > >>>>> =20 > >>>>> operation when required. The rpc would look like this: > >>>>> > >>>>> <rpc message-id=3D"102" > >>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.= > >>>>> 0"> > >>>>> <reload/> > >>>>> </rpc> > >>>>> > >>>>> The device would respond with a reply of <ok/>, close > the NETCONF=20 > >>>>> connection, and then reload. (If NETCONF doesn't > include a native > >>>>> "rel= > >>>>> oad"=20 > >>>>> operation, then this makes the most sense---to me anyway!) > >>>>> > >>>>> 4. <your idea here...> > >>>>> > >>>>> How should it work=3F > >>>>> > >>>>> Thanks! > >>>>> > >>>>> Henry > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> to unsubscribe send a message to > netconf-request@ops.ietf.org with > >>>>> the word 'unsubscribe' in a single line as the message > text body. > >>>>> archive: <http://ops.ietf.org/lists/netconf/> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> to unsubscribe send a message to > netconf-request@ops.ietf.org with > >>>> the word 'unsubscribe' in a single line as the message text body. > >>>> archive: <http://ops.ietf.org/lists/netconf/> > >>> > >> > > > > > -- > to unsubscribe send a message to netconf-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://ops.ietf.org/lists/netconf/> > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.1/421 - Release Date: 8/16/2006 -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>
- RE: Reload McDonald, Ira
- Re: Reload Andy Bierman