Re: [netext] Consensus call: Adopt I-D draft-bernardos-netext-pmipv6-flowmob-03 as Netext WG doc?

[<[e-mail]>]

Hi Julien,

On 8/12/11 2:03 PM, "ext Julien Laganier" <[e-mail]> wrote:

>Raj,
>
>
>
>On Fri, Aug 12, 2011 at 11:13 AM,  <[e-mail]> wrote:
>>
>> Hi Julien,
>>
>> On 8/12/11 12:55 PM, "ext Julien Laganier" <[e-mail]>
>>wrote:
>>
>>>Hello Raj,
>>>
>>>While parts of this document are reasonable extensions to the PMIPv6
>>>protocol, I have indicated repeatedly that I had a fundamental issue
>>>with the other part of the document that lets the LMA unilaterally
>>>decides to move flows.
>>
>> I don¹t believe there is this fundamental issue that (you mention) is a
>> show-stopper in the case of flow mobility for PMIP6. My recollection
>>from
>> previous discussions is that the LMA makes the decision to move a flow
>> based on some policy which is either locally configured or obtains from
>>an
>> external entity. You may disagree with that approach. We can discuss
>>this
>> issue further and ensure that it is either fairly resolved through the
>> tracker.
>> My suggestion would be for you to write up this issue and upload it to
>>the
>> tracker and we will resolve it to the satisfaction of the WG members.
>
>Are you assessing the issue I described as not fundamental in your
>function of  WG chair?

As WG member.

>
>The "approach" of resolving the issue by making it someone else
>problems does not address the fundamental issue that if one of the
>MN's radio access isn' t working properly, having the LMA unilaterraly
>direct a flow there will harm the MN ability to communicate without a
>mean for the MN to recover.

Thanks for refreshing my memory on this issue.
So yes, as you have mentioned before this is an issue. The LMA redirecting
a flow to an IF/MAG at which the MN may not be reachable (anymore) will
result in packets going into the void.

The consequence of such a scenario is pretty drastic in terms of user
experience and failure of communication.
An application may be able to recover if it has its own means. But that is
beyond the scope of the layer at which we are working on in this WG.
There has been mention of several possible solutions including a layer 2
based approach wherein the MN could indicate via its active IF that
another IF via which it was connected to MAGx and a flow was being
received has terminated. I know that solutions at L2 are out-of-scope and
such mechanisms have to be created in the relevant SDOs that specify
PHY/MACs. 
My point is that the I-D could highlight the issue and note the
consequence and severity of the problem which can serve as sufficient
warning to anyone who would consider deploying the protocol.
And that could be one way of dealing with the issue.
 
>
>So yes I disagree.
>
>I have written the issue down on this mailing list many, many times, I
>have discussed  it many, many times, and the issue was never addressed
>adequately.

Agree. It has been discussed at length. Several solutions have also been
discussed but maybe none that you are convinced of.

>
>Your denial that this this fundamental also does not hint at how
>further discussions can possibly resolve that issue. And keeping this
>controversial feature in the draft ensure that the basis on which we
>discuss is un-agreeable to a number of people in this group, and is
>fundamentally broken. Not a very good starting point IMHO.

It is a fundamental issue... Given that the MN has no way to indicate if
another IF via which it was connected has gone down at L3. Lets see if
folks have a good solution that they can come up with.

-Raj

>
>--julien