1. Partial Locking of a Datastore in NETCONF
Martin Bjorklund, Tail-F
Balazs Lengyel, Ericsson
draft-lengyel-ngo-partial-lock-01
IETF-70 Vancouver 2007 December

2. What is the problem?
Netconf has only global locking (per configuration datastore)
Sometimes operators need to lock only part of the configuration

3. Why is this needed ? Use Cases
Big nodes, multiple people responsible for configuration
BT: separate groups responsible for security, fault, performance, configuration management
Nodes operated by multiple organizations, multiple sections of the same company
Separate virtual routers operated by separate organizations
Nodes configured using parallel sessions

4. Why is this needed ? Use Cases
Nodes with subscriber data
core configuration: responsibility of network operator, experts
subscriber data: responsibility of customer care agent with very limited knowledge about the node
Sub-agent architecture: sometimes we want to lock only one sub-agent, not all

5. Partial Locking Lock part of a datastore Always lock full subtrees
Based on XPATH filter
Restricted XPATH using "Instance Identifier" syntax:
/interfaces/interface[name="eth0"]
Full XPATH if the XPATH capability is also supported
Subtree filtering not suitable for locking
Capability based

6. <partial-lock>
<nc:rpc
nc:message-id="135">
<partial-lock>
<nc:running/>
<filter
select="/if:interface[if:ifIndex='2']"/>
</partial-lock>
</nc:rpc>
Namespaces simplified in example

7. <partial-unlock>
<nc:rpc
nc:message-id="136">
<partial-unlock>
<lock-id>127</lock-id>
</partial-unlock>
</nc:rpc>
Namespaces simplified in example

8. Follow base NETCONF Avoid major new concepts or incompatibilities
Lock is multi-protocol, write lock
Lock owner is the session
Lock life-time connected to session
Partial-lock does in no way change the basic lock functionality

9. Additional considerations
Locking user MUST have some access rights, to locked parts
Mitigates the risk of a lock based DOS attack

10. Yang Model about Locks list locks { config false; key lockId;
leaf lockId { type uint32; }
leaf sessionId {
description "The Id of the session owning the lock.";
type uint32; }
leaf datastore {
type enumeration {
enum running;
enum candidate;
enum startup;
leaf isGlobalLock { type boolean; }
leaf-list originalLockScopeAsXpath {
description "The XPATH expression used to request the lock, omitted for global locks.“;
type string;

11. Open Issues Can non-existent parts be locked ?
Operator Smith want’s to create it later so leave it alone
Define “restricted XPATH” precisely

12. Open Issues
Interactions with locks from other access methods (CLI, SNMP, GUI, LDAP)
If we lock less (only part of the datastore) we will have fever lock conflicts
Mapping of naming systems needed anyway for configuration
If another access method can not support fine grained locking it can still lock big chunks or a complete datastore

13. Next Steps Draft available, accept it in WG
Tail-F, Ericsson plans to implement/use partial locking in the near future
Awaiting reviews, Comments

14. Thank You !

15. Subtree Filtering Problem
Leads to ambiguous, counter-intuitive results -> BAD !!!
Trying to lock a non-existing sub-element “B” of an existing element “A” would result in locking the existing element “A” instead of an error
If someone can show how to get this to work properly, it may be added to the draft

16. Existing Configuration Data
<interfaces>
<interface>
<name>eth0</name>
<mtu>1500</mtu>
<units>
<unit>
<id>1</id>
<vlan-id>3</vlan-id>
</unit>
</units>
</interface>
</interfaces>

17. Filter <filter> <interfaces> <interface>
<name>eth0</name> // OK this exists
<units>
<unit>
<id>2</id> // NOK does not exist
</unit>
</units>
</interface>
</interfaces>
</filter>

18. Result
We locked the whole eth0 interface instead of giving back an error !!!
<data>
<interfaces>
<interface>
<name>eth0</name>
</interface>
</interfaces>
</data>