Subject: [Mobike] question on draft-ietf-mobike-design-01.txt

From: <[email-masked]>
Date: Mon, 17 Jan 2005 11:33:35 -0500

In section 3.2 Multihoming scenario, do we allow simultaneous change of preferred addresses
at both the peers? The figure there kind of implies it. 

Could we explicitly say there whether we support such a simultaneous change? 

Atul

_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Tschofenig Hannes <[email-masked]>
Date: Sat, 22 Jan 2005 16:10:33 +0100

hi atul, 

> at both the peers? The figure there kind of implies it. 

we say that each peer change its preferred address at any time and that
there needs to be a mechanism to communicate this change to the other peer. 

if the peer address set contains more than one address then both peers can
still communicate with each other even if they happen to change their
preferred address at the same time. 

(btw, i don't think that the figure is good enough to show this situation.)

what is outside the scope is the case where a third entity would be
required. 

> Could we explicitly say there whether we support such a 

we can add something explicitly, if you think it is necessary. 

ciao
hannes

---

From: <[email-masked]>
Date: Mon, 24 Jan 2005 11:01:33 -0500

Hi Hannes,

I will give a particular scenario, which will make explicit
the question I was trying to raise. The scenario is inline.

Atul

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On
> Behalf Of ext Tschofenig Hannes
> Sent: Saturday, January 22, 2005 10:11 AM
> To: Sharma Atul (Nokia-ES/Boston); [email-masked]
> Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt
> 
> 
> hi atul, 
> 

Let us say Peer 1 has addresses A and B; Peer 2 has addresses C and D. Say
A and C are the advertised preferred addresses. Imagine both interfaces/paths
corresponding to A and C go down simultaneously. Peer 1 shall send to Peer 2
on address C telling the new preferred address is B. Peer 2 shall send to
Peer 1 on address A telling the new preferred address is D. But none of these
MOBIKE address change messages shall reach the other end.

Do we in the MOBIKE protocol incorporate the assumption that Peer 1 shall
always know of addresses C and D of Peer 2; and on not getting the ack from
Peer 2 on address change shall try sending the address change notification
to address D?

I had this kind of simultaneous change of preferred address in mind for the 
original question.

> (btw, i don't think that the figure is good enough to show 

The figure does not explicitly describe this situatiopn, it just implies it
by saying: "If Peer A and Peer B change their preferred address".
 
> what is outside the scope is the case where a third entity would be

I understand that, we are not taking the MobileIP path.
> we can add something explicitly, if you think it is necessary. 

I think, it will definitely help.

---

From: Tschofenig Hannes <[email-masked]>
Date: Sat, 29 Jan 2005 14:00:16 +0100

hi atul, 

thanks for your attempt to clarify this issue. please see my comment inline:

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Montag, 24. Januar 2005 17:02
> An: Tschofenig Hannes; [email-masked]
> Betreff: RE: [Mobike] question on draft-ietf-mobike-design-01.txt
> 
> 
> Hi Hannes,
> 

the path a <-> c does not work anymore because the respective interface at
each peer is down. 

now, what happens depends on the previously communicated peer address set.
if peer 1 and peer 2 decided that they communicate the peer address set
{a,b} and {c,d} for peer1 and peer2 respectively then both nodes can
recover. 

> Peer 2 on address change shall try sending the address change 

we don't need to make the assumption that each peer communicates all its
addresses. i would rather see this as a local decision of each peer which
address to advertise. however, as we can see in the previous example it
would certainly help. peer 1 might not want to send all its addresses to the
other peer. 

> I think, it will definitely help.

i think that an example, similar to the one above would certainly help. 

ciao
hannes