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

Hi Arnaud and Julien,

On 2009/05/11, at 6:42, Julien Laganier wrote:

> On Monday 11 May 2009, Arnaud Ebalard wrote:
>> Hi Julien,
>>
>> Julien Laganier <julien.laganier.ietf@googlemail.com> writes:
>>> On Monday 11 May 2009, Arnaud Ebalard wrote:
>>>> I am not familiar with 3GPP architectures so following comment is
>>>> probably stupid: if the 3GPP access is bad compared to another
>>>> simultaneous access I have, why not just switch off the 3GPP link
>>>> in order not to use it and simply use the other access as a common
>>>> foreign network (configure a CoA, register it to the HA, ...) ?
>>>
>>> The 3GPP access may be worse than the WLAN in some aspects (e.g.
>>> bandwidth) but better in other aspects (e.g. latency, packet loss),
>>> thus it makes sense to allow to receive some traffic (say VoIP) on
>>> the home link (3GPP access) while diverting some other traffic (say
>>> bulk data transfer) on the foreign link (non-3GPP access, e.g. a
>>> WLAN).
>>
>> Well, that makes sense. Even if I don't like the solution in term of
>> complexity, I understand the motivation based on your argument and
>> the explanation from Christian. Thanks.
>>
>> Considering the example you give, maybe you have some comment (in the
>> context of MCoA) on the current inability for a MN that has a binding
>> with a CN  to tell that CN that it should route some flows to the HoA
>> of the MN instead of sending those to the CoA.
>
> Without my WG chair hat: Since route optimization is in my view a
> central piece of the MIPv6 design, I would consider that inability  
> as a
> flaw.

This isn't a flow.

In Mobile IPv6, when MN registers its binding to CN, MN cannot tell  
some flow is sent without RO.
It is same here in MCoA. For the binding management, we don't offer  
any solution for this.
This is more like flow handling matter which is out of scope in the  
MCoA.
You can use flow binding spec to direct some of flow to bypass the RO.

regards,
ryuji

>
>
> --julien
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext