Subject: RE: [Mobike] issue #16

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 21 Dec 2004 13:48:06 +0100

hi all, 

maybe we get a little bit lost on this particular issue. what are we
discussing here? here is my short summary: 

a) mobike might get information from other protocols. this might indicate
that there is something wrong with the currently selected preferred address.
mobike does not specify with which protocols it needs to interact and it
does not specify the policy for changing the preferred address. this is
implementation dependent. 

b) there is also a mechanism to detect that something happened along the
path between the ikev2 initiator and the ikev2 responder using some sort of
message exchange (we called it dead-peer detection - which is not the best
name for it; sctp folks called it heartbeat).
this message exchange might reveal that something is wrong along the path
between from a given source address towards a destination address. this
might require a new preferred address to be selected. this new preferred
address needs to be communicated to the other ikev2 peer. 
the format of these messages will be found in a mobike specification. 

btw, we are not the first discussing this area. there has been a lot of work
in the context of sctp on this issue. i have the impression that they have
the same view on it.

hence, i think that there are not particular problems here (except that we
are a little bit struggling with terminology issues). 

ciao
hannes

Jari Arkko wrote:
> 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. 

On which end? On your end, there is. On the other end, there may or may 
not be depending on the level to which dynamic routing changes are 
propagated.

> A host is no
> longer reachable at that address. End of story. 

Agnosticism is useful here; just because you can't reach the other end
does't mean you know ANYTHING for sure about why. Any link on the path
could have gone down, or any routing on the path could have failed.

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

Seeing your own interface change and doing something seems OK - though I 
still feel it encourages YOUR IKE to interfere with YOUR dynamic routing 
(some people run that on the end host too).

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

"mere" address change is the issue. It's fine to say that MOBIKE should
cycle through equivalent addresses for the same endpoint; the question
is WHEN, and how to avoid interference between dynamic routing and MOBIKE.

Joe
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Dec 2004 14:59:31 +0200

> implementation dependent. 

Right.

> might require a new preferred address to be selected. this new preferred

Yes.

> address needs to be communicated to the other ikev2 peer. 

Note: this might also be an address that both peers already know
about, but they have been using the one that is now in trouble,
according to DPD.

> in the context of sctp on this issue. i have the impression that they have

Yes.

> hence, i think that there are not particular problems here

I agree.

--Jari

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Dec 2004 09:23:20 -0800

...
> in the context of sctp on this issue. i have the impression that they have

That is not necessarily a good thing. Multi6 decided to avoid 
encouraging higher layers handling multihoming for several reasons:

	- need to reinvent the wheel for every layer above network
	- interactions between network layer solutions and upper layer
	  solutions

It would be useful to at least review their progress on this issue.

Joe