Subject: draft-lengyel-netconf-granular-locking-00.txt

From: Balazs Lengyel <[email-masked]>
Date: Mon, 19 Dec 2005 13:12:14 +0100

I wrote a short document about granular locking for Netconf.

We in Ericsson feel that there is a strong need for granular locking.

Some of our configuration databases are so big that we can not use candidate 
configurations and for the same reason we must allow simultaneous paralel configuration 
sessions to manipulate different parts of the configuration.

I believe that we dont need to know the contents of the data model before we can devise a 
granular locking mechanism, just as the mechanism of the subtree-filter is not dependent 
on the data model it is filtering.

Any comments ?

regards Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager & AXD Operational Suite (AOS) OPM
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

Network Working Group                                        B. Lengyel
Internet-Draft                                          	   Ericsson
Expires: May 14, 2006                                 December 11, 2005

           Granular Locking for the NETCONF Configuration Protocol
               draft-lengyel-netconf-granular-locking-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The NETCONF protocol describes the lock and unlock operations 
   that (un)lock an entire configuration datastore. Often it is 
   needed to allow multiple management sessions to modify the 
   configuration of a managed element. In these cases it would be 
   needed to be able to lock only a part of a configuration 
   datastore. This draft proposes a capability based extension to 
   the NETCONF protocol to allow this.

   Please send comments to [email-masked].  To subscribe, use
   [email-masked].

Lengyel                     Expires May 14, 2006               [Page 1]

Internet-Draft         Netconf Granular Locking           December 2005

1.  Introduction

   The NETCONF protocol describes the lock and unlock operations 
   that (un)lock an entire configuration datastore. Often it is 
   needed to allow multiple management sessions to modify the 
   configuration of a managed element. In these cases it would be 
   needed to be able to lock only a part of a configuration 
   datastore. This draft proposes a capability based extension to 
   the NETCONF protocol to allow this.
   
   The managed information model behind NETCONF will not be 
   stable for a considerable time. Even so a mechanism for granular 
   locking can be defined based on the existing subtree filtering 
   and XPATH selection mechanisms in the protocl draft.
   
   Granular locking should be introduced as a capability into netconf.

2.  Granular Locking Capability

2.1.  Overview

   The :granular-locking capability indicates that the device supports
   the lock and unlock operations with a scope smaller then a complete 
   configuration datastore. The target can be specified using a 
   combination of a target datastore and a subtree filter or an 
   XPATH filter expression. A granular lock will succeed only if no 
   parts of the scope to be locked are locked by other management 
   users including users of NETCONF or any other management method. 
   The granular unlock operation has to specify the scope just the 
   same way as the granular lock operation. Granular unlock will only 
   succeed if the whole of the specified scope has been locked by the 
   user attempting to use the unlock operation. 

2.2.  Dependencies

   The :granular-locking capability's XPATH option is only relevant 
   if the :xpath capability is also supported.

2.3.  Capability Identifier

   The :granular-locking capability is identified by the following
   capability string:

      urn:ietf:params:netconf:capability:granular-locking:1.0

2.4.  New Operations

   None.

Lengyel                     Expires May 14, 2006               [Page 3]

Internet-Draft             Netconf Granular Locking       December 2005

2.5.  Modifications to Existing Operations

2.5.1.  <lock>

   The :granular-locking capability modifies the <lock> operation
   to accept a <filter> element beside a <target>.

2.5.2.  <unlock>

   The :granular-locking capability modifies the <unlock> operation
   to accept a <filter> element beside a <target>.

3.  Security Considerations

   No change compared to the <lock> and <unlock> operation in [NETCONF].

4.  IANA Considerations

	None

5.  Authors and Acknowledgements

   This document was written by:

      Balazs Lengyel, Ericsson

6.  References

12.1.  Normative References

   [NETCONF]  Enns, R., "NETCONF Configuration Protocol",
              ID draft-ietf-netconf-prot-09, October 2005.

Appendix A.  Change Log

A.1.  First version

   o  Initial version

Author's Address

   Balazs Lengyel (editor)
   Ericsson
   P.O. BOX 107
   1037 Budapest
   Hungary

   Email: [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 19 Dec 2005 09:27:07 -0500

Hi Balazs,

Thanks for submitting this document as a starting point.

Can you add a section to your draft that discusses the potential
issues that arise from having different operators working on different
pieces of a configuration simultaneously, and any suggestions for how
to address those issues? I assume that since this is required for some
of your company's devices, that there is existing knowledge of issues,
and how to address the problems that result from this, and having some
of the issues and potential solutions identified here would be useful.

Can you also address which other netconf operations might need to be
changed to support partial configuration? The :granular-locking
"target 
can be specified using a combination of a target datastore and a
subtree filter or an XPATH filter expression." So, for example, will
the copy-config, delete-config, and validate commands need to be
changed to accept a filter as well? 

Your draft says "A granular lock will succeed only if no parts of the
scope to be locked are locked by other management users including
users of NETCONF or any other management method." Can you define scope
in the document, so it is clear how one would determine overlap? 

Some issues surrounding separate configuration of pieces of the
"grand" configuration were discussed in 2003. One such thread can be
found in the archive at
http://ops.ietf.org/lists/netconf/netconf.2003/msg00867.html.

Thanks,
David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Monday, December 19, 2005 7:12 AM
> To: [email-masked]
> Subject: draft-lengyel-netconf-granular-locking-00.txt
> 

--
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: Mon, 19 Dec 2005 08:29:44 -0800

Balazs Lengyel wrote:

> Some of our configuration databases are so big that we can not use 
> candidate configurations and for the same reason we must allow 
> simultaneous paralel configuration sessions to manipulate different 
> parts of the configuration.
>
> I believe that we dont need to know the contents of the data model 
> before we can devise a granular locking mechanism, just as the 
> mechanism of the subtree-filter is not dependent on the data model it 
> is filtering.
>
> Any comments ?

 - Have you implemented this in product?
 - There isn't enough detail here for independent implementations
    to interoperate.
 - Multiple filter expressions resolve to the same set of nodes in the
   target configuration.  The operator has no way of knowing which
   exact set of nodes is being locked.  How do different operators easily
   debug a "lock denied" error?
 - This doesn't really work with our global candidate model does it?
   According to the standard, any lock is effectively a global lock here.
 - There are access control issues (not just global candidate issues).
   Can a user explicitly lock a portion of database without any access
   to that data?  How do they know which portion of their filter
   expression caused the 'access-denied' error?
 - The filter mechanisms allow node selection by value.
    I can lock all the interfaces with an ifInOctets count < 4000.
    The agent has to honor this request.  IMO, there are WAY MORE
    useless lock scenarios than useful ones that result from Xpath 
filtering.
 - I can lock an entry by value, even the value of regular columns
   (not in the key).   What happens if the value changes, such that
   the Xpath or subtree filter expression changes value, while I
   hold the lock?   Items in the granular lock can drift in and out
  of locked state.  How fun is that to implement correctly?
 - How do other access modes (SNMP, CLI) interact properly
   with filter-based locks?  If CLI or SNMP only have a global lock
   then NETCONF won't get to use its partial lock very often anyway.

I don't think this problem is as easy to solve as you do.

> regards Balazs

Andy

>------------------------------------------------------------------------
>
>
>
>