Transcript Partial Locking of a Datastore in NETCONF

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
What is the problem?
• Netconf has only global locking (per
configuration datastore)
• Sometimes operators need to lock only
part of the configuration
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
3
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
4
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
<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
<partial-unlock>
<nc:rpc
nc:message-id="136">
<partial-unlock>
<lock-id>127</lock-id>
</partial-unlock>
</nc:rpc>
•
Namespaces simplified in example
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
Additional considerations
• Locking user MUST have some access
rights, to locked parts
– Mitigates the risk of a lock based DOS
attack
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;
}
}
Open Issues
• Can non-existent parts be locked ?
– Operator Smith want’s to create it later so
leave it alone
• Define “restricted XPATH” precisely
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
Next Steps
• Draft available, accept it in WG
• Tail-F, Ericsson plans to implement/use
partial locking in the near future
• Awaiting reviews, Comments
13
Thank You !
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
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>
Filter
<filter>
<interfaces>
<interface>
<name>eth0</name>
<units>
<unit>
<id>2</id>
</unit>
</units>
</interface>
</interfaces>
</filter>
// OK this exists
// NOK does not exist
Result
• We locked the whole eth0 interface instead of
giving back an error !!!
<data>
<interfaces>
<interface>
<name>eth0</name>
</interface>
</interfaces>
</data>