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