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

[Jari Arkko <jari.arkko@piuha.net>]

Sébastien,

Thank you for the questions -- its always good to hear what
implementors have found problematic in a spec.
>
> 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.
>

Right.

> * 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 ?
>

Not really. The draft does not explain the reasons why it
was left out, but its more or less according to what you
describe above. Its something that we could make work,
perhaps, but I also am not sure the effort is worth it.
>
> 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).

Right. Thanks for catching this. There also are two extra STOP <timer>s
in the state machine, stopping a timer that just timed out.

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

reading on...

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

Very interesting case, indeed!

I agree that this is a problem. I would prefer your first solution
(or at least not changing the locator pair used for one direction,
perhaps there was some other reason to change the other).

Jari