When an instance of Netconf applies a global lock. it prevents the
shared config datastore from being modified by any other NM interface
(CLI, SNMP, COPS-PR, Web server, ...) or by any other instance/session
of Netconf. The implementation can simply block all CLI writes, all
SNMP write, all COPS-PR writes, and all web-server writes that wqould
modify the shared config datastore.
Now we want to talk about partial locking, so that two parts of the
shared config datastore can be worked on simultaneously using more
than one interface or Netconf instance. I interpret the conceptual
model to be a lock is taken out on **part** of the shared config
datastore, but not the complete datastore. The partial lock prevents
the locked part of the shared config datastore from being modified by
any other NM interface (CLI, SNMP, COPS-PR, Web server, ...) or any
other instance of Netconf. The implementation needs to block all
writes to that part of the config datastore by any NM interface other
than the one holding the lock.
My concern is how to specify the part of the shared config datastore
that is locked, in a way that the implementation cam determine what
configuration data is locked, in a way that it can efficiently
determine whether a write by another NM interface would modify the
locked part.
My shared config datastore implementation may in fact include complex
data structures such as hash tables or tree structures implmented in C
that happens to be very different from the type of structure used to
model the information in a Netconf XML-based data model, an SNMP
SMI-based data mode, a web-page-based data model, a COPS-PR PIB data
model, or a CLI data model.
If the part being locked is a statically-defined
implementation-defined subset of the shared config datastore, such as
"the config data in physical blade7", this is probably not an issue
for an implementation to determine what data is in the part. The
partition is statically defined by the implementation, and probably
means much the same set of data regardless of which NM interface is
used to modify it, or which vendor implemented it.
If the part being locked, however, is a dynamically-defined
client-defined logical part of the config datastore specified in an
NM-interface-dependent manner, such as with a Netconf XPath
expression, that might be problematic, because the NM-interface
modeling might not match my actual implementation. In SNMP, we have
oft heard complaints that the two-dimensional tables do not map well
to the actual underlying instrumentation of complex data structures.
Operators also may want to be able to specify "that part of the config
datastore that relates to the service I have configued for my
customer, the ACME company."
If there is a mismatch between the NM-interface data modeling concepts
and actual implementations, then allowing the lock specifications to
be dynamically defined using NM-interface-specific expressions could
be difficult for an implementation to apply. If partial locking is
constrained to some implementation-defined partitions, that might be
easier for the server to apply, although this could impact
interoperability across vendors.
I am not advocating one approach or the other. I think it is important
that proposals for partial locking clearly identify whether the data
partitions that can be locked are expected to be determined by the
implementation or by the client.
David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Romascanu, Dan
(Dan)
Sent: Friday, August 31, 2007 6:51 AM
To: Eliot Lear; Andy Bierman
Cc: David Harrington; Netconf (E-mail)
Subject: RE: partial locking
Eliot,
Just to make sure that I understand the requirement here. Do
you assume
that the data is writeable only by NETCONF? What if another
protocol may
change the same set of data or part of it?
Dan
-----Original Message-----
From: owner-netconf@ops.ietf.org
[mailto:owner-netconf@ops.ietf.org] On Behalf Of Eliot Lear
Sent: Friday, August 31, 2007 12:43 PM
To: Andy Bierman
Cc: David Harrington; 'Netconf (E-mail)'
Subject: Re: partial locking
Should NETCONF impose a write-lock on the data then it
shouldn't be writable to other applications, be that SNMP, or
for that matter the CLI. An error should be returned. In
other words, the lock interface needs to be below the
external protocol interface. This can prove Challenging in
some implementations, but it's still the right thing to do.
I'm a little leery (perhaps evena little LEARy) about
attempting to codify coherency of this form within the IETF,
but I could be convinced. Customers, on the other hand, can
codify anything they want in their RFPs...
--
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/>