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