RE: Multiple "Running" configurations

["Faye Ly" <faye@pedestalnetworks.com>]

Keith,

The concept of 'grand' or 'individual' running configuration is largely
dependent upon the network device itself.  In a router, I suspect one
grand running configuration is it.  Whereas if we go into the non router
world, there might be one device proxies for multiple devices
(stackable, for example) and multiple running configuration is needed.
A <running filename> tag seems to be needed?

-faye

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Allen, Keith
Sent: Monday, September 15, 2003 9:09 AM
To: netconf@ops.ietf.org
Subject: Multiple "Running" configurations

All,

Naturally, we couldn't solve all of the issues that came up during the
interim working group meeting last week, or even to discuss them all in
depth.  I thought, though, that an issue that David Harrington brought
up
was particularly sticky, especially given some of the decisions that
were
made during the meeting.

The protocol is being developed to enable operations on configurations
stored on an Internet device.  One configuration, the "running"
configuration, has a special meaning - it's the configuration currently
active on the device.  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.

The general tone of the responses to David's issue seemed to be that
even
though a device might have several different configurations active at
one
time, they are all part of the "grand configuration" (my term) of the
device.  If these devices support the NETCONF protocol, they will be
responsible for presenting their multiple running configurations as
snippets
of the grand configuration of the device.

This is certainly possible, and I think reasonable.  The problem is,
currently only the get-config and edit-config operations operate on
subsets
of a device's grand configuration.  Other important operations, such as
copy
and lock and validate, do not.  So, it seems that either the devices of
concern to David will have to live with this restriction, or the
protocol
will have to be modified by enabling these other operations to also
operate
on snippets of configurations.  I fear the former may not sit well with
David and perhaps others, but the latter has some rather negative
implications, too.  Does anybody see another way around this?

I think if we're going to consider modifying those operations, we should
address it soon.

Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com


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