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

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Kurtis,

I am including answers to both of your emails referring this topic in this
one.

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.

> 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.
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.
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. Such a solution would be more easily
accepted and deployed, since only the ones that obtain a direct benefit has
to upgrade their systems.
But I would say that this is not the case, people have been saying that the
preservation of established communication is important.

> but wether a
> connection will survive or not will also be highly dependent on the ULP
> as Erik points out. I think this is best handled by simply documenting
> what this solution offers, and what the alternatives for the ULPs are.
>

I think that we can do a bit more than that. I guess that we can provide
some ways to allow M6 compatible ULP to obtain an enhaced service.
I mean:
Different ULP have different needs, so it seems expensive (and perhaps
useless) to provide a general solution that satisfies the more demanding
needs.
So the approach that is proposed would be:
The general M6 layer provides a general service, for instance based in
current bgp response times
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

This presents some  potential difficulties like the ones you point out:

> 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.

> Would it not be better to simply say that survivability and
> "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?

Regards, marcelo

> They
> might depend on ULP signaling, BGP convergence, etc. But that is
> another issue.
>
> Am I making my life to easy here?
>
> - - kurtis -
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.2
>
> iQA/AwUBP5+NMKarNKXTPFCVEQLuTQCg8NTn1V0mniEDuTYQCybs3cyLFnUAoIq+
> 6m1xmITLki2bShj/JcERogDm
> =DI3I
> -----END PGP SIGNATURE-----
>
>