-------------------- Lauri Tarkkala (2004-02-29): In IKEv2 DPD state is specific to an IKE-SA. Reading the current drafts, it seems implicit that in MOBIKE it would be specific to a IKE destination (-pair) or a route (-triplet). The design decision to use (or if it is left to an implementor) must be defined. At the very least I would like a mention in the design-draft of this change. [...] It should also be stated that an exchange is considered to be failed (in terms of link dead) only if it has failed being executed over all possible paths [fixed Lauri's typo based on 2004-03-01 message --secretary]. -------------------- Jari Arkko (2004-02-29): Agreed. -------------------- Lauri Tarkkala (2004-02-29): A destination IP address for an IKE peer probably does not have a "preferrered route" (or "preferred source address") associated with it. Assuming the sender has m IKE addresses (IP1..IPm) and the recipient has (IP1..IPn) then it could end up sending m*n messages in total (one message for each (IP1..IPn) * (IP1..IPm) pair). This could be narrowed down using routing information, but in this case we are trying to recover from a route going down and we have to find a still operational one by selecting suitable (srcIP,dstIP) pairs for the IKE packets. -------------------- Tero Kivinen (2004-03-01): In the MOBIKE we are trying to fix the problems appearing at the host end, i.e. one of the laptops interface goes down, or one of the ISPs connected to the SGW breaks. In this case it does not really matter which interface is used to route the packet out from the other end. That would only matter in case the network problem is further on in the net (i.e. the London case, and routing packets through Amsterdam might help, but I do not think that is the main case for the MOBIKE to tr to fix that). I think selection of the local address should be left as local implementation issue. In some cases the host might have information from the routing information to select suitable addresses, in some cases it might simply use the most preferred IP-number first and if it does not receive any reply back then it can try other IP-numbers. If we think tat in the laptop case the laptop will most likely have 2-3 interfaces and in most cases the SGW will have 1-2 interfaces so the number of actual packets is going to be 2-6... -------------------- Francis Dupont (2004-03-01): In the spirit it should be a route, i.e., dead-path detection in place of dead-peer (which is "all paths are dead"). > The design decision to use (or if it is left to an implementor) must > be defined. At the very least I would like a mention in the > design-draft of this change. This is a matter of policy... Perhaps Tero has a good text to propose? [another message] > A destination IP address for an IKE peer probably does not have a > "preferrered route" (or "preferred source address") associated with > it. It seems you've found an usage for my notification ordering feature as it can easily encode this. > Assuming the sender has m IKE addresses (IP1..IPm) and the recipient > has (IP1..IPn) then it could end up sending m*n messages in total > (one message for each (IP1..IPn) * (IP1..IPm) pair). I agree: we should replace this product by a sum. > This could be narrowed down using routing information, but in this > case we are trying to recover from a route going down and we have to > find a still operational one by selecting suitable (srcIP,dstIP) > pairs for the IKE packets. SGs are routers so they could get reachability infos by other ways... (argument heart this morning) -------------------- Jari Arkko (2004-11-30): Our earlier resolution of issue 17 (if both parties have several addresses, do we assume that all pairs have connectivity between them?) was that we should NOT assume full connectivity in these cases. I believe the above resolution implies that upon a problem, we may have to switch paths, not just an address. I also explained the issue in Washington in my presentation. So I think its pretty clear that the answer to this question is that we need to be able to change paths. Suggested text below: Change design draft from 6. Changing addresses or changing the paths (issue #10, #14) The question here is, if it is enough for the MOBIKE to detect the dead-address, or do it need to detect also dead-paths. Dead-address detection means that we only detect that we cannot get packets through to that remote address by using the local IP-address given by the local IP-stack (i.e. local address selected normally by the routing information). Dead-path detection means that we need to try all possible local interfaces/IP-addresses for each remote addresses, i.e. find all possible paths between the hosts and try them all to see which of them work (or at least find one working path). Doing the dead-address detection is simpler, and there is less probe packets to be sent, thus it does not cause that much stress to the network. It also is enough for the scenarios where the connection problems are local (i.e. interfaces going down, WLAN access disappearing etc). It does not help if some router somewhere along the path breaks down, in which case rerouting the packets along another path might get around that broken router. The question is, whether rerouting around that problem inside the core network is a problem that MOBIKE needs to solve. to 6. Changing addresses or changing the paths (issue #10, #14) The question here is, if it is enough for the MOBIKE to detect the dead-address, or do it need to detect also dead-paths. Dead-address detection means that we only detect that we cannot get packets through to that remote address by using the local IP-address given by the local IP-stack (i.e. local address selected normally by the routing information). Dead-path detection means that we need to try all possible local interfaces/IP-addresses for each remote addresses, i.e. find all possible paths between the hosts and try them all to see which of them work (or at least find one working path). While performing just an address change is simpler, the existence of locally operational addresses are not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent the sent packets from reaching their destination. Or a failure of an interface on one side can be related to the failure of an interface on the -------------------- Hannes Tschofenig (2004-12-06): i agree with you that we need to test paths rather than addresses. i have read your multi6 draft which also derives this conclusion. my personal experience with path-coupled signaling in the nsis environment also supports this observation. -------------------- Issue closed (2004-12-13): "Not assuming full connectivity (issue 17) implies that changing paths is sometimes necessary." --------------------