RE: Multiple "Running" configurations

["Andrea Westerinen" <andreaw@cisco.com>]

This may also occur if the "device" is virtualized or partitioned - and
actually running on several physical components, or the physical
components are shared. These scenarios could cause problems if you
assume that there is only one "real" config.

Andrea  

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


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


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