[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NGO] Re: partial locks

Balazs Lengyel wrote:

Hello Andy,
Our most common use case is somewhat different from what you describe.
- We have virtual routers in a physical box and we want to lock only one of these - Someone is manipulating subscriber data and we want to lock only some subscribers - We have a sub-agent type architecture and we want to lock only some of the (possibly similar) sub-agents
As you see we need quite fine grained locking. (Also the mandatory global locking is a huge problem for us.) 

I don't agree with you that XML based solutions are unacceptable.
1) While the Netconf lock is a multi-protocol lock, still we will usually (or often) use it to protect multiple Netconf sessions from messing up each others data. This means that if we implement a Netconf specific partial lock and say that all other protocols only have global locking, thats already a really useful solution. 2) XPATH really locks objects not XML bits. It is a problem of each management protocol separately how it addresses a group of objects. If a protocol is very simple it can still lock everything globally or all subscribers or all virtual routers. 



I suggest you develop a proprietary solution and prove that it works.
If a non-XML access protocol locks the entire configuration, this locks
out all NETCONF sessions until the lock is cleared.  IMO a standard solution
for partial configuration locking should not be this fragile.


Balazs


Andy






Andy Bierman wrote:

Hi,

[This will move to the NGO mailing list when it gets created.]

This issue came up again, and I was wondering
if there is any progress in this area in implementations.

IMO, XML-focused solutions like Xpath do not allow
for other protocol access methods to easily participate in partial locking. 
This is sub-optimal, because NETCONF will have zero access if
any other protocol has any access at all.

IMO, a better approach would be a simple classification
scheme, something like Perl uses: <Application>::<Module>.
This is very coarse granularity, but it is possible for all
protocol APIs to make this sort of simple classification.

It means that all NETCONF data models would need to identify
this meta-data somehow in the schema.  This isn't that hard
so far:


  netconf::base
  netconf::notifications


Agents supporting the :partial-lock capability MUST support
partial locking across all access methods of an
individual application, and SHOULD provide locking of an
individual module within an application. Each owner (ietf, vendor, etc.)
can define applications, which are identified in XML by a namespace.

An application could be 'routing', and module could be 'bgp',
or an application could be 'remops', and a module could be 'ping'.
It's all up to the data model designer as usual.
XML hierarchy for <edit-config>, <get> and <get-config> falls out for free: 
(Note that <data> is the conceptual <top>.
There is no need to actually include that in the data model.)

[Namespace prefixes not shown:]

  <data>
    <netconf>
      <notifications>
        <streams>
          <stream>
            ...
          </stream>
         </stream>
      </notifications>
    </netconf>
  </data>


Comments?


Andy




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