Re: [netext] Update on flow mobility following discussion with ADs

[Julien Laganier <[e-mail]>]

Hi Rajeev,

On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <[e-mail]> wrote:
>
>
> On 3/2/11 11:49 AM, "Jari Arkko" <[e-mail]> wrote:
>
>> Sri:
>>
>> What Basavaraj said. I don't think the number of specifications is a big
>> concern either now or later. Split the documents the way you like. Lets
>> discuss functionality, robustness, assumptions instead -- those are
>> important.
>
>
> I agree that the spec should be robust, and should work under conditions
> assuming existing & new L2 signaling, as well as under conditions when new
> L2 signaling is unavailable.

I have expressed doubts about the feasibility of a robust flow
mobility / inter-access handover solution that relies on existing,
unmodified L2 signaling (this is discussed in a different thread.) We
should not sacrifice correctness and robustness for the sake of
working around unmodified L2 signaling. As I've said earlier, one of
the potential customer for this (3GPP) owns two L2 that are used to
access their system (PMIP based S5 for 3GPP accesses, and PMIP based
S2b for no-3GPP accesses.)

> It's a question of whether we agree that LMA-MAG signaling could also be
> used in addition to relying only on L2 signaling for flow mobility.

At this stage the question is rather, is it possible to provide a
correct and robust system without modified L2 signaling. If it is,
then we can go ahead with the question you laid above. Would you
agree?

>> (And of course, splitting to different specifications should not be
>> misused to hide a technical omission or a problem.)
>
> I would focus on getting a protocol that works under different cases and not
> just under continued reliance on (existing and new) L2 signaling. (I am not
> referring to new IP signaling between MN and MAG).

See above. The focus you propose is only appropriate insofar we've
come up with a positive answer to the question I asked above, and that
we' re discussing with Carlos, Hesham, et al.

--julien