Re: [DMM] regarding the re-chartering..

Alper Yegin <alper.yegin@yegin.org> Sat, 06 September 2014 10:04 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB471A0240 for <dmm@ietfa.amsl.com>; Sat, 6 Sep 2014 03:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qx2EDn1rCGDg for <dmm@ietfa.amsl.com>; Sat, 6 Sep 2014 03:04:14 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA8AF1A003A for <dmm@ietf.org>; Sat, 6 Sep 2014 03:04:13 -0700 (PDT)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0MDfbM-1XblJB0ZVm-00H4Lp; Sat, 06 Sep 2014 12:04:11 +0200
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <5409C782.6070807@gmail.com>
Date: Sat, 06 Sep 2014 13:04:05 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <BFD16BC9-0FF5-4B38-B8A9-53D917607FAD@yegin.org>
References: <53D17F75.3030207@gmail.com> <53D8AAE0.4040301@gmail.com> <2E9AF0DF-8B1A-475B-B5FB-ED5E419F0085@yegin.org> <53EB4F10.1040502@gmail.com> <A02C6954-3EC9-443F-ACC3-4A635EC79EFC@yegin.org> <53F35B44.1090808@gmail.com> <1E1DFA1F-8BC5-474B-A792-A8681A99D094@yegin.org> <72DAF3D2-05D9-4A1E-9185-7265AA915075@gmail.com> <CAC8QAcegx1QPATsrPS-v-dkoLbaSTNqE3M+BbrYJPHrCFKMyXA@mail.gmail.com> <5404BC3D.1000406@gmail.com> <CAC8QAccqjXHogC44iOBO5bDccFBRixgcgrQU=hst8ZYGM3Y5xA@mail.gmail.com> <5406A20F.60604@gmail.com> <CAC8QAccBSXSsydagekNHnBbaYvmtTdm=xv5aEE64c+=9X2Fp9w@mail.gmail.com> <5407422F.2010700@innovationslab.net> <CAC8QAcdvdY1Kbys4a=dw9aQ4cUs8cnRcnfaujxm1Fjn6_EAvkg@mail.gmail.com> <54074DAB.9020801@innovationslab.net> <CAC8QAcfVBeToUYYMp1uKTDwx8dGHw5TP2MTTSw8wziepcEZCsw@mail.gmail.com> <540763A0.7080509@innovationslab.net> <54083B6C.5010701@gmail.com> <F51A5BB8-0B0D-4F77-B354-A22B3171D8B9@yegin.org> <5409AD44.40308@gmail.com> <2C4B175F-425C-40A6-8CD1-432C193FC06C@yegin.o! rg> <54 09C782.6070807@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:ZOinomC353B/rZjfCcIuuHIMGrBFRzK5SXcQwiHZsSy P3Tu9VlaFEIJEhBubfrFgJY9ArPQo267CijFtB83zyU9Rqfqwy Z6Rf2vzoCfG4vUINIPgMQ+gxa3OGLfaGWaThfUAVSLlDN64CkY GJCMHA5iQeom3a34dGgHJNmgs61MpQz6Hk3aX8QS+T0G6SdkP9 VZ3JzpR7AwRSpVVPR7QfU0rPnTt4gEELXe+ShXg4c0TUqEZ9+o vrTeoXvtlFAoXKkFVeP5i+tHlqRMq+pAbYMwFBCkG1TceA+Cgc AHicQKB4J9toXTWy4iHz3QVkMgjrPLf8/6PwuMCyK5wvpj0AK+ uU76RyJQ771c1YMiYzEQbilANRFgDYa1gSuT2D7L5mBzP4qD4a xksOVuCPw64aw==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/MbVDYG7YQaHAqDw9xoILo0av2V8
Cc: dmm@ietf.org
Subject: Re: [DMM] regarding the re-chartering..
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Sep 2014 10:04:17 -0000

Alex,

>> 
>> The most robust way is to let the application tell the IP stack.
>> 
>> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-02.txt
> 
> Sounds reasonable.
> 
> A complimentary means is to look at this as a source address selection problem: given two addresses configured on an interface (an IP address, and an IP address designated as CoA), the application selects the src address as the IP address if its flows are brief query/response (http), or it selects the src address as the CoA if its flows are longer timed (request of UDP stream, or TCP download).
> 

That's exactly the intention and the approach. 


> This would need a means to designate to the stack an IP address as to be a 'CoA', or otherwise designate a prefix to be the 'home' prefix and, by deduction any address differing be the CoA.
> 

At a high-level, yes. If you've read the draft you'll see there are some details and extensions on top of that (such as it's not a simply matter of CoA vs HoA, but there are in fact 3 types of IP addresses, and also a required type IP address can be configured on-demand when needed).

Alper


> Alex
> 
>> 
>> Alper
>> 
>> 
>> 
>>> Alex
>>> 
>>> 
>>> 
>>>> 
>>>> Alper
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:
>>>> 
>>>>> Le 03/09/2014 20:53, Brian Haberman a écrit :
>>>>>> Behcet,
>>>>>> 
>>>>>> On 9/3/14 2:33 PM, Behcet Sarikaya wrote:
>>>>>>> 
>>>>>>> You don't seem to understand my points.
>>>>>> 
>>>>>> That is quite possible.  Your comment on the list was "I am
>>>>>> against any deployment work before we decide on a
>>>>>> solution..."
>>>>>> 
>>>>>> I read that as an objection to having the deployment models
>>>>>> work item on the agenda.  Please do tell me what I am
>>>>>> missing.
>>>>>> 
>>>>>> Regards, Brian
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I am following the discussion and me too I do not quite
>>>>> understand what is the complain.
>>>>> 
>>>>> I am happy to learn that a if a WG is to be formed then it
>>>>> would be around a solution rather than just requirements or
>>>>> architecture.
>>>>> 
>>>>> That said, I would like to express a worry along similar
>>>>> lines.
>>>>> 
>>>>> In DMM, precedents and the keen NETEXT, there seems to be a
>>>>> hard-rooted disconnect between the product developped -
>>>>> (P)Mobile IP - and the deployments.  We know for a fact that
>>>>> 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP.  We also
>>>>> know that 3GPP specs do mention Mobile IP. To such a point that
>>>>> I wonder whether 3GPP has not the same disconnect as here.
>>>>> 
>>>>> On another hand, we do have indications of where (P)Mobile IP
>>>>> is used - the trials, the projects, the kernel code, and not
>>>>> least the slideware attracting real customers.
>>>>> 
>>>>> The worry: develop DMM protocol while continuing the
>>>>> disconnect.
>>>>> 
>>>>> Alex
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ dmm mailing
>>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________ dmm mailing
>>>>> list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
>