Subject: RE: [midcom] Fail over mechanism in midcom

From: Tim Rang <[email-masked]>
Date: Wed, 17 Jan 2001 17:42:04 -0500

Inflexible ownership would be a very bad thing.  Consider an application
that dies and another takes over it's work.  If that "fail-over" box cannot
terminate a resource, the only way that resource may be able to be cleaned
up is by timeout, if a timeout is available.  Unless that ownership could be
defined as a group to which multiple apps might belong...

Tim Rang

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2001 5:19 PM
> To: Abdallah Rayhan; [email-masked]
> Subject: Re: [midcom] Fail over mechanism in midcom
> 
> 
> >     1- external agent going out of service and handing the
> >        service off to another agent.
> >        Should the middle box trust the new agent and
> >        impose security challenges on it?
> 
> I think you're missing something here but raising
> a related question that does need to be addressed.
> We're already assuming that more than one agent
> can talk to a middlebox.  What we haven't discussed,
> however, is the question of ownership of transactions.
> If agent A can request a pinhole, will it be possible
> to authorize agent B to dink with that pinhole (close
> it, extend its lifetime, etc.).  This strikes me as an
> authorization/policy question rather than having much
> to do directly with failover.
> 
> >     2- middle box going out of service and handing the service
> >        off to another middle box.
> 
> This really is a very hard problem for a bunch of 
> reasons and I cannot imagine how to do it reliably
> for NAT unless the whole box is being failed over.
> And if that's the case, then it's already being handled 
> elsewhere.  You may want to look at the reliable
> server pooling documents, although I think that
> rserpool is quite unsuitable for applications 
> maintaining a lot of state, which a middlebox
> (firewall, NAT, etc.) almost inarguably is.  At
> any rate, this is clearly out of scope for midcom.
> 
> Melinda
> 
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/midcom
> 

_______________________________________________
midcom mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/midcom