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 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
