Re: [MEXT] Comments on draft-ietf-monami6-multiplecoa-13

[Ryuji Wakikawa <ryuji.wakikawa at gmail.com>]

Hi Romain,

2009/5/12 Romain KUNTZ <kuntz at lsiit.u-strasbg.fr>:
> Hi Ryuji,
>
> On 2009/05/11, at 23:01, Ryuji Wakikawa wrote:
>>>
>>> My mistake, actually it does say something, in section 6.5 (Receiving
>>> Packets from Mobile Node):
>>>
>>>  When a node receives packets with a Home Address destination option
>>>  from a mobile node, it MUST check that the care-of address that
>>>  appears in the source address field of the IPv6 header MUST be equal
>>>  to one of the care-of addresses in the binding cache entry.  If no
>>>  binding is found, the packets MUST be discarded.  [...]
>>>
>>> But my comment on the efficiency (especially at the HA side) still holds,
>>> in addition to the other issue related to the RHT2.
>>
>> I have answered to this.
>>
>> This situation is only for the traffic between MN and HA. The same rule
>> apply to the traffic between MN and CN.
>
> Right, and I was especially concerned about the HA because it may have more
> MN to handle than a CN. I thought it could be a problem if there are lots of
> MNs-HA communications (but on the other hand, I can't think of an use-case
> where MN-HA communications would be frequent).

ok. From the MIP6 protocol, there is only protocol signaling exchange
between MN and HA.
As you said, there isn't use-case of MN-HA data communication.
We don't need to bother the data traffic between MN and HA.

>
> If you think it would not cause possible performance issues, I'll trust you
> on that.
>
>
>> The issue of RHT2 is not MCoA matter. It is solved by flow binding.
>
> Well, yes it could be solved by flow binding. I had in mind a case where
> only MCoA would be used. But I was already told here that everything related
> to flow distribution should be handled by some flow filtering mechanism, and
> not MCoA itself only, so I'll stop arguing on that.

OK

thanks,
ryuji

> Cheers,
> romain
>