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

[Alia Atlas <[e-mail]>]

Hi Russ,

On Fri, Aug 2, 2013 at 7:51 AM, Russ White <[e-mail]> wrote:

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

[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!!


> Routing protocols produce atomic updates today --we should stick with the
> 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


>
> :-)
>
> Russ
>
>