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