[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)
-----BEGIN PGP SIGNED MESSAGE-----
On torsdag, okt 30, 2003, at 15:56 Europe/Stockholm, marcelo bagnulo
> 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
> 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
>> 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
> 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
> 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
> 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
>> 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
> 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
-----END PGP SIGNATURE-----