Re: delayed multihoming/mobility set-up

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



What I think we need to do at some point in the future though, is to 
define what we _can_ do. Agreed, that is far way and not what we should 
focus on now.


- - kurtis -

On onsdag, nov 19, 2003, at 14:51 Europe/Stockholm, Brian E Carpenter 
wrote:

> 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

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBP8Jz+6arNKXTPFCVEQLCwACgjCRXBA1hW324bus3rCKoWxu1RfQAoLl0
2E8/VISCy9Bg23+wEiqj11Q8
=7b1B
-----END PGP SIGNATURE-----