RE: Multiple "Running" configurations

["Harrington, David" <dbh@enterasys.com>]

Hi Phil,

Nobody is arguing that your application should need to know the
specifics of the embedded hardware. 

It is possible to support multiple running configs and to report which
configs exist and which of them are "running" configs. Your application
would need to simply loop through all running configs to get the entire
configuration.

This loop could of course be done by the device itself, but there are
some real problems doing the integration of these multiple
configurations. This "entire running config" protocol design constrains
future data modeling approaches for netconf and simply doesn't fit well
with some existing data modeling approaches that assume there might be
multiple distinct (or non-distinct) running environments. 

The "running config" concept is similar to a context in SNMPv3. The
SNMPv3 protocol does not require that all data must be able to be
represented or addressed within a single complete context; in fact, SNMP
uses the context specified in a protocol message to distinguish between
the multiple subsets of data on the device. It is not possible to
address data in two different contexts using one SNMP message. Multiple
messages with different specified contexts are required to capture the
complete SNMP configuration/state, and then they can be integrated
off-the-box.

Now this may be an undesirable aspect of SNMP, and it may be desirable
to specify that netconf must support having such an "entire config"
context.  If so, then we better make sure that when the data modeling is
done, we remember this constraint to the data modeling approach imposed
by the protocol design. 

Also since some portion of a system might be configured in a manner that
expects multiple running configs, i.e. a non-netconf approach, we should
also specify how the distinct partial configs should be integrated into
a single netconf schema in a standardized manner for retrieval using
get-config/get-state for "running", i.e how to proxy these into a
cohesive whole. This is especially necessary if we will support the
"text" format parameter within our schemas to support encapsulating CLI
(or other non-XML) configuration capability for subsets of the system.

O there are some issues to be resolved in order to support a "running"
configuration that includes the entire device configuration.

dbh

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net] 
> Sent: Monday, September 15, 2003 12:38 PM
> To: Allen, Keith
> Cc: netconf@ops.ietf.org
> Subject: Re: Multiple "Running" configurations 
> 
> 
> "Allen, Keith" writes:
> >The protocol as it is currently envisioned identifies
> >operations on this configuration with a special "<running>" 
> XML tag.  The
> >problem brought up by David (correct me if I mischaracterize 
> this, David)
> >was that some devices might have multiple running 
> configurations (running on
> >separate cards, for example), and he would like to see the 
> protocol support
> >operations on devices of this type.
> 
> One of the operator requirements was to be able to fetch the entire
> configuration from a device in a single, simple operation.  This
> seems like a reasonable request, since it allows the operators to
> completely archive the entire device configuration hourly/nightly/etc.
> 
> The running configuration is the full configuration of the device.
> If there are multiple sub-systems, the netconf daemon should proxy
> all the pieces into a cohesive whole.
> 
> If my archive application has to know sufficient in-depth knowledge
> about the layout of your box to be able to pull pieces of 
> configuration
> off embedded hardware, we've failed.
> 
> Thanks,
>  Phil
> 
> --
> 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/>