Subject: [i2rs] Clients-Agents relationship WAS: consensus on I2RS protocol and model

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 06:27:58 -0400

Forgot to change the topic.
I would like to follow up and build on this - but i wanted to make sure
there was some sanity first.

cheers,
jamal

---------- Forwarded message ----------
From: Jamal Hadi Salim <[email-masked]>
Date: Thu, Apr 24, 2014 at 6:24 AM
Subject: Re: [i2rs] consensus on I2RS protocol and model
To: Dean Bogdanovic <[email-masked]>
Cc: Andy Bierman <[email-masked]>, "<[email-masked]>"
<[email-masked]>, Martin Bjorklund <[email-masked]>, "<[email-masked]>"
<[email-masked]>, "<[email-masked]>" <[email-masked]>

On Wed, Apr 23, 2014 at 4:19 PM, Dean Bogdanovic <[email-masked]> wrote:
>
> On Apr 23, 2014, at 3:54 PM, Andy Bierman <[email-masked]> 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.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Apr 2014 06:29:13 -0700

> there was some sanity first.
Which drafts shows 1 I2RS client performing a network-wide edit
across N locked I2RS agents?

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.

cheers,
> jamal

Andy

> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 09:40:11 -0400

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

> 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 24 Apr 2014 09:51:44 -0400

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 10:08:09 -0400

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-masked]> 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
> agents does not in itself palce new protocol or model requirements on the
> system.  If we wanted inter-agent atomicity, then there would be

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 24 Apr 2014 20:03:06 +0000

On Apr 24, 2014, at 10:08 AM, Jamal Hadi Salim <[email-masked]> wrote:

> 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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Apr 2014 21:56:20 -0400

I was mostly referring to overload conditions (of both compute and
wire resources).
It is feasible for a client not to be able to keep up (eg a table dump
response; i.e a single
request resulting in a large fast bulk response). However,
the more interesting case is for a daemon overload as a result of some
client transaction;
assuming possibly N daemons talk to an agent on the south bound
multiplexing to M clients
on the northbound, where M>>N - and how to deal with the client(s)
that are responsible for the
overload without adversely affecting the other clients that dont
contribute to overload.
Some of this could be implementation issues.

I think l misunderstood what you and Andy were saying to imply you
meant M equals N equals 1.

cheers,
jamal

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 28 Apr 2014 20:23:57 +0000

Jamal,

There is only one agent to one daemon. There is no scenario of one agent to multiple daemons.

There are multiple clients to one agent.

So agent is depending on the speed of daemon and agent should protect overloading daemon with requests, so it can police requests from clients.

Dean

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 29 Apr 2014 09:47:59 -0400

Dean,

In your slides, IIRC,  at the meeting you illustrated several daemons
all interacting with the
agent doing different things. In our case it will very likely be
multiple daemons doing
different things for the agent (and sometimes remote machines). In any
case, this may end up being
an implementation issue.
I have another issue I will post probably under a separate topic:
Prioritization.

cheers,
jamal

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2014 19:31:50 -0400

Jamal,

> case, this may end up being

I suspect it may be.  I tend to view the Agent as anything from the entire
intelligent i2rs portion of the system to something as simple as a
light-touch dispatcher for underlying instances implementing portions of
i2rs.

As an example, a RIB query may be dispatched one way, a BGP query may be
dispatched another.  The fact that this is happening within the
implementation should remain an opaque detail, I think.

If we decide to ever get clever about our transport system, as an example
using SCTP channels, there's little reason that even the transport endpoint
might eventually get tied to the underlying component rather than being
fronted by a dispatcher.  But lets solve the easier case first. :-)

> I have another issue I will post probably under a separate topic:

A topic near and dear to me. :-)

-- Jeff