Proposed attribute for <edit-config>

[Ganesh CS <gsankara@cisco.com>]

Hi,

Proposed attribute for <edit-config>
------------------------------------
Provide an optional "commit-at" attribute for <edit-config> tag.
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/>