Hi Behcet, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Behcet Sarikaya > Sent: Thursday, March 22, 2012 12:50 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [DMM] review of draft-bernardos-dmm-distributed-anchoring- > 00 > > Hi Carlos, > > On Wed, Mar 21, 2012 at 6:11 PM, Carlos Jesús Bernardos Cano > <[email protected]> wrote: > > Hi Behcet, > > > > On Mon, 2012-03-19 at 11:13 -0500, Behcet Sarikaya wrote: > >> Hi Carlos, > >> > >> On Sun, Mar 18, 2012 at 2:59 PM, Carlos Jesús Bernardos Cano > >> <[email protected]> wrote: > >> > Hi Behcet, > >> > > >> > On Fri, 2012-03-16 at 11:06 -0500, Behcet Sarikaya wrote: > >> >> Hi Carlos, > >> >> > >> >> You say in various places in your draft that your protocol is > PMIPv6-based. > >> >> I wonder how it could be? > >> > > >> > More accurately, we could say that the solution is network-based. > PMIPv6 > >> > is just one network-based protocol and the solution is specified > in the > >> > draft for PMIPv6. Not sure what your doubt comes from... > >> > > >> > >> If it is network based then I don't understand why MN has a lot to > do > >> in your protocol as Wen has pointed out? > > > > AS stated in the draft, the solution is completely network-nased. The > MN > > is a legacy IPv6 node, has nothing to do in our protocol. > > > >> > >> > >> >> RFC 5213 in Section 7.1 says: > >> >> Once the address configuration is complete, the mobile node can > >> >> continue to use this address configuration as long as it is > attached > >> >> to the network that is in the scope of that Proxy Mobile IPv6 > domain. > >> >> > >> >> I wonder if MN moved out of PMIPv6 domain in your case? > >> > > >> > No, it has not. One of the common assumptions for DMM is that the > MN > >> > does not need address continuity for the whole duration the MN is > >> > attached to the domain. The idea is to enforce new communications > to > >> > make use of the address anchored closer to where the MN is > attached to, > >> > and to deprecate addresses anchored elsewhere (so they are not > needed > >> > once active communications using them are done). > >> > > >> > >> I guess what you understand from DMM is to put LMA functionality > into > >> MAG and lump the two together into one. That's why MN needs to get > an > >> address in the new MAG/LMA. And all other requirements coming out of > >> this huge change in PMIPv6. > >> > >> However, if you look into IETF work, in such cases MN needs to use > >> MIPv6 as in http://tools.ietf.org/html/draft-ietf-netlmm-mip- > interactions-07 > > > > I think I'm not following your rationale to jump from our draft to > the > > MN needing to use MIPv6. > > In your new draft draft-bernardos-dmm-distributed-anchoring-00, you > already admit that D-GW is a MAG and LMA combined. Actually it is also > very much like HA in draft-sarikaya-dmm-dmipv6-00. > > Because of the MN in Fig.1 configures PrefA (this one is normal PMIPv6) > and > > then again configures PrefB (and keeps using PrefA) which is where > the trick is. > > PMIPv6 is network-based and this is achieved with having two distinct > entities of MAG and LMA. Then you don't need much from MN in such an > architecture with such assumptions.
[JCZ] Agree > > However if you change these basic assumptions and have D-GW and make > it a single entity mobility protocol then you can not claim it is > network-based any more because it simply is not. > [JCZ] I think that Carlos refers to the fact that the changes are on the network side and we have not introduced any MN functionality. Hence, this is a network-based approach. > I think that there are similar concerns on draft-seite-dmm-dma-00 and > draft-liebsch-mext-dmm-nat-phl (I have not checked this one yet). > > What is interesting is that with D-GW becoming like HA, all these > protocols become very similar to the distributed MIPv6 protocol. [JCZ] Again, we are not introducing MN changes in the draft, so I don't think it maps to a client-MIP approach. Regards, Juan-Carlos > > Regards, > > Behcet > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
