Subject: Proposed attribute for <edit-config>

From: Ganesh CS <[email-masked]>
Date: Wed, 03 Nov 2004 20:44:13 +0530

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 03 Nov 2004 07:35:30 -0800

>Proposed attribute for <edit-config>

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:
>
>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.
>
>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:
>
>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.
>
>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,
>"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.
>
>devices in a fail-safe manner if devices do not have out-of-band management interface
>
>