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

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

Hi John and many thanks for your review. I'm finally
getting to updating the failure detection document.

Please find below some further discussion
where it was warranted. For the rest I have simply
adopted your suggestions.

>2) Intro says:
>
>   This draft defines the mechanism and protocol to achieve both failure
>   detection and locator pair exploration.  This protocol is called
>   REAchability Protocol (REAP).  It designed to be carried within the
>   SHIM6 protocol, but may also be used in other contexts.
>
>I think we should drop the '... may be used in other contexts.' as this
>seems
>outside of the scope of SHIM6. I don't think that SHIM6 should work on a
>general
>purpose failure detection & path exploration protocol.  
>  
>
We have tried to scope the document to Shim6 and only
Shim6, although some earlier versions had more ambitious
goals. I'll remove the text that you quote above and see
if there are any other similar cases later in the next.

This narrow scope is necessary for us to complete the
work. (Neverthless, its been my hope that we can use
the same protocol later in, e.g., HIP, because the protocol
number and basic format between SHIM6 are already
very close to each other. However, there are non-trivial
issues in extending it. For instance, while its easy to
add IPv4 support, adding NAT support may not be all
that easy -- in MOBIKE for instance this was the hardest
part.)

>   ...  We assume that there are other, higher
>   level identifiers such as CGA public keys or HBA bindings that tie
>   the different locators used by a node together [17].
>
>Do we need to care about higher level identifiers for REAP?  My guess is
>that
>is something that should really matter for REAP, so that suggesting CGA
>or HBA
>would be something of relelvance for REAP is misleading.
>  
>
Specific techniques for identification should be removed from this
document.

>I also wonder if a blanket statement along the lines of "Many protocols,
>both
>standardized in the IETF and outside of the IETF make use of keep-alives
>to
>trVack the live-ness of a connection or session."  Also, you might want
>to consider
>RSVP also, as RSVP does track path conditions at the raw IP level.  I
>can supply
>text if needed.
>  
>
I like the blanket statement. Perhaps no need to say anything about
RSVP then.

>	
>5.3.  Exploration Order
>
>   The exploration process assumes an ability to pick current and
>   alternative address pairs.  
>
>The above sentence doesn't parse ... do you mean "... and use an 
>alternative address pair."?
>  
>
I see the problem. How about "... assumes an ability to pick a sequence
of alternative address pairs to try in order."?

>Section 5.3:
>
>   Nodes MUST first consult RFC 3484 [6] Section 4 rules to determine
>   what combinations of addresses are allowed from a local point of
>   view, as this reduces the search space. 
>
>RFC 3484 is "default address selection"; I would hesitate to make this
>a MUST.  I would say that 3484 is the default mechanism for REAP, but
>surely nodes can have an optimized algorithm?
>  
>
Yes they should be able to. A SHOULD seems more appropriate.

>Section 5.3:
>
>   One suggested good implementation strategy is to record the
>   reachability test result (an on/off value) and multiply this by the
>   age of the information.  This allows recently tested address pairs to
>   be chosen before old ones.
>
>This suggestion confuses me.  If reachable = 1 and unreachable = 0;
>multiplying
>it by the age of the information, I guess we'd like to choose the lowest
>non-zero
>value ... but I suggest deleting this text, unless you want to make a
>more formal
>algorithm for this action.
>  
>
I'd rather delete this text, and replace it with something that
suggests the age of previously acquired information should be
taken into account.

>Section 5.3:
>
>   Out of the set of possible candidate address pairs, nodes SHOULD
>   attempt a test through all of them until a working pair is found, and
>   retrying the process as is necessary.  However, all nodes MUST
>   perform this process sequentially and with exponential back-off.
>   This sequential process is necessary in order to avoid a "signaling
>   storm" when an outage occurs (particularly for a complete site).
>   However, it also limits the number of addresses that can in practice
>   be used for multihoming, considering that transport and application
>   layer protocols will fail if the switch to a new address pair takes
>   too long.
>
>I know you are describing a general procedure, but I think this protocol
>needs
>some suggest timer values, etc.  'as is ncessary' isn't sufficient.  If
>you 
>define timers elsewhere, then put a forward reference to the section,
>please.
>  
>
Yes -- the need for timers has been brough up by others as well.
They will be included.

>Section 5.4
>
>   REAP is designed as a modular part of SHIM6 in the hopes that it may
>   also be useful in other contexts. 
>
>This sentence doesn't make sense - you designed it to be a modular part
>of SHIM6
>so that it might be useful in other contexts?  I think you mean it is
>not included
>in the base shim6, but as a stand-alone, modular protocol as it may have
>potential
>uses for other protocols ....
>  
>
This will be removed.

>7. Security Considerations
>
>I think you should say that REAP SHOULD NOT rely on unverified "various
>indications from 
>lower layers" etc. to determine connectivity or failure, as they may be
>spoofed.
>  
>
Ok.

>General comment - lots of text in the document is somewhat speculative,
>esp. the use
>of REAP in other scenarios.  I'd probably tighten-up this language.
>Designing the
>protocol to a modular piece of SHIM6 is a good idea, but speculating
>that it could
>be used elsewhere seems inappropriate.
>
Right. This will be done in -04.

>4) Generally, I could quibble with some text in section 4 - if the
>authors feel
>quibbling is valuable, I could send text. 
>
I believe it would be valuable. Please send text.

--Jari