Subject: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 13:40:29 +0200

Hi Joel,
	In today's session, I asked about provisions in the architecture
(document) for Client Redundancy/Fault Tolerance. I believe you stated
that "it's not needed" and that you'd elaborate on the list.

I believe you also answered a latter question by stating that clients
are free to coordinate between themselves to provide redundancy. Is this
the simple answer?  If not, can you elaborate?

Thanks,
Lou

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Aug 2013 07:51:38 -0400

Not to answer for Joel, but my view is that a client is identified by its
identity.  A different application can take over from the first by using
the same identity.  Loss of a transport session does not cause existing
client state to be removed (in the architecture) - so there is the ability
for a new application to take over.

Does that help?

Alia

On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <[email-masked]> wrote:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 01 Aug 2013 08:09:24 -0400

The key point is that client coordination (for standby or any other 
purpose) is the clients problem.  Sharing the identity is one way to do 
this.

I suppose for permission to delete state we might want to have some 
notion of shared authorization with distinct authentication, but I would 
prefer not to go there.

Yours,
Joel

On 8/1/13 7:51 AM, Alia Atlas wrote:
> Not to answer for Joel, but my view is that a client is identified by
> its identity.  A different application can take over from the first by
> using the same identity.  Loss of a transport session does not cause
> existing client state to be removed (in the architecture) - so there is
> the ability for a new application to take over.
>
> Does that help?
>
> Alia
>
>
> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Joel,
>     [email-masked] <mailto:[email-masked]>

---

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 08:09:20 -0400

Alia,

See below.

> the ability for a new application to take over.

A bit.  The discussion of treating multiple writers for the same state
as errors got me worried about this case - from a redundancy
perspective, and to a lesser degree, accountability standpoint.

Given the importance of reliable operation even in the case of client
failures, I think the topic should be covered in the architecture
document. Of course this topic/comment can be addressed after the
document is adopted.

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 08:21:03 -0400

> notion of shared authorization with distinct authentication, but I would

Well now you're getting to my AAA comment from the last meeting, i.e.,
is it okay to lose today's ability for user level traceability on device
state changes *on the device*. The current document of course says it
is. I'm sure there are some out there who will see this as a pain point,
but it also may be acceptable to tell such users to not use I2RS.

Lou

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Aug 2013 08:25:03 -0400

Lou,

You think the secondary identity that we put in is insufficient?

Alia

---

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 09:44:54 -0400

> You think the secondary identity that we put in is insufficient?

I wasn't actually suggesting any technical changes (yet), but rather
that the document explicitly cover the topic(s), assumptions, and
limitations. Preferably for both topics now in this thread. I'm happy to
discuss/propose specific text if needed/helpful.

Thanks,
Lou

> 
> On Thu, Aug 1, 2013 at 8:21 AM, Lou Berger <[email-masked]
>     <mailto:[email-masked]>
>     >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >>
>     >>     Hi Joel,
>     >>     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 01 Aug 2013 11:05:18 -0400

> the ability for a new application to take over.

That worries me without more discussion about authentication.
Additionally, from a troubleshooting standpoint, if I can assume the
same identity as another client, how can I be absolutely sure which
client does what to the agent?  I feel there needs to be more to ensure
accountability of what client does what, certainly from a security
perspective, but also from a troubleshooting perspective.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 01 Aug 2013 11:10:56 -0400

> but it also may be acceptable to tell such users to not use I2RS.

It is a pain point, especially for troubleshooting and understanding
what client did what when.  Sure one can not use I2RS, but is that
really acceptable to the WG as a stance when it comes to reputability
and troubleshooting?

Joe

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Aug 2013 11:16:16 -0400

Joe,

What we put in the architecture in response to the concern about user-level
traceability is that there should be a secondary identity that a client can
specify and should be stored for traceability.  The authentication and
authorization of that secondary identity is the client's problem.  The
authentication and authorization of the i2rs client is, of course, the i2rs
agent's problem.

Hopefully, we can reuse existing security techniques and infrastructure.
 I'd recommend working with Wes George and others who indicated interest
and willingness to do work (Sam Hartman, Nancy Cam-Winget, etc) and on the
list to help flesh out the requirements and details.

Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 01 Aug 2013 11:15:42 -0400

