RE: Some thoughts about "path failover"

[email protected] writes:
> The document probably has to say something about acceptable
> retransmission behavior, in order to ensure that the path
> testing works together with that.

Yes, but normally those include that if you get n retransmissions
immediately following each other, you only reply to one of them (this
can happen, when there is some box between that queues the packets for
some reason, the normal reason for developers to see this is the case
where they debug the program and it is stopped in the debugger for
some time, and the other end decides to retransmit several packets
during that time). 

> This seems to assume that we have e.g. some configuration
> information for picking the best working local IP address 
> (or in other words, prior knowledge about which paths 
> are likely to work, given that the current one doesn't).

Yes, the local host do have the information about what source address
should be usable for the remote end. I.e. if it tries to route them
out, he do get one ip-address which to use...

He also have knowledge which of the local links are broken, thus if he
removes the routes from those links, then packets will not be routed
to those links, and it will not use that ip-address.

I do not think MOBIKEs should be fixing problems in the core network,
i.e. the sender will only select the local ip based on the local
information he have (i.e. information from the link status and routes
for each links). 

> If we have that, we certainly should take that into account, but

We do have information which links are up, i.e which local
ip-addresses are working. Also if the local routing information
indicates that if you send packet to that ip-address you should be
using this link, then you should select source ip-address from that
link. There is nothing more we need. 

> IMHO we should also handle the case where no such information
> exists (my message yesterday suggested that "...this could be
> either all N*M paths, or if the initiator has some additional
> knowledge, only a subset of that").

I do not think we should be trying to get around the general routing
problems inside the core network. That is not MOBIKEs job. 
-- 
[email protected]