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

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



Balazs Lengyel wrote:

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 ?


- 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

------------------------------------------------------------------------




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 netconf@ops.ietf.org.  To subscribe, use
  netconf-request@ops.ietf.org.


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: balazs.lengyel@ericsson.com





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