Sorry for my late response. I've understood the detailed mechanisms about the multi-headed control of I2RS through review of architecture document and authors' detailed comments. Thank you, again. Many curiocities are solved but I have more questions about the congestion control.
As stated in Sec. 6.1 of the architecture document, I think a congestion control mechanism of the I2RS transport is also related to the multi-headed control. As Joel explained, the priority information each client has can simply solve a congestion situation in an agent. Sec. 6.1 covers a congestion in a client as well as an agent. The probability of the congestion in a client is generally higher than the agent case. Like the client case, each agent can have any priority? Or, I2RS messages from agents can additionally have priority? I think as the architecture distinguishes "notifications (in Sec. 6.6)" and "information collection (in Sec. 6.7)" the notification message's priority is generally higher than the priority of information collection message because the former has important and urgent information like interface failure that may affect the next control of the underlying networks. If does, more detailed matters are needed to mention in the architecture document. I think it can help alleviate concerning of scalability and reliabilty for service providers considering SDN(I2RS)-enabled routing networks. best regards, Kwang-koog Lee (KT) On Sat, Jan 18, 2014 at 9:09 AM, Susan Hares <sha...@ndzh.com> wrote: > KwangKoog: > > Joel did not answer: "In addition, for basic client redundancy, the > architecture states active and backup network application can be used. At > this point, I want to know both network applications are physically > separated from the client?" > > The definitions in section 1.2 and 3.3 indicate that this is up to the > implementation. > > Have we answered all your questions? > > Sue > > -----Original Message----- > From: Joel M. Halpern [mailto:j...@joelhalpern.com] > Sent: Friday, January 17, 2014 10:10 AM > To: KwangKoog Lee; Songhaibin (A) > Cc: Susan Hares; i2rs@ietf.org; Guanxiaoran > Subject: Re: [i2rs] Multi-Headed Control > > As was discussed at the last meeting, The authors of the rfernando > requirements draft will be making some changes to align with the working > group agreed architecture. There are currently some minor (and I > believe unintentional) discrepancies. > > And in the context of collision detection, "first" simply means the > first client to change a piece of data. We hope folks do not rely on > that mechanism, as it is unpredictable in outcome when changes are > applied close together in time. That is why we have the priority scheme. > > Yours, > Joel > > PS: Client archtiecture, application architecture, and client management > are out of scope for this document. There are many ways they can be > built, and we are not mandating an approach. > > > On 1/17/14 4:15 AM, KwangKoog Lee wrote: > > Dear Susan Hares, > > > > I deeply appreciate for your kind explanation about the multi-headed > > control of I2RS so that I reviewed the architecture document again and > > understood about the error-handling mechanism and the simplicity of I2RS > > nature. Sorry for my poor understanding of I2RS. > > > > Regarding to your comments, I still have some questions to be more clear. > > > > First, as you explained and the architecture states, the manipulation of > > the collision of multi-headed control can be processed by the assignment > > of client priorities. > > Rather, when the priority ties, the first client can keep the control. > > At this point, the first client means the firstly connected client for > > the controlling data or firstly connected client to the agent with that > > data? > > > > Second, the statements of two documents, architecture > > (draft-ietf-i2rs-architecture-00) and protocol > > requirement(draft-rfernando-i2rs-protocol-requirements-00), seem to have > > somewhat different views about the communication channel between client > > and agent. In the architecture document, Sec 6.2 states the > > communication channel between client and agent does not need to keep > > continuous transport. But Sec 4.2 TR-12 of the protocol requirement > > document states that keep-alives at transport level or I2RS protocol > > level could be provided for detecting the session failure. And > > simulataneous usage of session and communication channel of the > > architecture document is confusing for me. > > > > Finally, I have a question about the network application and client for > > client redundancy. I think client is not equal to network application. > > The architecture document states in Sec 6.5 for handling dead clients > > "the network applications or management systems will detect a dead > > network application and either restart that network application or clean > > up any state left behind." In addition, for basic client redundancy, the > > architecture states active and backup network application can be used. > > At this point, I want to know both network applications are physically > > separated from the client? > > > > Thank you for your comments, again :-) > > > > best regards, > > Kwang-koog Lee (KT) > > > > > > > > On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) <haibin.s...@huawei.com > > <mailto:haibin.s...@huawei.com>> wrote: > > > > 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:sha...@ndzh.com <mailto:sha...@ndzh.com > >] > > > Sent: Friday, January 17, 2014 7:47 AM > > > To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' > > > Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; 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 > > <http://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 <http://192.1.1.0/24> to a single I2RS agent and > > I2RS client B wants to add > > > 1 prefix 192.1.1.0/24 <http://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:i2rs-boun...@ietf.org > > <mailto:i2rs-boun...@ietf.org>] On Behalf Of Joel M. Halpern > > > Sent: Tuesday, January 14, 2014 11:11 PM > > > To: Songhaibin (A); KwangKoog Lee > > > Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; 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:i2rs-boun...@ietf.org > > <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 <mailto: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> > > <mailto: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> <mailto: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> <mailto: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 > > > > _______________________________________________ > > > > i2rs mailing list > > > > i2rs@ietf.org <mailto:i2rs@ietf.org> > > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > _______________________________________________ > > > i2rs mailing list > > > i2rs@ietf.org <mailto:i2rs@ietf.org> > > > https://www.ietf.org/mailman/listinfo/i2rs > > > > > >
_______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
