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

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

A follow-up. Sebastien's comments have been addressed
as follows in the -09 that I will submit today:


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

Having thought about this again, I'm not sure there is anything we
can do with link local addresses unless we build support for recognizing
links. I'm not sure we want to do this, so I made the use of link local
addresses not allowed in Shim6.

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

Fixed in -09.

> There also are two extra STOP <timer>s
> in the state machine, stopping a timer that just timed out.
>   
Fixed.

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

I added some text about this (the first solution).

Jari