On 8/1/13 11:11 AM, Joel Halpern wrote:
> The client is the entity that is authenticated and authorized. If the
> client is acting on behalf of someone else, we assume that the
> authentication and authorization of that party is the task of the client
> and outside our scope. However we include that identity so that actions
> can be easily correlated with originators.

Right.  I get that.  I had thought we were talking about two clients
that might be redundant to each other where Client 1 dies and Client 2
assumes its identity to make changes possibly driven by northbound
actors.  Even in this case, I feel Client 2 still needs to maintain a
unique identification to the I2RS agent so that one can trace the
operation back to the specific I2RS client (in addition to the
northbound actor).

Joe

> 
> Yours,
> Joel
> 
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
> 
> -----Original Message-----
> *From:* Joe Marcus Clarke [[email-masked]]
> *Received:* Thursday, 01 Aug 2013, 17:07
> *To:* Alia Atlas [[email-masked]]
> *CC:* Lou Berger [[email-masked]]; [email-masked] [[email-masked]]; Joel
> Halpern [[email-masked]]
> *Subject:* Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance
> in draft-atlas-i2rs-architecture-01
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 1 Aug 2013 11:19:00 -0400

Joe,

Ok - so what I hear from you is needed is the
   client role
   client identity
   sub-client identity?

Where the permissions and ownership of state is tied to the client role?
 Does that match to what you are saying?  I believe we're assuming that the
ownership of state is tied to the client identity - and you are suggesting
that if so, we need a client sub-identity or such?

Alia

---

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 11:39:26 -0400

[resend: dropped WG on my original reply]

On 08/01/2013 10:05 AM, Joel M. Halpern wrote:
> 
> PS: I do think for the second aspect you raised (traceability) the
> secondary identity is precisely what is needed.  And it is basically
> there for that purpose.

It could be used that way, but I think the application goes beyond
"troubleshooting"...

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 01 Aug 2013 11:44:01 -0400

> Even in this case, I feel Client 2 still needs to maintain a

I completely agree.  Even if there's a simplification to have a single
*active* state writer, there should be a provision to allow the active
writer to shift.

Lou

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 01 Aug 2013 19:28:57 -0400

On 8/1/13 11:19 AM, Alia Atlas wrote:
>  Does that match to what you are saying?  I believe we're assuming that
> the ownership of state is tied to the client identity - and you are
> suggesting that if so, we need a client sub-identity or such?

Yes, I think that is in line with what I'm suggesting.  If we can allow
Client A to assume the identity of Client B using the same credentials,
I would want some way to know that this is indeed Client B now acting on
behalf of either itself or some northbound controller.

Joe

