Re: netconf meeting notes

[Len Nieman <lwnieman@bellsouth.net>]

Comments in line.

"Lock semantics. Wes Hardaker asks the question whether the lock
should prevent read access."

In a word, no.

In addition to provisioning activities, the average LEC or IXC
has a lot of folks performing network monitoring and customer
troubleshooting activities in the network. They need access to
config and state information on a regular basis, regardless of
whether any provisioning activity is going on elsewhere within a
device.

"Interaction between copy-config and locking. Wes wants to have a
recommendation that you should lock both configs if you do a
copy-config. Wes really wanted to have a statement that locks
should be raised together at the beginning of a transaction. Wes
says that this affects also the behavior of get-config while
there is someone modifying a configuration."

I'm coming to this late in the game, so a dumb question: With all
this 'locking' being discussed, is NETCONF only intended for
small networks, say less than 50 devices???

I ask because in a network of 1,000 to 1,500 network elements,
there can be upwards of 15,000 provisioning and deprovisioning
activities per day. On top of that, you're probably talking
somewhere around 50,000+ config and state queries per day from
troubleshooters working customer complaints and network
monitoring centers.

In particular, if locks interfere with config queries from
troubleshooters working customer problems, causing carriers to
lose bill paying customers, NETCONF will not last long. No matter
how well it may work for provisioning activities. 


"The document should probably spell out these issues so that
NETCONF users do not make false assumptions."

Very good idea. It's always a good idea to inform people of the
limitations and potential "gotcha's" of a tool.

"Phil Shafer also suggests that there might be cases where one
want to get access to configuration data, even if there is an
existing lock."

From personal experience over many years, the odds are that as
soon as a lock is in place someone, somewhere, will have a critical
need to look at a piece of config information.

"Wes says this is an instance of the general problem that the
IETF does a poor job in documenting how something is being used."

Should they be documenting how something is being used? Or should
they be documenting how something is supposed to work, and how
it should be used?


Len Nieman

P.S. I'm not with Bellsouth, they're just my ISP.




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