Hi Raj,

In your message below you agree that this is a fundamental issue of
which consequences are "pretty drastic in terms of user experience and
failure of communication". Working within the Internet layer, placing
an application in a situation in which it fails without being able to
recover constitutes a blatant lack of protocol correctness. Since you
also acknowledge that so far no good solution to this has been put
forth, it is only logic to not include the offending feature in the
draft to be adopted by the WG, so that we can build upon a correct
baseline.

I will be more than happy to see the draft extended with a mechanism
that provides the feature at stake when it is shown to exhibit
correctness at the Internet layer.

--julien



2011/8/12  <Basavaraj.Patil@nokia.com>:
> Hi Julien,
>
> On 8/12/11 2:03 PM, "ext Julien Laganier" <julien.ietf@gmail.com> wrote:
>
>>Raj,
>>
>>
>>
>>On Fri, Aug 12, 2011 at 11:13 AM,  <Basavaraj.Patil@nokia.com> wrote:
>>>
>>> Hi Julien,
>>>
>>> On 8/12/11 12:55 PM, "ext Julien Laganier" <julien.ietf@gmail.com>
>>>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
>
>