[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)



> My apologies for not being clearer. What I meant was, multi6 should
> pick a targer for survivability, whether measured in tens of minutes
> (TCP), tens of seconds (HTTP with a human in the loop) or hundreds of
> milliseconds (VoIP).
>
> By doing so, communities can consider their needs vis-a-vis the
> target. If your needs are met by the target, you can rely on multi6
> for survivability, and if not, you can start working on
> special-purpose survivability mechanisms.
>

My reading of the thread is that the approach is somehow different:

The solution will provide a basic capability based on routing system path
outage detection.
Such mechanism won't provide a defined response time, since its response
time depends on the situation and the worst case can be very bad.

Additionally, the solution would accept hints from the ULP that can be used
as failure detection mechanism. This is better than leting the apps start
working on their own special purpose survivability mechanism, since they
don't need to discover alternative locators and provide proper security and
so on, they just need to provide hints to facilitate outage detection

The general mechanism would be used by ULP that don't require such a good
response time and also by legacy ULP that don't implement the hint
mechanism.
Does this sound good to you?

Thanks, marcelo

> Spencer
>
> ----- Original Message -----
> From: "marcelo bagnulo" <mbagnulo@ing.uc3m.es>
> To: "Spencer Dawkins" <spencer@mcsr-labs.org>; <multi6@ops.ietf.org>
> Sent: Thursday, October 30, 2003 8:56 AM
> Subject: RE: Preserving established communications (was RE: about
> draft-nordmark-multi6-noid-00)
>
>
> > Hi Spencer,
> >
> > > Agreed, but I'm not sure everyone else in the IETF agrees. It
> Would Be
> > > Lovely to pick a target (TCP survivability, HTTP survivability,
> VoIP
> > > survivability being three rough possibilities) and agree on it.
> >
> > What do you mean?
> > That the M6 layer should provide 3 types of service, TCP HTTP and
> VoIP like
> > services and that the app can select it? Or perhaps an automatic
> selection
> > based in the port/protocol combination that is being used?
> > Or just that we should have theses 3 services as reference?
> >
> > Regards, marcelo
> >
>
>