Subject: Re: Reload

From: [email-masked]
Date: Wed, 16 Aug 2006 16:43:20 +0000

FROM=5FRFC=5FABUSE,
=09DNS=5FFROM=5FRFC=5FPOST,MSGID=5FFROM=5FMTA=5FHEADER,SPF=5FPASS autol=
earn=3Dno=20
=09version=3D3.1.1
Received: from [65.54.246.76] (helo=3Dbay0-omc1-s4.bay0.hotmail.com)
=09by psg.com with esmtp (Exim 4.60 (FreeBSD))
=09(envelope-from <[email-masked]>)
=09id 1GDCtw-000HEi-SE
=09for [email-masked]; Wed, 16 Aug 2006 04:21:08 +0000
Received: from hotmail.com ([64.4.51.41]) by bay0-omc1-s4.bay0.hotmail.=
com with Microsoft SMTPSVC(6.0.3790.1830);
=09 Tue, 15 Aug 2006 21:21:08 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSV=
C;
=09 Tue, 15 Aug 2006 21:21:08 -0700
Sender: [email-masked]

=09Wed, 16 Aug 2006 04:21:05 GMT
X-Originating-IP: [216.93.211.196]
X-Originating-Email: [[email-masked]]
X-Sender: [email-masked]
From: "Henry Pootel" <[email-masked]>
To: [email-masked]
Bcc:=20
Subject: configuration use case question
Date: Tue, 15 Aug 2006 21:21:05 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=3Dflowed
X-OriginalArrivalTime: 16 Aug 2006 04:21:08.0278 (UTC) FILETIME=3D[65B3=
FD60:01C6C0EB]

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Aug 2006 11:24:08 -0700

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

 >...

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Aug 2006 16:34:07 +0200

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

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2006 07:56:46 -0700

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

---

From: Phil Shafer <[email-masked]>
Date: Thu, 17 Aug 2006 11:27:25 -0400

>mechanisms (new RPCs) just the data model for a new proprietary command.

This puts your mgmt app in the spot of guessing which version of
your data model a particular device supports.  Using capabilities
allows the mgmt app to know this, based on the capability.  You
could also define two distinct capabilities, one for the generic
data model and one for that is version specific.

Thanks,
 Phil

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Aug 2006 19:07:32 +0200

I thought I could include the data model version in a capability indicating support for 
the data model itself. That is important even if I don't use <exec>.
Balazs

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 17 Aug 2006 19:11:25 +0200

My point is only: I would see clear advantages for an <exec> operation in the 
netconf-protocol draft/rfc.
Balazs

>    independently implemented in an interoperable manner
BALAZS: Sorry, I meant the netconf-protocol draft or some similar IETF draft/RFC.
>    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.
>>>> <rpc message-id=3D"101" 
>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=
>>>> 0">
>>>>    <edit-config>
>>>>       <target>
>>>>          <running/>
>>>>       </target>
>>>>       <config>
>>>> <rpc message-id=3D"102" 
>>>> xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=
>>>> 0">
>>>>    <reload/>
>>>> </rpc>
>>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Aug 2006 10:22:53 -0700

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 17 Aug 2006 19:48:01 +0200

> Unless there was more to it than this, the <exec> node

I am not sure I agree. Such an "exec" feature allows a data model to
formally describe what the in/out argument for an exec are.  For
example, a data model could define that there is an operation called
"ping", that it takes an IP address as input and returns some
statistics. This moves the definition of operations out of the
protocol into the data model (and thus requires that there is a data
model framework to support this).

The other approach is to introduce all new verbs as protocol
extensions which does not require any data modeling agreement. (This
is for those people who believe the IETF is good at protocols but less
so on data models.)

I am not arguing in either direction. I am just questioning the
statement that there is "no point in this 'feature'" and "has no real
value".

/js

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

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 18 Aug 2006 09:59:01 +0200

For us the main point is to allow the definition of new <exec>s with minimum modification 
to the management SW.

Yes the full value of <exec> relies on data modeling. You really gain a lot only if you 
have something like this in place (an excerpt from our DTD that defines our modeling 
language like SMI)

<!ELEMENT action (description, returnType, parameter*, raisesException*)>
<!ATTLIST action name CDATA #REQUIRED>

<!ELEMENT exception description,name, exceptionParameter*)>

You have to define the number of parameters and for each parameter you have to define the 
exact type. This allows our management system to handle new actions (<exec>s) based on the 
data model without modification.

I know that netconf does not have (yet) a data model in place, but I could think about a 
two stage introduction of this feature.
1) define a standard <exec> with opaque parameters to allow users who already have a 
proprietary data model (actually everyone) to easily implement the function
2) define the necessary data model to gain the full value

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Aug 2006 06:11:32 -0700

Balazs Lengyel wrote:
> For us the main point is to allow the definition of new <exec>s with 
> minimum modification to the management SW.
> 
> Yes the full value of <exec> relies on data modeling. You really gain a 
> lot only if you have something like this in place (an excerpt from our 
> DTD that defines our modeling language like SMI)
> 
> You have to define the number of parameters and for each parameter you 
> have to define the exact type. This allows our management system to 
> handle new actions (<exec>s) based on the data model without modification.
> 
> I know that netconf does not have (yet) a data model in place, but I 
> could think about a two stage introduction of this feature.
> 1) define a standard <exec> with opaque parameters to allow users who 
> already have a proprietary data model (actually everyone) to easily 
> implement the function

What are the implementation requirements?
It seems like the one commonality is that the node
used to "wrapper" the proprietary command is called 'exec'.

IMO, this is not worth standardizing.
In any event, this is not a chartered work item,
and a written proposal would have to fly a lot
further than "wrapper named exec" to get chartered.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 18 Aug 2006 06:48:51 -0700

> handle new actions (<exec>s) based on the data model without modification.

IMO, this belongs in the schema, not the agent.
There is already a mechanism to advertise data model capabilities.

There is a plan in the WG to specify what a "module capability"
looks like.  The only place the schema should show up (wrt/
mandatory support) is in the capabilities exchange, in the <hello>
PDU.

<capability>some-uri-to-identify-the-data-model-namespace</capability>

There is an assumption (by many people) that the DM language
is XSD, and therefore a module is a <schema> element, which
refers to a single target namespace.

I don't like this assumption, but as long as a <capability>
identifies a data model namespace, and not a module, then
it doesn't matter.

But the WG's plan to use capabilities for this purpose is still
somewhat broken because we're not really supposed to parse
URIs to get the capability name and version fields.

<capability type="data-model" name="foo" version="1.0">
     http://example.com/schemas/foo/1.0
</capability>

I don't think the NETCONF schema allows this extension, so
we need to leave the ad-hoc parsing out-of-scope.

I am not in favor of standardizing additional data model
discovery mechanisms, especially before all the current
chartered work is completed.

Andy