While I will try to paraphrase things to answer your question, I
recommend you read the archtiecture draft to get more details.
The assumption is that normally different I2RS clients will be asking
the agent to perform operations which change different pieces of data.
We discussed various models of conflict resolution for the case when one
client adjusts a piece of data, and then another client goes to change
that data. We decided that this was an error, and that we wanted a
simple mechanism to decide what to do, while the clients sort out what
was intended. Rather than pure FCFS, we decided to have client
priorities. And that clients could arrange (easily) to be notified of
changes to data they are interested in.
The goal is to keep the mechanisms very lightweight, particularly in
order to support very high rates of operations.
Yours,
Joel
On 1/14/14 10:29 AM, KwangKoog Lee wrote:
I do not fully understand the data model of i2rs. But in case that many
clients interact forwarding devices with the i2rs-enabled control plane,
various policies about routing, signaling, qos and etc. from multiple
clients or multiple upper users (network applications) can be set to
those devices and to prevent or negotiate some collision of multiple
policies, such a machanism might be necessary regardless of netconf?
Joel or anyone can explain more why it does not need? Thanks in advance.
best regards,
Kwang-koog Lee
On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern <[email protected]
<mailto:[email protected]>> wrote:
As I read the documents, locking is specifically not the approach
I2RS is taking. So I think that "<lock>" does not suffice to
resolve the I2RS needs, and is in fact not part of the current I2RS
arhtiecture at all.
Yours,
Joel
On 1/14/14 4:17 AM, Guanxiaoran wrote:
Hi,
I've a question about i2rs multi-headed control and NETCONF.
[draft-ietf-i2rs-problem-__statement-00] describes:"Additional
extensions to handle multi-headed control may need to be added
to NetConf and/or appropriate data models."
[draft-ietf-i2rs-architecture-__00] describes:"The current
recommendation is to have a simple priority associated with each
I2RS clients, and the highest priority change remains in effect."
As NETCONF has <lock> mechanism: "The <lock> operation allows
the client to lock the entire configuration data-store system of
a device. Such locks are intended to be short-lived and allow a
client to make a change without fear of interaction with other
NETCONF clients, non-NETCONF clients (e.g., SNMP and CLI), and
human users."
Do we still need to do the extensions, i.e. additional
extensions to handle multi-headed control added to NETCONF?
Regards,
Ran
_________________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/i2rs
<https://www.ietf.org/mailman/listinfo/i2rs>
_________________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/i2rs
<https://www.ietf.org/mailman/listinfo/i2rs>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
