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

Re: Reload

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.

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).

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