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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.