Hi Sue, Thank you very much for so detailed explanation. I understand your two principles very clearly now.
What comes into my mind is the following use case. Let's say it a bandwidth on demand scenario. Two clients A and B have different priorities to change user X's access bandwidth, and one client could be embedded in the user itself while another client is the system admin. Client A has higher priority. Then user X's access bandwidth is the piece of data. At time Y, Client A requests to change X's bandwidth to 20Mbps for two hours. And after two hours, X's bandwidth is reset to its default value. And after the time Y+2, either A or B should have the permission to change X's bandwidth data. I guess you probably have already considered this. Best Regards! -Haibin > -----Original Message----- > From: Susan Hares [mailto:[email protected]] > Sent: Friday, January 17, 2014 7:47 AM > To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' > Cc: [email protected]; Guanxiaoran > Subject: RE: [i2rs] Multi-Headed Control > > Mach, Haibin, and KwanKooq: > > Joel gave you brief answers and then suggested reading the document. As > one of the co-authors, I will attempt to give the "longer" answers. I hope > this > will encourage discussion sections in the architecture document. > > This is not suggest current flaws in the architecture draft, but to elucidate > (explain in depth) some of the drafts concepts. You may be asking questions > that we hope will be discussed on the list, but I cannot tell yet. > There are many sections in the architecture draft end with the phrase > "Editor's > note: This topic (or These topics) need more discussion in the working group." > We encourage discussion of these drafts. > > If I am not answering the question, please just tell me. The important part > of > this work is to get an architecture and drafts that can be implemented in > routers and switches. > > Ok.. enough introduction. On to a longer review that ends in a question: > > Review: > --------- > > In section 1.2, page 6 (bottom) of the -00 version of the architecture draft, > I > states: > > " As can be seen in Figure 1, an I2RS client can communicate with > multiple I2RS agents. An I2RS client may connect to one or more I2RS > agents based upon its needs. Similarly, an I2RS agent may > communicate with multiple I2RS clients - whether to respond to their > requests, to send notifications, etc. Timely notifications are > critical so that several simultaneously operating applications have > up-to-date information on the state of the network." > > Note here that the architecture states you may have one agent talking to > multiple I2RS clients. Once you enter this zone, you can have collisions. > In the beginning , we talk and talked about ways that you could handle > collisions - but we want to start simple. > > The phrase "protocol parsimony is clearly a goal" (section 3.1, p. 9) suggest > we > are trying to implement just a few things in the first version of I2RS > Clients and > I2RS Agents. From there, the I2RS protocol will be extended later. > > The simple rule for multi-headed control (section 6.8) is to consider that two > clients manipulating the same piece of data is an error. For example, > configuring an static route of prefix 192.1.1.0/24 should only be done by one > client. If two I2RS clients try to change the same piece of data in the same > I2RS Agent, it is an error. > > The architecture then requires that the I2RS clients and Agents have a > decidable way for the Agent to resolve the error. Section 6.8 states our > simple way: > 1) assign each client a priority (either by policy or default policy) > 2) If the priorities tie, the first client "whose attribution is associated > with the > data" keeps the control. > > That means - if you tie is First-come-keeps-control (FCKC) > > This is important to consider when you look at data models, scope (Section 2, > p. > 7-8), and identity. You will note that the RIB manager is the easiest thing > to > start with. Only one person can change one prefix, but multiple I2RS clients > can add different prefixes to the list. > > Now, what if I2RS client A wants to add 10 prefixes to the RIB and this > includes > 192.1.1.0/24 to a single I2RS agent and I2RS client B wants to add > 1 prefix 192.1.1.0/24. Does it cause a problem with I2RS client A if I24S > Client B gets there first (FCKC), and only 9 prefixes get added. > > That very issue is what section 6.9 deals with. > > Questions: > ----------- > 1. Are you trying to determine what happens when the multi-headed control > hits one of these errors? [See Sections 6.5, 6.6, 6.8 and 6.9] > > 2. Are you trying to build redundant clients (I2RS client A and I2RS Client > A') which are redundant clients? [See section 6.4.1] > > 3. Are you concerned about multi-headed control with multiple interfaces per > client? > (You could have 4 SCTP and 4 TCP session over which this protocol runs) > [Section 6.2] > > 4. How does a I2RS client A that reads the data know when I2RS Client B > modifies the Data? > [Section 6.8] > > Sue Hares > > > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Joel M. Halpern > Sent: Tuesday, January 14, 2014 11:11 PM > To: Songhaibin (A); KwangKoog Lee > Cc: [email protected]; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control > > 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:[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 > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
