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

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 12 Aug 2011 14:54:27 -0700 (PDT)

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 12 Aug 2011 15:05:25 -0700 (PDT)

Hi Romain,
Sorry for my late reply.

 1 Home Test Init

      2  Care-of Test Init

      3  Home Test

      4  Care-of Test
message exchanges.

Regards,

Behcet

---

From: Romain KUNTZ <[email-masked]>
Date: Fri, 12 Aug 2011 17:28:18 -0700

Hello Behcet,

> So we need it. I will clarify no route optimization statement, which means that there is no need 

If I remember correctly, RFC6275 requires the CN to have a binding cache entry to process destination options from the MN, which requires the return routability procedure. 

romain

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Aug 2011 08:11:17 -0700 (PDT)

Hi Romain,

> If I remember correctly, RFC6275 requires the CN to have a binding cache entry 
> to process destination options from the MN, which requires the return 
> routability procedure. 
> 

As it says in RFC 6275 the destination option is needed to inform the recipient
of the mobile node's home address

This is the functionality that is needed for dmm. There is no need for return routability procedure.
That means dmm can not work with an unmodified CN, which is the most important impact.

Regards,

Behcet

---

From: Romain KUNTZ <[email-masked]>
Date: Mon, 15 Aug 2011 18:17:31 -0700

Hi Behcet, 

> That means dmm can not work with an unmodified CN, which is the most important impact.

I'm not sure you get my point: it is a security breach to use the destination option with a CN without having a proper binding registration & return routability procedure.

Regards,
Romain

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Aug 2011 11:53:16 -0700 (PDT)

Hi Romain, all,

> I'm not sure you get my point: it is a security breach to use the 
> destination option with a CN without having a proper binding registration & 
> return routability procedure.
> 

Yes, you are right.
Sorry
 for my misunderstanding, I was mislead by Sec. 6.3 in RFC 6275 which 
did not clearly state that home address destination option is only 
required for route optimized packets.

draft-sarikaya-mext-multicastdmm-03.txt

clarifies it, I hope.

Regards,

Behcet