continued review of /draft-ietf-shim6-failure-detection-03.txt

[<john.loughney@nokia.com>]

continued from where I left off.

Section 5.2:

   Upon changing to a new address pair, transport layer protocol needs
   to be informed so that it can perform a slow start, or some other
   form of adaptation to the possibly changed conditions.  However, this
   functionality is outside the scope of REAP and is rather seen as a
   general multihoming issue.

Slow start is really for TCP, probably you should generalize this to
say:

   Upon changing to a new address pair, the network path traversed most
likely
   has changed, so that the ULP SHOULD be informed. This can be a signal
   for the ULP to adapt due to the change in path so that, for example,
   TCP could initiate a slow start procedure.

or something along those lines.

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

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?

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.

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.

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

6.1.  Keepalive Message

Missing explanations of the  Hdr Ext Len, Checksum fields.

====
NOTE: 
I'm holding off on a full protocol review until a revision, it looks
basically like it could work.

====

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.

=== 

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.  If you want to design it as a
completely standalone
protocol, then that should be done - though I would not recommend that
option.

John