Re: delayed multihoming/mobility set-up

[Brian E Carpenter <brc@zurich.ibm.com>]

What we should probably be clear about is that multi6
is not aiming to support instant QOS restoration. In other words
we are not aiming to be qualified for emergency services and not
even for fast signalling (which is what SCTP is aimed at).

   Brian

Pekka Savola wrote:
> 
> On Mon, 17 Nov 2003, Kurt Erik Lindqvist wrote:
> > > Uhh, could you clarify how this relates to this subject?  I think
> > > I see a few ways to tie these together, but I'm not sure what your
> > > point is..
> >
> > ( I was a bit fast there, to much mail to read and catch up with)
> >
> > Well the point I was after was your discussion on when a connected
> > session should expect connection survivability. In todays IPv4/IPv6
> > internet, a connection passing over a EGP boundary (and I guess in
> > worst case even inside ASes) will have to take the route
> > cancellation in effect. This means that you will always have to
> > worry about this. So the last you said was :
> >
> > > Note that in low-mobility or site multihoming scenarios you don't
> > > expect the the multihoming to be required *immediately*; the risk
> > > increases in proportion to the time.
> >
> > And I was pointing out that you can't expect it to be immediate in the
> > case above.
> 
> No, this does not make sense.
> 
> I'm trying to guess what point you're making.  I can see two
> possibilities which neither clearly falls inside your text:
> 
>  1) "if a route goes down, how long does it take to be able switch to
> the other connection if the protocols supported transport
> survivability"
> 
>  2) "if a route goes down, and comes back up, how long does it take
> until it's fully usable everywhere?"
> 
> Both of these are interesting, but not directly related to the
> question I raised, AFAICS.
> 
> Could you try to elaborate a bit more?
> 
> The proposal was all about stable configuration.  Instead of setting
> up connection survability immediately when setting up the connection,
> it would only be done for connections that pass certain criteria check
> (e.g. last more than T minutes).  That way, if there is a failure
> inside 0 ... T minutes from the startup of the connection, the
> connection in question will fail.  If not, it'll just switch to the
> another connection transparently, with the possible problems switching
> connections may have.  This is just about optimizing away the
> connection survability for "statistically" short-lived sessions unless
> you really care about that feature.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK