Thanks for your discussion and responses. As Joel mentioned, simplified control is regarded as one of the major priciples for i2rs. So, I agree that multiple interaction for a unit of data can be process by the priorities of clients. But, I still have little concerns whether all the cases for writing and reading a unit of data can be covered by the assigned client priorities or not. It seems that it is risky that client's priority determines the ownership of its controlled data. I will review the architecutre again deeply and make some comments as soon as possible. Thanks.
best regards, Kwangkooog Lee (KT) On Wed, Jan 15, 2014 at 1:11 PM, Joel M. Halpern <j...@joelhalpern.com>wrote: > There are no locks. > The changes made by the higher priority client remain in effect until > either they are removed by that client or an even higher priority client > erroneously over-writes them. Changes do not have lifetimes. > > One of the points of this mechanism was to avoid needing to guess what > order things happened in if they are close in time and you want to know the > results. > > Please, read the draft. > > Yours, > Joel > > > On 1/14/14 10:50 PM, Songhaibin (A) wrote: > >> Hi Joel, >> >> It is a little confusing for me. See inline. >> >> -----Original Message----- >>> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Tuesday, January 14, 2014 11:43 PM >>> To: KwangKoog Lee >>> Cc: i2rs@ietf.org; 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 <j...@joelhalpern.com >>>> <mailto:j...@joelhalpern.com>> 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 >>>> i2rs@ietf.org <mailto:i2rs@ietf.org> >>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>> <https://www.ietf.org/mailman/listinfo/i2rs> >>>> >>>> _________________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org <mailto:i2rs@ietf.org> >>>> https://www.ietf.org/mailman/__listinfo/i2rs >>>> <https://www.ietf.org/mailman/listinfo/i2rs> >>>> >>>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >>
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
