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

[Tschofenig Hannes]

hi atul, 

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

> -----Ursprüngliche Nachricht-----
> Von: Atul.Sharma at nokia.com [mailto:Atul.Sharma at nokia.com] 
> Gesendet: Montag, 24. Januar 2005 17:02
> An: Tschofenig Hannes; mobike at machshav.com
> Betreff: RE: [Mobike] question on draft-ietf-mobike-design-01.txt
> 
> 
> 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: mobike-bounces at machshav.com 
> > [mailto:mobike-bounces at machshav.com]On
> > Behalf Of ext Tschofenig Hannes
> > Sent: Saturday, January 22, 2005 10:11 AM
> > To: Sharma Atul (Nokia-ES/Boston); mobike at machshav.com
> > Subject: AW: [Mobike] question on draft-ietf-mobike-design-01.txt
> > 
> > 
> > hi atul, 
> > 
> > > 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. 
> > 
> > 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. 
> 
> 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.

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. 

> 
> 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?

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 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 
> > this situation.)
> 
> 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
> > required. 
> 
> I understand that, we are not taking the MobileIP path.
> > > 
> > > Could we explicitly say there whether we support such a 
> > > simultaneous change? 
> > 
> > we can add something explicitly, if you think it is necessary. 
> 
> I think, it will definitely help.
> 

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

ciao
hannes

> > 
> > ciao
> > hannes
> > 
> > > 
> > > Atul
> > > 
> > > _______________________________________________
> > > Mobike mailing list
> > > Mobike at machshav.com
> > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > > 
> > _______________________________________________
> > Mobike mailing list
> > Mobike at machshav.com
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > 
>