Re: [MEXT] Some questions on draft-sarikaya-mext-multicastdmm

Hi Romain,
Sorry for my late reply.




> Hello Behcet, 
> 
> Comments inline:
> 
> On Jul 23, 2011, at 9:36, Behcet Sarikaya wrote:
>>>  I'm currently updating draft-kuntz-dmm-summary and was  considering 
> including 
>>>  draft-sarikaya-mext-multicastdmm. However I have a few  questions about 
> your 
>>>  draft.
>>> 
>>>  To me it seems that your proposal is not a  DMM solution by itself but 
> is built 
>>>  upon draft-kassi-mobileip-dmi. Am I right?  Is the exact motivation of 
> your 
>>>  proposal to support multicast on the mobile node  when DMI is used?
>>> 
>> 
>>  My draft is intended to be a candidate for Mext WG charter item on dmm and 
> it is 
>>  inline with the discussions we had in the last Mext session on dmm, I 
> don't 
>>  remember where, was it Beijing, IETF 79?
>>  .
>>  If you are saying that  cellular network application is emphasized, yes, I 
> think 
>>  that cellular networks are of course the place where we should look for 
>>  deployment possibilities.
> 
> I'm not sure what made you think I was talking about cellular network 
> application? That was not my intent. 
> I was stating that if we remove the multicast part, the underlying DMM solution 
> exposed in your draft seems to be very similar to DMI (draft-kassi-mobileip-dmi) 
> and was wondering if there were any differences that I failed to see.
> 
>>  I think multicast support is important and so far no other draft talks 
> about 
>>  multicast. That's why multicast is covered in my draft.
> 
> Ok.
> 
>>>  About the solution itself:
>>> 
>>>  * Section 3: 
>>> 
>>>   "MN starts to receive the packets over HA-MN link from
>>>     CN and MN starts to send packets with a destination option 
> containing
>>>     the previous Care-of Address as MN's Home Address (HoA) to the 
> CN."
>>> 
>>>  I'm  not sure why you are doing this? This sounds like route 
> optimization to  
>>>  me.
>>> 
>> 
>>  Why not? This is the behaviour MN should have because HA keeps changing, 
> right?
> 
> In section 5 you are stating "This protocol removes the need for route 
> optimization.  Correspondent nodes do not need to maintain a binding cache of 
> bindings for other  nodes.", so this does not sound coherent with the MN 
> behavior exposed above. 
> 


RFC 6275 says destination option is used in a packet
   sent by a mobile node while away from home, to inform the recipient
   of the mobile node's home address.
So we need it. I will clarify no route optimization statement, which means that there is no need 

 1 Home Test Init

      2  Care-of Test Init

      3  Home Test

      4  Care-of Test
message exchanges.

Regards,

Behcet