Partial Locking of a Datastore in NETCONF

1. Partial Locking of a Datastorein 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>