[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Question about REAP state transition (draft-ietf-shim6-failure-detection-09)
- To: <email@example.com>
- Subject: Question about REAP state transition (draft-ietf-shim6-failure-detection-09)
- From: Alberto García <firstname.lastname@example.org>
- Date: Wed, 12 Dec 2007 17:15:25 +0100
I have a question about draft-ietf-shim6-failure-detection-09.
First, my understanding of the specification is that Probe Exploring
messages do not carry neither "probe received information source address"
nor "probe received information destination address", etc. Although this
information is not normally available at the Exploring state, it could be
available if the node was in the past in the Inbound_OK state, but a Send
Timeout occurred to move it to the Exploring state.
If this is true, I wonder if it is possible that the exploration process
could not find two valid unidirectional paths (on each direction) even if
they exist. Suppose that a node A in Exploring state receives a Probe
Exploring, so it moves to Inbound_OK. For the next Probes it sends, it
includes the information about the valid locators for its incoming paths (B
to A), but it is not able to find a working path from A to B for some time.
In B, the Retransmission Timer of B expires because a valid path from A to B
was not found, so B starts testing other paths that are not working. Then, A
stops receiving data from B, so the Send timer expires (I don't find any
reason why all the possible paths should be explored in less than Send
Timeout time, so A could not test all possible paths from A to B in this
time). Then, A falls to the Exploring state, and (in the supposition of the
previous paragraph) forgets about the working path from B to A. May be now A
sends a probe to B through a working path. but in B happens the same (it
tries now with different paths from B to A that are no valid, so A tries
another paths from A to B abandoning the good one...). In this case, two
valid unidirectional paths existed, one from A to B, and other from B to A,
but the protocol could not find them, because they not were known at the
same time by both nodes.
I'm missing something?