RE: issue 10: changing addresses or paths?
Tschofenig Hannes <[email protected]>
| Newsgroups | gmane.ietf.mobike |
|---|---|
| Message-ID | <[email protected]> |
hi jari, i agree with you that we need to test paths rather than addresses. i have read your multi6 draft <http://www.ietf.org/internet-drafts/draft-arkko-multi6dt-failure-detection- 00.txt> which also derives this conclusion. my personal experience with path-coupled signaling in the nsis environment also supports this observation. ciao hannes > 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 > other side, making it necessary to change more than one address > at a time. > > --Jari > > _______________________________________________ > Mobike mailing list > [email protected] > https://www.machshav.com/mailman/listinfo.cgi/mobike >