Re: review of draft-ietf-shim6-failure-detection-03.txt

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

Hi Sam,

And thanks your comments! Some further discussion inline:

>    As for section 6.4 (behaviour), maybe it is a better specification form
>to seperate the text explaination and move them to the corresponding the
>state machine section. Then reader can easily understand what the draft
>says.
>  
>
I have merged the description and the state machine in version -05.
Lets see if you like it better.

>   And why do you think it is suitable to define the value for send timer
>and alive timer as 10s and 3s?
>  
>
The first of these reflects the timeframe under which Shim6 attempts
to recover from a perceived problem. It can not be too long (e.g. minutes)
because otherwise recovery would not be useful for existing sessions.
But it can not be too short either, because temporary glitches would
cause unnecessary Shim6 activity.

The second timer reflects the need to send keepalive messages
under a specific situation (one-way traffic) such that we get
feedback on whether recovery should be started on not.

Its clear that experimentation with suitable values will be
needed, as well as dynamic adjustments. But we've tried to
avoid specifying too many mechanisms for now, until we
get implementation and deployment experience.

>  In my opinion, introduction of shim6 to ipv6 has add the complexity of ip
>layer very much; and shim6-failure-detection is not simple. I don't know
>what is the last performance.
>  
>
It does add complexity, yes. The questions though are if (a) this
complexity is a smaller price to pay than the pain from having no
multihoming or the complexity from other, alternative solutions,
and (b) whether there is something that we could do to reduce
complexity.

On point b, I'm not sure there is a lot we can do. At least not
without revisiting some of the requirement decisions, such
as the need to support at least some scenarios where there's
only unidirectional connectivity.

Thoughts?

--Jari