> 
> Alia
> 
> 
> On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > Sent from my Android phone using TouchDown (www.nitrodesk.com
>     <http://www.nitrodesk.com>)
>     >
>     > *From:* Joe Marcus Clarke [[email-masked]
>     <mailto:[email-masked]>]
>     > *To:* Alia Atlas [[email-masked] <mailto:[email-masked]>]
>     > *CC:* Lou Berger [[email-masked] <mailto:[email-masked]>];
>     [email-masked] <mailto:[email-masked]> [[email-masked]
>     <mailto:[email-masked]>]; Joel
>     > Halpern [[email-masked] <mailto:[email-masked]>]
>     > Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>        
>     c i s c o  S y s t e m s
>     > Email: [email-masked] <mailto:[email-masked]>
>     >
>     >
>     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>         c
>     i s c o  S y s t e m s
>     Email: [email-masked] <mailto:[email-masked]>
>

---

From: Joel Halpern <[email-masked]>
Date: Thu, 1 Aug 2013 15:11:16 +0000

The client is the entity that is authenticated and authorized. If the client is acting on behalf of someone else, we assume that the authentication and authorization of that party is the task of the client and outside our scope. However we include that identity so that actions can be easily correlated with originators.

Yours,
Joel

-----Original Message-----
From: Joe Marcus Clarke [[email-masked]]
Received: Thursday, 01 Aug 2013, 17:07
To: Alia Atlas [[email-masked]]
CC: Lou Berger [[email-masked]]; [email-masked] [[email-masked]]; Joel Halpern [[email-masked]]
Subject: Re: [i2rs] Provisions for Client Redundancy/Fault Tolerance in draft-atlas-i2rs-architecture-01

Joe

---

From: "Russ White" <[email-masked]>
Date: Fri, 2 Aug 2013 07:51:31 -0400

> A bit.  The discussion of treating multiple writers for the same state as
errors
> got me worried about this case - from a redundancy perspective, and to a
> lesser degree, accountability standpoint.
> 
failures,
> I think the topic should be covered in the architecture document. Of
course
> this topic/comment can be addressed after the document is adopted.

Wouldn't much of this problem be alleviated if we went to a RESTful style
atomic interface? It seems, to me, that multipart "commit/rollback"
procedures always end up adding a lot of complexity, etc. I know there are
situations where it's simpler to have the client hold partial state while
telling the controller, "this part will succeed, please send me the next
part," but then we've also fallen into dealing with latency of operations,
locking forwarding plane tables across a remote connection (which routing
events are still occurring!), and this entire error management mess in terms
of resiliency.

Routing protocols produce atomic updates today --we should stick with the
pattern set there as much as possible.

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 16:58:00 -0400

I am going to publish an updated version of draft-atlas-i2rs-architecture
without fully addressing this point.

I did add in a new subsection (6.4.1 Client Redundancy) under 6.4 Identity
and Security Role that says:

"I2RS must support client redundancy.  At the simplest, this can be
handled by having a primary and a backup network application that both
use the same client identity and can successfully authenticate as
such.  Since I2RS does not require a continuous transport connection
and supports multiple transport sessions, this can provide some basic
redundancy.  However, it does not address concerns for troubleshooting
and accountability about knowing which network application is actually
active.  At a minimum, basic transport information about each
connection and time can be logged with the identity.  Further
discussion is necessary to determine whether additional client
identification information is necessary.[[Editor's
note: This requires more discussion in the working group.]]"

Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 13 Aug 2013 17:00:38 -0400

Hi Russ,

> events are still occurring!), and this entire error management mess in

[Alia] I don't think that we are suggesting supporting multipart
commit/rollback procedures.  What operations come in a single message can
be handled but so far we are avoiding transaction semantics and certainly
locking any tables across messages!!

> pattern set there as much as possible.

[Alia] Yup - my understanding of their concern is the traceability of
whether the backup has taken over or not.  I'm sure I'm missing nuances
that I will be shortly enlightened about.  :-)

Regards,
Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 14 Aug 2013 13:49:04 -0400

On 8/13/13 4:58 PM, Alia Atlas wrote:
> I am going to publish an updated version of
> draft-atlas-i2rs-architecture without fully addressing this point.
> 
> I did add in a new subsection (6.4.1 Client Redundancy) under 6.4
> Identity and Security Role that says:
> 

This is fine as a start.  I would want to strengthen the language to
ensure that an I2RS Agent always stores Client connection information
with a timestamp.  This information should be queriable via I2RS (with
appropriate read scope).

Joe

> 
> Alia
> 
> 
> On Thu, Aug 1, 2013 at 7:28 PM, Joe Marcus Clarke <[email-masked]
>     > On Thu, Aug 1, 2013 at 11:15 AM, Joe Marcus Clarke
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > authentication and authorization of that party is the task
>     of the
>     >     client
>     >     > Sent from my Android phone using TouchDown
>     (www.nitrodesk.com <http://www.nitrodesk.com>
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>]
>     >     > *To:* Alia Atlas [[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>     >     > *CC:* Lou Berger [[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>];
>     <mailto:[email-masked]>> [[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>]; Joel
>     >     > Halpern [[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>]
>     >     >> On Thu, Aug 1, 2013 at 7:40 AM, Lou Berger
>     <[email-masked] <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >> <mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>     >     >>
>     >     >>     Hi Joel,
>     >     >>     I believe you also answered a latter question by
>     stating that
>     >     clients
>     <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked]
>     <mailto:[email-masked]>
>     >     <mailto:[email-masked] <mailto:[email-masked]>>>
>     <tel:%2B1%20%28919%29%20392-2867>
>     >     c i s c o  S y s t e m s
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >     >
>     >     >
>     >    
>     <tel:%2B1%20%28919%29%20392-2867>         c
>     >     i s c o  S y s t e m s
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     >
>     >

---

From: Lou Berger <[email-masked]>
Date: Wed, 14 Aug 2013 15:19:31 -0400

I agree, a fine start.  There's room to add/relocate in the future.

Thanks!

Lou