This may not so widely supported:-) So, there are actually two arbitrations, one is at I2RS Agent, the other is at Rib manager.
Based on the definition of I2RS, seems that the arbitration at Rib manager is out of the scope of I2RS, but it really brings the requirement to the Rib manager. This may need some guide/clarify text in the architecture. Best regards, Mach > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Wednesday, January 15, 2014 11:17 AM > To: Mach Chen; KwangKoog Lee > Cc: [email protected]; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control > > Rib manager is the easy case. It generally already has logic to arbitrate > across > multiple writers. So the I2RS Agent talks to the RIB manager just as CLI and > the > routing processes do. > > For other cases, the I2RS Agent interacts with the system in a similar (but > probably not identical) fashion to that of the CLI. With the same arbitration > between that and internal processes. > > In fact, except for RIB Manager, there are relatively few difficult cases over > interaction. I2RS and CLI can administratively disable or enable things. > Internal > processes can operationally disable them (reporting that they don't work.) > This > distinction is already widely supported. > > Yours, > Joel > > On 1/14/14 10:05 PM, Mach Chen wrote: > > Thanks Joel, > > > > Please see my response inline... > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:[email protected]] > >> Sent: Wednesday, January 15, 2014 10:29 AM > >> To: Mach Chen; KwangKoog Lee > >> Cc: [email protected]; Guanxiaoran > >> Subject: Re: [i2rs] Multi-Headed Control > >> > >> The unit of data for collisions is to be specified as part of the > >> relevant information models. Trying to define that architecturally seemed > counter-productive. > > > > Yes, agree. > > > >> > >> In terms of collisions with things in the box, there are two cases. > >> 1) Collision between I2RS and CLI. The CLI is assign a priority. > >> That way the operator can choose how they want that resolved. > >> 2) Collision between other processes and I2RS is handled by the > >> system in the same way it handles collisions between those processes and > CLI. > > > > There is slight different between the "other processes" and the I2RS > > clients, > the I2RS clients requests are processed by the I2RS Agent, but the "other > processes" directly communicate with the Rib manager and other components > that really maintain the "data". So, does it mean that the RIB manager and > some > other components have to add new functionalities for arbitrating requests from > I2RS and other processes? > > > > Best regards, > > Mach > >> > >> Again, the guiding principle is "keep it simple." > >> > >> Yours, > >> Joel > >> > >> On 1/14/14 9:09 PM, Mach Chen wrote: > >>> Hi Joel, > >>> > >>>> 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. > >>> > >>> Are there any specifications about the unit of the "data" ? I did > >>> not find this in > >> the architecture and IM documents. > >>> > >>>> decide what to do, while the clients sort out what was intended. > >>>> Rather than pure FCFS, we decided to have client priorities. > >>> > >>> So, each client will have its own priority and the priorities are > >>> comparable > >> among the clients. But there are other entities(e.g., the control > >> plane, a.k.a, ISIS, OSPF, BGP etc.) that may changes the data as > >> well, how to handle the conflicts between the clients and non-clients? > >>> > >>> Best regards, > >>> Mach > >>> > >>>> -----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. 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
