Subject: [i2rs] Multi-Headed Control

From: Guanxiaoran <[email-masked]>
Date: Tue, 14 Jan 2014 09:17:27 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jan 2014 09:19:51 -0500

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:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: KwangKoog Lee <[email-masked]>
Date: Wed, 15 Jan 2014 00:29:14 +0900

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-masked]>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
>
>> [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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jan 2014 10:43:11 -0500

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:
> 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-masked]
> <mailto:[email-masked]>> 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
>         [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-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>     _________________________________________________
>     i2rs mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/i2rs
>     <https://www.ietf.org/mailman/listinfo/i2rs>
>

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Jan 2014 02:09:33 +0000

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:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 14, 2014 11:43 PM
> To: KwangKoog Lee
> Cc: [email-masked]; 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
> 
> > 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?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jan 2014 21:28:40 -0500

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

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Jan 2014 03:05:10 +0000

Thanks Joel,

Please see my response inline...

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2014 10:29 AM
> To: Mach Chen; KwangKoog Lee
> 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.

> 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  
> >> 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.
> >
> >> 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
> >
> >> 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
> >>> 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?
> >>> On Tue, Jan 14, 2014 at 11:19 PM, Joel M. Halpern
> >>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jan 2014 22:17:29 -0500

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

---

From: "Songhaibin (A)" <[email-masked]>
Date: Wed, 15 Jan 2014 03:50:07 +0000

Hi Joel,

It is a little confusing for me. See inline.

> The assumption is that normally different I2RS clients will be asking the agent
> to perform operations which change different pieces of data.

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

---

From: Mach Chen <[email-masked]>
Date: Wed, 15 Jan 2014 03:58:28 +0000

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
> Sent: Wednesday, January 15, 2014 11:17 AM
> 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
> 
> >> relevant information models.  Trying to define that architecturally seemed
> counter-productive.
> >
> > Yes, agree.
> >
> >>
> >> 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
> >>
> >>>> 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.
> >>>
> >> 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
> >>>
> >>>> 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
> >>>> The goal is to keep the mechanisms very lightweight, particularly
> >>>> in order to support very high rates of operations.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>>     Joel or anyone can explain more why it does not need? Thanks
> >>>>> in
> >> advance.
> >>>>>
> >>>>> best regards,
> >>>>> Kwang-koog Lee

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 14 Jan 2014 23:11:11 -0500

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

---

From: KwangKoog Lee <[email-masked]>
Date: Wed, 15 Jan 2014 15:30:33 +0900

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 <[email-masked]>wrote:

> order things happened in if they are close in time and you want to know the
> results.
>
> Please, read the draft.
>
> Yours,
> Joel
>
>
>>> recommend you
>>> the agent
>>> client
>> 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
>>>> multiple policies, such a machanism might be necessary regardless of
>>>>
>>> netconf?
>>>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Jan 2014 18:47:20 -0500

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-masked]] On Behalf Of Joel M. Halpern
Sent: Tuesday, January 14, 2014 11:11 PM
To: Songhaibin (A); KwangKoog Lee
Cc: [email-masked]; 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:
>> wanted a simple mechanism to decide what to do, while the clients sort
out what was intended.
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.
>>> negotiate some collision of multiple policies, such a machanism 
>>> might be necessary regardless of
>> netconf?

---

From: "Songhaibin (A)" <[email-masked]>
Date: Fri, 17 Jan 2014 08:55:38 +0000

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

> From: Susan Hares [mailto:[email-masked]]
> Sent: Friday, January 17, 2014 7:47 AM
> To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee'
> Subject: RE: [i2rs] Multi-Headed Control
> 
> 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
> 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.
> 
> In section 1.2, page 6 (bottom) of the -00 version of the architecture draft, I
> states:
> 
> 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.
> 
> 2) If the priorities tie, the first client "whose attribution is associated with the
> data" keeps the control.
> 
> 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
> 3.  Are you concerned about multi-headed control with multiple interfaces per
> client?
> 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.
> 
> things happened in if they are close in time and you want to know the results.
> 
> Please, read the draft.
> 
> Yours,
> Joel
> 
> >> sort
> 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.
> >
> 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
> >>>          the client to lock the entire configuration data-store
> >>> system
> of

---

From: KwangKoog Lee <[email-masked]>
Date: Fri, 17 Jan 2014 18:15:51 +0900

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) <[email-masked]>wrote:

