Re: [i2rs] Multi-Headed Control

["Susan Hares" <[e-mail]>]

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:[e-mail]] 
Sent: Friday, January 17, 2014 10:06 AM
To: Songhaibin (A); Susan Hares; 'KwangKoog Lee'
Cc: [e-mail]; 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

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:[e-mail]]
>> Sent: Friday, January 17, 2014 7:47 AM
>> To: 'Joel M. Halpern'; Songhaibin (A); 'KwangKoog Lee'
>> Cc: [e-mail]; 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:[e-mail]] On Behalf Of Joel M. 
>> Halpern
>> Sent: Tuesday, January 14, 2014 11:11 PM
>> To: Songhaibin (A); KwangKoog Lee
>> Cc: [e-mail]; 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:[e-mail]] On Behalf Of Joel M.
>>>> Halpern
>>>> Sent: Tuesday, January 14, 2014 11:43 PM
>>>> To: KwangKoog Lee
>>>> Cc: [e-mail]; 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 
>>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>           [e-mail] <mailto:[e-mail]>
>>>>>           https://www.ietf.org/mailman/__listinfo/i2rs
>>>>>           <https://www.ietf.org/mailman/listinfo/i2rs>
>>>>>
>>>>>       _________________________________________________
>>>>>       i2rs mailing list
>>>>>       [e-mail] <mailto:[e-mail]>
>>>>>       https://www.ietf.org/mailman/__listinfo/i2rs
>>>>>       <https://www.ietf.org/mailman/listinfo/i2rs>
>>>>>
>>>> _______________________________________________
>>>> i2rs mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>> _______________________________________________
>>> i2rs mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>
>> _______________________________________________
>> i2rs mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i2rs
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>