Re: [MEXT] the future of the MEXT working group

"Charles E. Perkins" <charles.perkins@earthlink.net> Fri, 04 November 2011 17:31 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: mext@ietfa.amsl.com
Delivered-To: mext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAD321F8A97 for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 10:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.434
X-Spam-Level:
X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4vKVPKuy+kU for <mext@ietfa.amsl.com>; Fri, 4 Nov 2011 10:31:46 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E876221F8A71 for <mext@ietf.org>; Fri, 4 Nov 2011 10:31:45 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=N8E8cYZ69ZZeEVwQNf/gzsv7DLq+FRNwZBylWE78r/cLOaZ1rEvISM9R+KjUIYQ9; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [138.111.58.2] (helo=[172.17.96.136]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1RMNcE-0000Uo-WA; Fri, 04 Nov 2011 13:31:43 -0400
Message-ID: <4EB4217A.8040109@earthlink.net>
Date: Fri, 04 Nov 2011 10:31:38 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: jouni korhonen <jouni.nospam@gmail.com>
References: <4EAA9B4A.3020208@piuha.net> <4EAA9E34.2080903@piuha.net> <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com>
In-Reply-To: <1B31D76B-4C76-4351-B270-437D4560007C@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad866f7ad810b1c8adc933d4ae9af7a27d3d350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 138.111.58.2
Cc: mext@ietf.org
Subject: Re: [MEXT] the future of the MEXT working group
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 17:31:46 -0000

Hello Jouni,

Comments inline:

On 11/3/2011 5:21 PM, jouni korhonen wrote:

> Few quick comments. I would remove all explicit references to 3GPP and
> existing offload mechanisms therein. FWIW this WG is not supposed to
> be a stub of SA2. The possible (protocol) enhancement must be generic
> enough to be applicable outside of a specific deployment architecture.

I agree 100%.  I use 3GPP as an example.  However, it is a likely
bet that a huge fraction of the mobile devices in the future will
implement wireless connectivity specified by 3GPP and depend upon
network backhaul specified by 3GPP, so it is pretty relevant
to consider the design needs specifically of 3GPP -- if nothing
else, then at least as a reality check.


> Also, I think we ought not only consider just mobility enhancement.
> More efficient use of CoA(s) for direct/local/non-tunneled communication
> along with existing mobility solutions should be in scope as well.


Again, agree 100%.  However, we might eventually determine that the
methods for efficient use of CoA(s) are somewhat different than the
methods for enabling IP address continuity and smooth handover.
I wonder whether the two different technologies would even belong
in the same working group.

Before enabling a mechanism to select a CoA, we need some way
for classifying the "characteristics" of an IP address as bound
to a specific radio interface and Internet PoA.  To me, it's not
at all obvious that such a problem is "like" the other problems
of interest within the Internet Area.

Regards,
Charlie P.