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

[Romain KUNTZ <[e-mail]>]

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. 

>> * Section 6: 
>> 
>>  "Multicast state for the mobile node is  usually established when
>>   mobile node was on the link and the state in  Multicast State mobility
>>   option normally must match this state and  the multicast state sent by
>>   the mobile node becomes the multicast  state of the mobile node when
>>   communicating over MN-HA  tunnel."
> 
> OK, let me clarify this in the next version.

Thanks,
romain