[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
continued review of /draft-ietf-shim6-failure-detection-03.txt
continued from where I left off.
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
Upon changing to a new address pair, the network path traversed most
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."?
Nodes MUST first consult RFC 3484  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?
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;
it by the age of the information, I guess we'd like to choose the lowest
value ... but I suggest deleting this text, unless you want to make a
algorithm for this action.
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
I know you are describing a general procedure, but I think this protocol
some suggest timer values, etc. 'as is ncessary' isn't sufficient. If
define timers elsewhere, then put a forward reference to the section,
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
so that it might be useful in other contexts? I think you mean it is
in the base shim6, but as a stand-alone, modular protocol as it may have
uses for other protocols ....
6.1. Keepalive Message
Missing explanations of the Hdr Ext Len, Checksum fields.
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
lower layers" etc. to determine connectivity or failure, as they may be
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.
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
protocol, then that should be done - though I would not recommend that