> 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.
>
> elucidate
> "Editor's
> draft, I
> suggest we
> includes
> either they
> order
> request

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Jan 2014 10:06:05 -0500

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Jan 2014 10:10:01 -0500

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:
> 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?
>
> 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.
>
> 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
> On Fri, Jan 17, 2014 at 5:55 PM, Songhaibin (A) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Sue,
>
>     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.
>
>      > From: Susan Hares [mailto:[email-masked] <mailto:[email-masked]>]
>      > Cc: [email-masked] <mailto:[email-masked]>; Guanxiaoran
>      > configuring an static route of prefix 192.1.1.0/24
>     <http://192.1.1.0/24> should only be done by one
>      > 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
>      > From: i2rs [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>      > Cc: [email-masked] <mailto:[email-masked]>; Guanxiaoran
>      > >> From: i2rs [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M.
>      > >> Halpern
>      > >> Cc: [email-masked] <mailto:[email-masked]>; Guanxiaoran
>     asking
>      > >>>    Joel or anyone can explain more why it does not need?
>     Thanks in
>      > advance.
>      > >>>
>      > >>> best regards,
>      > >>> Kwang-koog Lee
>      > >>> <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      > >>>
>      > >>>          recommendation is to have a simple priority
>     associated with
>      > each
>      > >>>          NETCONF clients, non-NETCONF clients (e.g., SNMP and
>     CLI),
>      > and
>      > >>>          human users."
>      > >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>      > >>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Jan 2014 18:45:28 -0500

Haibin:

If Client A has the higher priority, does the reset to original value - mean
that the I2rs client release the "write" permissions for user X's access
bandwidth [no write permissions]?  Or is it that Client "A" disconnects from
the i2rs Agent? 

Answer to Joel's input: 
To expand on Joel's brief comment about WG agreement,  Joel refers to the
IETF '87 presentation with the WG (see below), email between August and
November on list, and IETF '88 presentation.  Alia (co-chair/author) and
other co-authors are looking to put all these comments into the next draft.
The draft probably be out before Chinese New Year - so I suspect you'll want
to read sections 5 and 6 of the new draft carefully. 

=================
WG notes from IETF 87 
<snip> 
http://tools.ietf.org/wg/i2rs/minutes

Starts" 
draft-atlas-i2rs-architecture-01
(J. Halpern, 15')
Joel H: I'm Joel Halpern. This is work a bunch of us did as a design team to
propose an architecture for I2RS.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, January 17, 2014 10:06 AM
To: Songhaibin (A); Susan Hares; 'KwangKoog Lee'
Cc: [email-masked]; Guanxiaoran
Subject: 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 / over-written (or the box resets).
Changes do not have expieration times.

Yours,
Joel

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.
>> 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.
>> 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.
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 2) If the priorities tie, the first client "whose attribution is 
>> associated with the data" keeps the control.
>>
>> 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.
>>
>> 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]
>>
>> 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
>>
>>
>>
>> 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.
data.
>>>> clients sort
>> 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.
>>>
>> 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.
>>>>>           recommendation is to have a simple priority associated 
>>>>> with
>> each

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Jan 2014 19:09:15 -0500

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:[email-masked]] 
Sent: Friday, January 17, 2014 10:10 AM
To: KwangKoog Lee; Songhaibin (A)
Cc: Susan Hares; [email-masked]; Guanxiaoran
Subject: Re: [i2rs] Multi-Headed Control

Yours,
Joel

On 1/17/14 4:15 AM, KwangKoog Lee wrote:
>     important part of
>     handle
>     easiest thing to
>     control
>     interfaces per
>     what order
>      > >> pure FCFS, we decided to have client priorities.  And that
clients
>      > >> could arrange
>      > >>>          extensions to handle multi-headed control may need to
be
>      > added
>      > >>>          I2RS clients, and the highest priority change remains
in
>      > effect."

---

From: KwangKoog Lee <[email-masked]>
Date: Wed, 29 Jan 2014 22:13:18 +0900

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 <[email-masked]> wrote:

> >      > From: Susan Hares [mailto:[email-masked] <mailto:[email-masked]
> >]
> >      > >>>          As NETCONF has <lock> mechanism: "The <lock>
> operation
> >      > allows

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 30 Jan 2014 13:14:48 +0100

I don't think multi-head control is controlling any thing, to control
the system it needs one head/management method.

AB

On 1/14/14, Guanxiaoran <[email-masked]> wrote:
> [draft-ietf-i2rs-problem-statement-00] describes:"Additional extensions to
> handle multi-headed control may need to be added to NetConf and/or
> [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."
>