Hi Joel, It is a little confusing for me. See inline.
> -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Tuesday, January 14, 2014 11:43 PM > To: KwangKoog Lee > Cc: [email protected]; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control > > 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. Except for client priorities, there are other factors like timing. I assume that a client with higher priority changes a piece of data, but then a client with lower priority can make changes to the same piece of data. It could possibly depend on the how long the client with higher priority wants that change to take effect. But when two clients want to make changes to the same data at the same time, then the client with higher priority will get the <lock>, and the request from the client with lower priority will be denied. And we can leave the choice on whether to make another try to the client itself. Regards! -Haibin >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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
