Subject: partial locks

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Nov 2006 13:25:35 -0800

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

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 17 Nov 2006 14:18:55 +0100

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.

Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Nov 2006 06:30:46 -0800

Balazs Lengyel wrote:
> - 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.)
> 
> 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.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 17 Nov 2006 16:48:39 +0100

Hello,
I did not say that a non-netconf protocol must lock out Netconf fully. I just stated that 
a partial locking between just Netconf session is also a valid and needed use case.

I agree with you that it would be better if other protocols would also be capable of 
partial locking, but I am a bit unsure how this could be introduced into SNMP or LDAP or a 
Juniper style CLI. Yes you can always add new locking commands to these other interfaces, 
but it might not be easy to impact them. I would be most interested in your ideas how you 
propose to handle this.

I see three possibilities:
1) A nice partial lock solution for SNMP, LDAP etc. but I don't know how to do this.
2) Leave the multi-protocol handling to the device and just standardize how Netconf 
handles partial  locking. (I had previously a draft about something like this.)
3) Accept that partial locking works only for Netconf and the other protocols use a full lock.

In one of our products we actually already have 2) implemented with other protocols. When 
you do a transaction you lock everything on the fly and if one of these locks fail we 
abort the transaction. While this might not be acceptable for all configuration data it 
has served well many customers already using our systems.

Balazs

Andy Bierman wrote:
>> - We have a sub-agent type architecture and we want to lock only some 
>> of the (possibly similar) sub-agents
>>
>> specific partial lock and say that all other protocols only have 
>> management protocol separately how it addresses a group of objects. If 
>> a protocol is very simple it can still lock everything globally or all