[Netext] Scope of proposed work

tsirtsis at googlemail.com (George Tsirtsis) Thu, 09 April 2009 09:08 UTC

From: "tsirtsis at googlemail.com"
Date: Thu, 09 Apr 2009 10:08:58 +0100
Subject: [Netext] Scope of proposed work
In-Reply-To: <C603B4CC.C9AD%hesham@elevatemobile.com>
References: <C602DE27.265E5%basavaraj.patil@nokia.com> <C603B4CC.C9AD%hesham@elevatemobile.com>
Message-ID: <d3886a520904090208qd84cb78l8257ca43f834e58@mail.gmail.com>

Hesham, thanks for this e-mail.

It is exactly what a number of people have been calling for, first
during the BOF, and since then on the list.
Part of the problem in this discussion has been that people are
selective to the "technical argument" they want to hear.

Hesham below (and others before him)  ask for technical justification
of why the work needs to be done.
Others have been demanding that we accept the need to do this as a
given and discuss the solutions directly.

These are both technical discussions and we need the first before we
get into the second.

Regards
George


On Thu, Apr 9, 2009 at 4:21 AM, Hesham Soliman <hesham at elevatemobile.com> wrote:
> Hi Raj,
>
> Thank you for responding to my question! I'm glad someone is listening.
>
>
> On 9/04/09 3:05 PM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
> wrote:
>
>>
>> Hi Hesham,
>>
>> I have seen you asking for a problem statement in several emails now and
>> none has been forthcoming so far. So let me try to understand your view:
>>
>> Netext proposes to extend PMIP6 to support flow mobility, address several
>> multihoming scenarios and, support intertechnology handovers.
>>
>> Are you asking why we need to work on these features for PMIP6? Obviously
>> from the perspective of protocols specified in the IETF, we do recognize
>> that multihoming, flow mobility and intertechnology handovers can be
>> provided by Mobile IPv6. So are you of the opinion that given the
>> availability of a solution in the IETF for these problems there is no need
>> to work on these?
>
> => No. Here is what I think in the abstract and how it applies to this
> particular case. A problem statement should explain the problem, discuss the
> state of the art, then show why the state of the art doesn't solve the
> problem. Based on this, one can conclude one of two things:
> 1. We need to modify the state of the art to solve the problem, or,
> 2. We need something new because modifying the above is not going to work
> (for many possible reasons).
>
> The choice between 1) and 2) obviously involves a solution space discussion
> once the problem is defined.
> For this BoF, this means:
> - Define the problem: a host needs to to able to send/receive packets on
> multiple interfaces ....etc, deployment issues, ....etc
> - Explain why the state of the art is not sufficient: PMIP doesn't solve
> this because..., MIP doesn't solve this because ... Something else....etc
>
> Then we can see real reasons for deciding to go one way or another. Of
> course what happened so far is that people essentially say one of three
> things:
> A. PMIP doesn't solve this so we need something (completely ignoring MIP),
> or,
> B. MIP solves this but there must be more than one way of doing it, or,
> C. There is an unofficial, unstated requirement from SDOs that we must
> fullfil without discussion.
>
> A) is obviously incomplete, B) is utter nonsense and C) is dangerous.
>
>>
>> If the question is about what is the problem w.r.t multihoming in the case
>> of PMIP6 and respectively other features as well, please do review the PS
>> I-Ds ( draft-jeyatharan-netext-multihoming-ps-01,
>> draft-krishnan-netext-intertech-ps-00). If these fall short of explaining
>> what is the problem, then we need to do a better job.
>
> => As I said before draft-krishnan and Suresh's presentation in the BoF
> effectively say "don't do that". draft-jeyatharan falls under A) above. The
> problem with A) above is that PMIP was never designed to solve this problem.
> According to the NETLMM PS, and James Kempf's comments (and the NETLMM
> charter), this problem was supposed to be solved by MIPv6. So, to write a PS
> saying PMIP doesn't solve the problem is a rhetorical ps.
>
>>
>> Let me also say that justifications for creating a WG is not the main
>> driver. Far from it... I do agree that the IETF should charter work which is
>> useful and hence am hoping that through this discussion we will able to get
>> a better grasp on this set of topics over which there is a disagreement.
>> Rajeev also mentioned earlier that the intent is not to achieve parity in
>> terms of features supported by PMIP6.
>>
>> It would be useful to understand your PoV (might be challenging given the
>> CINR) as to why you believe there is no real PS.
>
> => I hope this helps. I'm happy to discuss these issues on the list because
> they're relevant. I don't think it's useful to discuss other "howto" threads
> so I'll stay away from them.
>
> Hesham
>
>>
>> -Raj
>>
>> On 4/8/09 5:03 PM, "ext Hesham Soliman" <hesham at elevatemobile.com> wrote:
>>
>>> Hi Raj,
>>>
>>>
>>> On 9/04/09 7:29 AM, "Basavaraj.Patil at nokia.com" <Basavaraj.Patil at nokia.com>
>>> wrote:
>>>
>>>>
>>>> Hello,
>>>>
>>>> There is an issue in the current debate that we should put to rest.
>>>> Netext proposes to extend PMIP6 to support multihoming, flow mobility
>>>> and inter-technology handovers (in addition to others over which there is
>>>> an agreement on).
>>>>
>>>> It is recognized that host based Mobile IP (RFC3775) and DSMIP6 has
>>>> these capabilities currently. I dont think there is any debate about
>>>> that.
>>>> However there is an interested group of people within the IETF
>>>> community who would like to extend PMIP6 to support these features as
>>>> well.
>>>
>>> => Ok but without a PS, without justification, nothing? I mean if that's the
>>> case why have a BoF? Everyone keeps talking about the market needs. If this
>>> is the only reason for having these functions then we may as well send a
>>> business plan to Jari instead of having a BoF :). Market needs usually tell
>>> us the problem that needs to be solved, not *how* to solve it.
>>>
>>>> It is not uncommon in the IETF to have multiple competing protocols
>>>> provide similar functionality. The industry will ultimately choose an
>>>> appropriate solution depending on the needs. So I dont think we can
>>>> just quash the idea of working on these extensions simply because we
>>>> already have a protocol that does it.
>>>> It is also noted that one of the primary reasons for developing PMIP6
>>>> was to provide mobility without host involvement.
>>>
>>> => Yes but least for netlmm there was a PS and *some* technical arguments.
>>> Mostly bogus IMO but at least they took place. Here everyone is singing in
>>> concert about how to solve things and completely refusing to say why.
>>> Actually some people explicitly said that on the list.
>>>
>>> It's sad that this level of discussion is taking place to justify a WG.
>>> Remember the discussions you had to manage for PANA or other WGs you
>>> chaired? Very different. I think it's good that you're encouraging people to
>>> discuss the technical problems, and it's good that they're agreeing, but
>>> unfortunately it's not happening. That should tell us something...
>>>
>>> Hesham
>>>
>>>
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>