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

[Ryuji Wakikawa <[e-mail]>]

Hi Arnaud,


2009/5/12 Arnaud Ebalard <[e-mail]>:
> Hi Ryuji,
>
> Ryuji Wakikawa <[e-mail]> writes:
>
>>>> 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.
>
> That's correct but MIPv6 was restricted to a single binding and route
> for communications bewteen MN-HA and MN-CN. Because MCoA removes that
> restriction, I don't see your point about citing a missing feature of
> MIPv6 as an argument not to have it in MCoA. IMHO, MCoA is the place
> where all the possible destination should be handled, including the
> HoA.
>
>> It is same here in MCoA. For the binding management, we don't offer
>> any solution for this.
>
> From my perspective, MCoA *is* about binding management.

>From the protocol point of view, we have two choices here.
- having special binding for the HoA destination
- having flow management to skip RO

Since RO is not so important at this point, we should go with the
minimal spec which mean the second option.
You can put all the possible features in the MCoA, but the draft is
not discussed in that direction at this stage.
We can always revisit the spec once we "really need" such extension.


>> This is more like flow handling matter which is out of scope in the
>> MCoA.
>
> The thing is that at the moment the MCoA draft is the one providing
> information about the address to which the traffic is expected to go
> (via the content of the BID). If you cannot express the direction is the

Before the binding, we need to have additional mechanism to the
binding selection.

> HoA with what is in the draft, next documents will have to modify the
> semantic of the BID, instead of simply use it. Or do I fail to
> understand how you want that to be handled?

We shouldn't change the semantics of BID for this.
We can't modify the spec after completing WG/IETF/IESG LC, but we only
accept minor changes for clarification and editorial errors.
Otherwise, we will get into endless cycles.

Anyway, IMO, your feature can be achieved with the current MCoA spec
with flow binding.

regards,
ryuji

>> You can use flow binding spec to direct some of flow to bypass the RO.
>
> See above.
>
> Cheers,
>
> a+
>
>