Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state
This was discussed with the working group, and the agreement was that I2RS changes did not have lifetimes, were not dependent upon a maintained connection, and were removed either on device reboot or removal by the controller that put them there (or when overriden my erroneous overlap.) If you ahve new perspectives that were not discussed before, you can of course ask the chairs to reopen the discussion. Yours, Joel On 8/14/15 4:57 PM, Linda Dunbar wrote: Thanks Joel and Andy for the clarification. See my additional comments inserted below: *From:*Andy Bierman [mailto:a...@yumaworks.com] *Sent:* Saturday, July 18, 2015 9:55 PM *To:* Linda Dunbar *Cc:* i2rs@ietf.org; Susan Hares; jh...@juniper.net *Subject:* Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state Hi, very interesting comments... I agree these are requirements that could apply to more than I2RS. The first-one-wins (via client priority) details could apply to configuration as well as ephemeral state, and I wonder if NETCONF should be changed to support it. I don't agree that a lost connection caused all the state for that client to disappear. In NETCONF, it is generally only the edits in progress that are tossed. Since I2RS will not use a candidate config, these multi-PDU edits should not be possible in I2RS. [Linda] The lost connection could mean that configuration from the I2RS agent is stale. At least there should be a timer for the data from the I2RS agent whose connection has been lost. When the Timer expired during the connection loss, the configuration should be wiped out. Linda I agree that the access procedures for ephemeral state can be separated from multi-head procedures, but they are somewhat coupled. I think the arch. doc mentioned parameters sent with an edit to ask for a notification if the edit is rejected because higher priority data already exists (notify me when my edit might work). It seems multi-head control is mandatory to support. Andy On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar linda.dun...@huawei.com mailto:linda.dun...@huawei.com wrote: Sue and Jeff, There have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wasting your time. I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about the “multi-headed control of a I2RS agent”. IMHO, the “I2RS-ephemeral-state” should be addressed separately from “multi-headed control”, because for networks that only use single controller, they don’t have to deal with the complicated scheme of multiple controllers, but they do need to conform to the “ephemeral-state” via I2RS interface. “I2RS-ephemeral-state” should be simply: - all commands from I2RS interface are ephemeral, i.e. they do not sustain restart, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost. The Multi-headed control scheme described in the draft can also be applied to persistent configuration. draft-ietf-i2rs-ephemeral-state-00 introduced a new “ephemeral-config” to NETCONF, does it mean that if I2RS client uses regular “config” instead of “ephemeral-config”, the configuration becomes persistent? It shouldn’t, in my opinion. Linda Dunbar ___ 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 ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state
Thanks Joel and Andy for the clarification. See my additional comments inserted below: From: Andy Bierman [mailto:a...@yumaworks.com] Sent: Saturday, July 18, 2015 9:55 PM To: Linda Dunbar Cc: i2rs@ietf.org; Susan Hares; jh...@juniper.net Subject: Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state Hi, very interesting comments... I agree these are requirements that could apply to more than I2RS. The first-one-wins (via client priority) details could apply to configuration as well as ephemeral state, and I wonder if NETCONF should be changed to support it. I don't agree that a lost connection caused all the state for that client to disappear. In NETCONF, it is generally only the edits in progress that are tossed. Since I2RS will not use a candidate config, these multi-PDU edits should not be possible in I2RS. [Linda] The lost connection could mean that configuration from the I2RS agent is stale. At least there should be a timer for the data from the I2RS agent whose connection has been lost. When the Timer expired during the connection loss, the configuration should be wiped out. Linda I agree that the access procedures for ephemeral state can be separated from multi-head procedures, but they are somewhat coupled. I think the arch. doc mentioned parameters sent with an edit to ask for a notification if the edit is rejected because higher priority data already exists (notify me when my edit might work). It seems multi-head control is mandatory to support. Andy On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar linda.dun...@huawei.commailto:linda.dun...@huawei.com wrote: Sue and Jeff, There have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wasting your time. I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about the “multi-headed control of a I2RS agent”. IMHO, the “I2RS-ephemeral-state” should be addressed separately from “multi-headed control”, because for networks that only use single controller, they don’t have to deal with the complicated scheme of multiple controllers, but they do need to conform to the “ephemeral-state” via I2RS interface. “I2RS-ephemeral-state” should be simply: - all commands from I2RS interface are ephemeral, i.e. they do not sustain restart, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost. The Multi-headed control scheme described in the draft can also be applied to persistent configuration. draft-ietf-i2rs-ephemeral-state-00 introduced a new “ephemeral-config” to NETCONF, does it mean that if I2RS client uses regular “config” instead of “ephemeral-config”, the configuration becomes persistent? It shouldn’t, in my opinion. Linda Dunbar ___ i2rs mailing list i2rs@ietf.orgmailto:i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state
Thanks Andy. I had missed that line in Linda's email. I agree with Andy. As I understand the WG agreements, ephemeral state has nothing to do with the presence or absence of a connection to the I2RS client which provided the state. The ephemeral aspect is strictly about whether the state survives reboot of the device with the I2RS Agent (there is some ambiguity / flexibility about the case where the I2RS Agent reboots without the device itself rebooting, which we should be clear about.) While the document title may be narrower than its scope (often the case with IETF documents) it is important that we get protocol mechanisms which deal with the priority as well as the ephemeral aspects. I see no benefit in having two separate documents to discuss them. Yours, Joel On 7/18/15 10:55 PM, Andy Bierman wrote: Hi, very interesting comments... I agree these are requirements that could apply to more than I2RS. The first-one-wins (via client priority) details could apply to configuration as well as ephemeral state, and I wonder if NETCONF should be changed to support it. I don't agree that a lost connection caused all the state for that client to disappear. In NETCONF, it is generally only the edits in progress that are tossed. Since I2RS will not use a candidate config, these multi-PDU edits should not be possible in I2RS. I agree that the access procedures for ephemeral state can be separated from multi-head procedures, but they are somewhat coupled. I think the arch. doc mentioned parameters sent with an edit to ask for a notification if the edit is rejected because higher priority data already exists (notify me when my edit might work). It seems multi-head control is mandatory to support. Andy On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar linda.dun...@huawei.com mailto:linda.dun...@huawei.com wrote: __ __ Sue and Jeff, __ __ There have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wasting your time. __ __ I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about the “multi-headed control of a I2RS agent”. __ __ IMHO, the “I2RS-ephemeral-state” should be addressed separately from “multi-headed control”, because for networks that only use single controller, they don’t have to deal with the complicated scheme of multiple controllers, but they do need to conform to the “ephemeral-state” via I2RS interface. __ __ “I2RS-ephemeral-state” should be simply: - all commands from I2RS interface are ephemeral, i.e. they do not sustain restart, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost. __ __ __ __ The Multi-headed control scheme described in the draft can also be applied to persistent configuration. __ __ __ __ draft-ietf-i2rs-ephemeral-state-00 introduced a new “ephemeral-config” to NETCONF, does it mean that if I2RS client uses regular “config” instead of “ephemeral-config”, the configuration becomes persistent? It shouldn’t, in my opinion. __ __ __ __ Linda Dunbar __ __ ___ 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 ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Multi-Headed Control
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] Sent: Friday, January 17, 2014 7:47 AM To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' Cc: 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 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
Re: [i2rs] Multi-Headed Control
One thing to keep in mind. The WG has agreed to drop all time-based operations. Changes are applied when the order is given, and they remain until they are replaced / overw-written (or the box resets). Changes do not have expieration times. Yours, Joel On 1/17/14 3:55 AM, Songhaibin (A) 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] Sent: Friday, January 17, 2014 7:47 AM To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee' Cc: 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 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
Re: [i2rs] Multi-Headed Control
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.comwrote: 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 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
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 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
Re: [i2rs] Multi-Headed Control
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: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. 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
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. 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. 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: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. 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
Re: [i2rs] Multi-Headed Control
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
Re: [i2rs] Multi-Headed Control
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:j...@joelhalpern.com] Sent: Wednesday, January 15, 2014 11:17 AM To: Mach Chen; KwangKoog Lee Cc: i2rs@ietf.org; 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:j...@joelhalpern.com] Sent: Wednesday, January 15, 2014 10:29 AM To: Mach Chen; KwangKoog Lee Cc: i2rs@ietf.org; 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: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. 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
Re: [i2rs] Multi-Headed Control
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.comwrote: 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
Re: [i2rs] multi-headed control
On Wed, Jan 23, 2013 at 6:37 PM, Joe Marcus Clarke jcla...@cisco.comwrote: On 1/23/13 5:04 PM, Alia Atlas wrote: I'd be interested in hearing others perspective on the use-cases requiring multi-headed control and what you see this requirement as meaning. This is a rather different requirement, in terms of embedding the policy-enforcement into the routing system, from what is currently done for CLI/NetConf/SNMP. In those cases, the latest writing wins and installs its state. For i2rs, an idea proposed (in http://tools.ietf.org/html/draft-atlas-irs-policy-framework) is that different i2rs clients are decided between based upon precedence. Frequently, different services are known to not collide, based upon human-assigned policy - such as different prefixes for different traffic types, etc. To get things started with a use-case, consider that there are two different services that are using i2rs. a) Special Traffic Flow Routing: a service that installs policy-based routing filters to route specific traffic on predetermined paths. b) DDoS Detection: a service that detects traffic of interest and installs policy-based routing filters to route the suspicious traffic to an analysis box. In this case, the second service could have a higher precedence to override the first service's installed filters when necessary. Any opinions? More like a thought. In the use case you describe, couldn't both coexist? Meaning you could simply have two PBR actions, one that routes the traffic and the other that copies the interesting traffic to the DDoS sniffer. So the precedence may be the same and both can coexist. Now, if the DDoS service finds a problem in the copied traffic, it can install an overlapping policy that would preempt the original. Exactly - both could exist unless the DDoS service finds a problem with a flow being routed by the first service. As to the flow in the draft, if the new, higher-precedence service is transient and the store-if-not-best bit is set, then the previous state will be restored (if it has the next best precedence). Shouldn't the commissioner be notified again that its state is active again? Absolutely - I'll double-check to be sure that's in there when we revise the draft. Regards, Alia Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP| | Distinguished Services Engineer ..:|::|:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jcla...@cisco.com ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] multi-headed control
On Wed, Jan 23, 2013 at 7:16 PM, Joe Marcus Clarke jcla...@cisco.comwrote: On 1/23/13 7:08 PM, Alia Atlas wrote: On Wed, Jan 23, 2013 at 6:37 PM, Joe Marcus Clarke jcla...@cisco.com mailto:jcla...@cisco.com wrote: On 1/23/13 5:04 PM, Alia Atlas wrote: I'd be interested in hearing others perspective on the use-cases requiring multi-headed control and what you see this requirement as meaning. This is a rather different requirement, in terms of embedding the policy-enforcement into the routing system, from what is currently done for CLI/NetConf/SNMP. In those cases, the latest writing wins and installs its state. For i2rs, an idea proposed (in http://tools.ietf.org/html/draft-atlas-irs-policy-framework) is that different i2rs clients are decided between based upon precedence. Frequently, different services are known to not collide, based upon human-assigned policy - such as different prefixes for different traffic types, etc. To get things started with a use-case, consider that there are two different services that are using i2rs. a) Special Traffic Flow Routing: a service that installs policy-based routing filters to route specific traffic on predetermined paths. b) DDoS Detection: a service that detects traffic of interest and installs policy-based routing filters to route the suspicious traffic to an analysis box. In this case, the second service could have a higher precedence to override the first service's installed filters when necessary. Any opinions? More like a thought. In the use case you describe, couldn't both coexist? Meaning you could simply have two PBR actions, one that routes the traffic and the other that copies the interesting traffic to the DDoS sniffer. So the precedence may be the same and both can coexist. Now, if the DDoS service finds a problem in the copied traffic, it can install an overlapping policy that would preempt the original. Exactly - both could exist unless the DDoS service finds a problem with a flow being routed by the first service. That coexist wasn't clear (at least to me) in the draft or your description here. But maybe this wouldn't be considered overlap in the precedence sense? Yes, I wasn't considering it overlap - just like two routes in the RIB aren't overlapping if they're not the same prefix. As to the flow in the draft, if the new, higher-precedence service is transient and the store-if-not-best bit is set, then the previous state will be restored (if it has the next best precedence). Shouldn't the commissioner be notified again that its state is active again? Absolutely - I'll double-check to be sure that's in there when we revise the draft. Thanks. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP| | Distinguished Services Engineer ..:|::|:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jcla...@cisco.com ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] multi-headed control
On 1/23/13 7:19 PM, Alia Atlas wrote: Yes, I wasn't considering it overlap - just like two routes in the RIB aren't overlapping if they're not the same prefix. Got you. So maybe the use case should make it clear that the DDoS Service has already deemed a problem is seen (via some pre-programmed copy op) and it is now overriding the pre-existing state with a higher precedence state vs. simply inspecting traffic. In general, I think there is value to this, especially in the notification piece. This may help management systems suspend polling while a certain state is known not to exist. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP| | Distinguished Services Engineer ..:|::|:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jcla...@cisco.com ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] multi-headed control
On Wed, Jan 23, 2013 at 7:26 PM, Joe Marcus Clarke jcla...@cisco.comwrote: On 1/23/13 7:19 PM, Alia Atlas wrote: Yes, I wasn't considering it overlap - just like two routes in the RIB aren't overlapping if they're not the same prefix. Got you. So maybe the use case should make it clear that the DDoS Service has already deemed a problem is seen (via some pre-programmed copy op) and it is now overriding the pre-existing state with a higher precedence state vs. simply inspecting traffic. Yes, the peril of not writing down assumptions. In general, I think there is value to this, especially in the notification piece. This may help management systems suspend polling while a certain state is known not to exist. Good to hear. Providing good notifications seems critical to making good control loops and having i2rs scale. Alia Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP| | Distinguished Services Engineer ..:|::|:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jcla...@cisco.com ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
