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

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

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


On torsdag, okt 30, 2003, at 15:56 Europe/Stockholm, marcelo bagnulo 
wrote:

> Kurtis wrote:
>
>> Isn't this simply expectation management? The reason we changed the
>> requirements into goals was because the items in the document where
>> either contradictory; we realized that we couldn't get it all so make
>> it all requirements wasn't an option; and we couldn't decide on what
>> issues where needed more than others; ?
>>
>
> Well i am not sure this the case of session survivability, at least 
> right
> now. I mean, i don't think that providing transport session 
> survivability is
> contradictory with another of the requirements, it is just that 
> providing it
> is expensive.

So we are back to what is the definition of "having survived"? How long 
is reasonable before a session times out? This has been discussed in 
several other discussions such as site-local as well. There is no easy 
answer.

>> I think that connection survivability is a nice to have,
>
> IMHO is more than that. It is the main problem that we have.
> I mean, all other aspects of multihoming are simpler to solve than 
> this one
> i guess.

Again. Depends on the timeout value.

> The preservation of established sessions is the only requirements that 
> its
> support imposes modifications of both sites of the communication. this
> implies that hosts *outside* the multihomed site will need to be 
> upgraded in
> order to support this feature of the multi-homing solution. This is 
> IMHO a
> great effort with a really important cost. This cost is justified only 
> if it
> is an important feature, i guess.

Agreed. Note that "nice to have" is not the same as "shouldn't have". I 
agree that it is a really important criteria, but it's not THE criteria.

> If session preservation is a nce to have feature, we could just don't
> provide it and provide a multi-homing solution that only imposes
> modifications to the multi-homed site.

We could. But if we can, we should address it. I am trying introduce a 
gray scale here...

> So the approach that is proposed would be:
> The general M6 layer provides a general service, for instance based in
> current bgp response times

Ok, that is a good definition of my gray scale..:-)

> Also, the M6 accepts hints from modified ULP that have more demanding
> requirements. This would enable that if an ULP is capable of detecting
> outages more quickly than the generic M6 layer it can signal it to the 
> M6
> layer so that it can react somehow

Ok, I am still worried over this hints thing...

>> More, if there is also a rerouting event causing
>> distribution of bad news, and perhaps a new set of locators, or the
>> signaling to move to new locators, this might trigger a "race-like"
>> condition, depending in what order the priorities are set and in which
>> order they arrive where, and then actually making the case worse - no?
>
> I guess that we should try to see if it is possible to design a 
> solution
> that a avoids that.

Oh, I think it is. I just think we need to keep that in mind.

>>
>> "restoration" time is due to these X factors, they can be influenced 
>> by
>> this - but they are not an issue per se for the multi6 layer.
>
> Yes, but IMHO we should define those potential hints and also define 
> the
> interaction among them. Do you agree?

Yes. But I am not convinced that is where we should start.

- - kurtis -


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

iQA/AwUBP6gABaarNKXTPFCVEQKBZQCeMxHeEwp8hzcmnrq2eeRr5y/FAwUAoJUY
9FP++DhY6Wznp/tjLx3jewye
=3zeS
-----END PGP SIGNATURE-----