Re: issue #16

Joe Touch wrote:

> | (1) You are OK with explicit management of addresses
> |     when we have local information from the other
> |     parts of the stack that we need to do something,
> |     such as when the currently used link went down,
> |     ND tells us that we have moved to a new address,
> |     and so on.
> 
> Not quite - I don't buy the part about the 'link going down'. All you
> know is that the other end isn't reachable. Reacting to links is what
> dynamic routing does; if this layer does it as well, there's liable to
> be interactions (in a bad way).

Maybe I described it too vaguely... I did not mean just
any links -- that's in the routing domain.

If the WLAN interface of my laptop goes down there's nothing
in the routing system that reacts to this. A host is no
longer reachable at that address. End of story. But perhaps
you are thinking of links within the routing system, such
as between routers? I agree that its definately out of scope
for MOBIKE. The end hosts running IKE would not even see
this. But they would see their own interface go down, which
I think is in scope.

> Trying a new mapping, or cycling among alternate names ought to happen
> when IKE starts anyway (at the app layer).
...
> It depends on what the errors are. Some warrant a restart, some do not.
> But, IMO, they warrant restart of the IKE.
...
> More that cycling among alternate addrs is something that ought to
> happen on start anyway - side-effect isn't quite the right term; it's
> more like 'already included explicit mechanism'.

Its unclear to me what you mean by IKE "start" or "restart". The
purpose of MOBIKE is precisely to avoid having to re-run IKE from
the beginning for a mere address change.

--Jari