[Netext] Scope of proposed work

Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com) Thu, 09 April 2009 04:05 UTC

From: "Basavaraj.Patil at nokia.com"
Date: Thu, 09 Apr 2009 06:05:11 +0200
Subject: [Netext] Scope of proposed work
In-Reply-To: <C6036A4A.C99B%hesham@elevatemobile.com>
Message-ID: <C602DE27.265E5%basavaraj.patil@nokia.com>

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?

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.

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.

-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
> 
>