On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim <[email protected]> wrote:
> I was more looking at the agent - it brokers between clients and the > RIB subsystem > as shown in figure 1 of the architecture doc. Different clients bring > different latencies/capacities. > Congestions will kick in, how does client latency influence agent? The agent sees request coming in from different authorized clients at a rate and it is processing those requests. The agent will depend on the daemon performance, but not on client. > reliability requirements will need to be > considered. And there may > be need to signal these details to the clients (SIP proxying is the > closest i can think of). > You cant solve this problem by just inserting a reliable transport > where the i2rs protocol > runs. > > cheers, > jamal > > On Thu, Apr 24, 2014 at 9:51 AM, Joel M. Halpern <[email protected]> wrote: >> No, there is no requirement that the client is a broker. He may be, or he >> may not. And the scope of his brokering, if he is a broker, may be >> application specific or more general. >> >> We have placed requirements to be able to provide traceability when the >> client is brokering. This is as much because even a non-broker may be >> acting on behalf of several different applications. >> >> As far as I can tell, the fact that a client may itneract with multiple >> agents does not in itself palce new protocol or model requirements on the >> system. If we wanted inter-agent atomicity, then there would be >> requirements. But we explicitly decided that was out of scope. >> >> Yours, >> Joel >> >> >> On 4/24/14, 9:40 AM, Jamal Hadi Salim wrote: >>> >>> On Thu, Apr 24, 2014 at 9:29 AM, Andy Bierman <[email protected]> wrote: >>>> >>>> >>>> >>>> Which drafts shows 1 I2RS client performing a network-wide edit >>>> across N locked I2RS agents? >>>> >>> >>> There is a requirement to allow only one client to own write access to >>> a specified object in order to avoid locking. There is nothing objecting >>> to a client being able to write to multiple objects as long as that rule >>> is met. >>> >>>> The agents do not coordinate with each other. >>>> The clients do not coordinate with each other. >>>> >>>> This is currently out of scope for the I2RS protocol. >>>> >>> >>> Both assertions true. >>> But what i was responding to is: >>> There are multiple clients that connect to the same agent. >>> And a client can connect to multiple agents. >>> >>> I believe that such a requirement _may_ call out certain features in >>> the protocol. Essentially the agent is a broker. >>> >>> cheers, >>> jamal >>> >>>>> cheers, >>>>> jamal >>>> >>>> >>>> >>>> Andy >>>> >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Jamal Hadi Salim <[email protected]> >>>>> Date: Thu, Apr 24, 2014 at 6:24 AM >>>>> Subject: Re: [i2rs] consensus on I2RS protocol and model >>>>> To: Dean Bogdanovic <[email protected]> >>>>> Cc: Andy Bierman <[email protected]>, "<[email protected]>" >>>>> <[email protected]>, Martin Bjorklund <[email protected]>, "<[email protected]>" >>>>> <[email protected]>, "<[email protected]>" <[email protected]> >>>>> >>>>> >>>>> On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <[email protected]> >>>>> wrote: >>>>>> >>>>>> >>>>>> On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email protected]> wrote: >>>>>> >>>>> >>>>>> I thought I2RS is starting out focusing on 1 client and 1 agent. >>>>> >>>>> >>>>> Dont think so. >>>>> >>>>>> Network locking across devices is out of scope. >>>>>> >>>>>> >>>>>> >>>>>> I have same opinion as you on this one, just wanted to spell it out one >>>>>> more >>>>>> time explicitly, as I heard some discussions where network locking was >>>>>> coming up. >>>>>> >>>>> >>>>> Either I am misunderstanding both of you or both of you misunderstood >>>>> the >>>>> requirement. >>>>> The idea is to allow a single writer per object as a starting point. >>>>> OTOH, if you really mean what you say then I violently disagree. >>>>> >>>>> cheers, >>>>> jamal >>>>> >>>>> PS:- Changing the topic so this is not lost in the noise because i think >>>>> that >>>>> the many clients-single agent brings needs for other protocol >>>>> requirements. >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
