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. 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. 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. Regards, Behcet _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
