Re: New issue 16: No packets from other end?
Francis Dupont <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
In your previous mail you wrote:
I've created a new issue in the issue list:
"Can the protocol recover from situations where the only
sign of problems is lack of packets from the other end?"
(http://www.vpnc.org/ietf-mobike/issues.html)
=> note that this issue applies only if we decide that the protocol
should handle everything by itself, i.e., there is no generic control
of the mobile/multi-homed environment (what should be likely the
case for a not-dedicated-to-IPsec box).
Regards
[email protected]
PS: the action related to issue 7 is done. IMHO we can stop here the
possible interactions between Mobike and transport mode but we'll
talk about that when my draft will be available in repositories, i.e.,
tomorrow or next week?
PPS: IMHO it is not a good idea to put everything into mobike tools:
we should not re-invent all the movement detection and multi-homing
handling. For example SCTP tried and even failed to specify a complete
peer dead detection. We should only specify what kind of events or
conditions should be reported to the generic control ("lack of packets
from the other end" is a good example) and what kind of actions should
be proposed to the generic control (tear-down, update, addition of a
new peer address, etc), but not the control itself!