[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Reload

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/>