About draft-ietf-shim6-failure-detection-07

[Sébastien Barré <sbarre@info.ucl.ac.be>]

Hi,

while implementing the failure detection draft version 7 (new release 
available soon at http://gforge.info.ucl.ac.be/projects/shim6/), I have 
found some things I would like to ask precisions about :


section 3.1 : available addresses
----------------------------------------------------
--
Where IPv6 link-local addresses are used, their use needs to be
     unambiguous as follows.  At most one link-local address may be
     used per node within the same connection between two peers.
--

Why ? What is the problem in dealing with multiple link-local addresses ?
In fact, I think the problem is not in dealing with multiple link-local 
addresses, but rather in making sure we use a link-local address over 
the right link.

* Using the peer's link-local address (announced during shim6 
intialization in the peer locator set) : The problem is that we have no 
way to know if the peer is in the same subnetwork as us. Moreover, if we 
have multiple interfaces, which is the one corresponding to the given 
link-local address ? Because of this, I think it is not correct to send 
the link-local addresses as part of the locator list during shim6 
initialization without a proper mechanism, but I also guess it is not 
worth designing such a mechanism, given the limited interest in doing that.
* Using the local link-local address as source for exploration : If we 
use our link-local address as source, we know over which link to use it, 
but this is not really useful if we don't know if our peer is inside our 
subnetwork.

* In summary, it appears to me that link-local addresses are not really 
suitable for use with shim6/reap. Am I missing something ?


State machine (table 4)
--------------------------------------

--
Upon a timeout on the Send timer, the node enters the Exploring
  state, sends a Probe, and stops the Keepalive timer if it was
  running.
--
Why to stop the Keepalive timer ? Isn't it always stopped when the send 
timer is running ? (so necessarily also if it does a timeout).


Incoming probe Inbound OK
----------------------------------------------

As specified in the draft, the reception of a probe Inbound OK triggers 
a come back to the operational state. But a come back to the operational 
state implies that a pair of working locators are given to the shim, for 
use as current locator pair. AFAIK, this locator pair must be chosen in 
the list of probes received : each received probe report contains a 
working locator pair, which may be chosen as the new current locator 
pair. Now, the problem is that it is possible to receive a probe Inbound 
OK without any probe reception report inside. For example, if the peer 
receives an incoming packet while in state exploring, it will send an 
Inbound OK probe without any source reception report. In this case the 
receiver of that probe is only able to know that *there is* a working 
locator pair, but it cannot know which is that locator pair. In fact I 
guess we have two solutions to solve this :
- Let the draft as is : When we receive a probe Inbound OK without any 
received probe report (Precvd=0), we conclude that a payload packet or a 
keepalive has been received by the peer, which means that we can come 
back to the operational state without changing the current locators. 
(Because payload packets and keepalives are sent with current locators).
- Find some way to report the reception of data packets/keepalives : In 
the case of probes having been received, this would allow to tell the 
peer that also the current locator pair is working.

What do you think ?

Sébastien.

--
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium