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

Tschofenig Hannes <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
hi atul, 

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

> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:[email protected]] 
> Gesendet: Montag, 24. Januar 2005 17:02
> An: Tschofenig Hannes; [email protected]
> 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: [email protected] 
> > [mailto:[email protected]]On
> > Behalf Of ext Tschofenig Hannes
> > Sent: Saturday, January 22, 2005 10:11 AM
> > To: Sharma Atul (Nokia-ES/Boston); [email protected]
> > 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
> > > [email protected]
> > > https://www.machshav.com/mailman/listinfo.cgi/mobike
> > > 
> > _______________________________________________
> > 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.