Re: Proposed attribute for <edit-config>

[Andy Bierman <abierman@cisco.com>]

At 07:14 AM 11/3/2004, Ganesh CS wrote:
>Hi,
>
>Proposed attribute for <edit-config>
>------------------------------------
>Provide an optional "commit-at" attribute for <edit-config> tag.

This doesn't really make sense for <edit-config>.
The WG discussed this feature at length for the <commit>
operation, but dismissed it because there were too many
problems.  For example, how does this pending config
show up in <get-config> operations?  Does the <candidate>
config stay locked and unusable until the commit-at time?
What if another user/session issues conflicting commit-at
commands?  How does an operator debug misconfigured devices
related to this feature?  Does a <validate> operation check 
for this type of problem?  What about error reporting and recovery? 
What if the config changes are valid at the time they are transferred
to the box, but are not valid at the commit-at time?  

The WG decided not to put this option in NETCONF 1.0.
It may come up again in the future, but the feature set
for 1.0 is frozen.  We are in WG Last Call now.  Only
corrections and clarifications will be made to the
WG drafts from now on.

Andy


>Value for commit-at attribute can specify wait time(in sec/msec) after which <edit-config> operation is performed on the network entity
>
>Problem background
>------------------
>Currently some of the following critical configuration changes across network devices will have to be performed through an out-of-band management channel. If not there is a reliability issue related to losing the active network connections due to reconvergence of one/more of the network protocols.
>
>For example:
>
>a) changing ipv4 address of all devices in the network
>
>b) Link level configurations like dot1q trunk attributes, LACP attributes
>
>c) Changing some spanning tree parameters across the network like VLANs mapped to a Spanning tree instance across a MST(802.1s) region
>
>For any of the above configuration tasks, if we need to apply configurations on to multiple devices A,B...X then a particular sequence can be followed in pushing the configurations. Like say push config on to device B before A and so on.
>
>But, this type of sequencing may not be sufficient. For example, if A is a
>router and B is another router in the network and we are planning to
>change ip addresses then applying changes to B might affect reachability
>to networks connected on the other side of B and applying changes to A
>can result in ip disconnectivity to networks on the other side of A till
>the other device is configured.
>
>Another complexity is that the sequencing needs to be determined by the network management station before making the configuration changes. This sequencing mostly depends on the network topology.
>
>In some cases seqencing is impossible. For example, if we need to do some PAgP configuration changes on to Switch1 and Switch2 in the following topology:
>
>NMS-----Router1---Switch1----Switch2-----Router2
>subnet 1 contains - Router1 and NMS
>subnet 2 contains - Router1 , Switch2 and Router2
>subnet 3 contains - Switch1 and Router2
>
>In the above configuration, from the NMS perspective, device nearer at layer 2  is not equal to the device nearer at layer 3. So there is no fail-safe sequence in which this configuration can be performed.
>
>Sequencing also has a threat in terms of network availability and it can potentially put the network in to some unrecoverable state. Like if LACP is not properly configured on both ends then in some cases interfaces can get in to disable state.
>
>Possible Solution
>-----------------
>If we can schedule the config operation on all the devices at time T1 where current time is less than T1. The value of "commit-at" attribute for a device to be configured can be T1 - current time. In this case NMS will push the config to all devices before T1 but devices will commit the config only at T1.
>
>How can <get-config> reflect this
>-----------------------------------
>If a get-config request is initiated in the intermediate time before T1 and after pushing the <edit-config> with "commit-at" attribute, the configuration returned can contain a <deferred-config> tag with "id", "commit-at" and "committer-id" attributes.
>Here,
>"id" can be set to unique local identifier created by the local system.
>"commit-at" can be set to wait time after which the configuration will be committed to the network element.
>"committer-id" can be set to the NMS that initiated the <edit-config> with "commit-at" attribute.
>
>Under this <deferred-config> tag the actual configuration that was sent by the NMS can be accomodated.
>
>Advantages
>----------
>1. Scheduled config operation ensures minimal network downtime because of synchronization (if the configuration is critical enough to affect reachability)
>2. NMS does not need to do any kind of sequencing. In other words no prior knowledge about the network topology is required for pushing the configuration.
>
>3. In some of the network topologies this is the only way to configure
>devices in a fail-safe manner if devices do not have out-of-band management interface
>
>
>Please let me know your views
>
>best regs
>Ganesh
>
>--
>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/>