Re: [Seamoby] IP Paging ]Framework discussion

Behcet Sarikaya <behcet.sarikaya@alcatel.com> Wed, 02 January 2002 21:07 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10845 for <seamoby-archive@odin.ietf.org>; Wed, 2 Jan 2002 16:07:52 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21360; Wed, 2 Jan 2002 15:55:26 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21334 for <seamoby@ns.ietf.org>; Wed, 2 Jan 2002 15:55:23 -0500 (EST)
Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10659 for <seamoby@ietf.org>; Wed, 2 Jan 2002 15:55:19 -0500 (EST)
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA19911; Wed, 2 Jan 2002 14:54:52 -0600 (CST)
Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g02Ksqm15515; Wed, 2 Jan 2002 14:54:52 -0600 (CST)
Message-ID: <3C337390.4000109@alcatel.com>
Date: Wed, 02 Jan 2002 14:54:40 -0600
From: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Organization: Alcatel USA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: James Kempf <kempf@docomolabs-usa.com>
CC: seamoby@ietf.org
Subject: Re: [Seamoby] IP Paging ]Framework discussion
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF>
Content-Type: multipart/alternative; boundary="------------030300030305030501040403"
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

Hi Jim,


James Kempf wrote:

>>  You seem to ignore the LAHAP draft always, why? (I think
>>the answer is implicit in your other mail, parts of it I am copying
>>
>here)
>
>No evil intent, it was strictly a matter of oversight.
>
Therefore the assessment process is moot, sorry for coming back to this 
conclusion again. I think that this will be more evident when the 
meeting slides are ever posted with the mnutes, I had specifically asked 
during the meeting if there are any slides on LAHAP draft and you said no.

>
>
>One of the uses of IP paging for seamless mobility is the ability
>to abstract across a variety of different L2 paging protocols.
>Suppose a device has five wireless interfaces, three of
>which define L2 paging protocols specific to their
>particular medium. In this case, confining the L2
>paging information to the AR would simplify
>management of paging within the network. L3
>paging areas could be used to abstract across
>various L2 paging protocols, in the same way
>that an IP subnet abstracts across a different
>L2 link. In this case, I think there is an advantage
>to having L3 paging areas even if there is
>already L2 support.
>
>                        jak
>
You seem to refer to Yoshi"s mail on orthogonality and also assume that 
L2 paging areas always exist. Orthogonality or L2 paging area 
configuration regardless of IP subnet structure can only happen in 2G 
voice-based cellular networks where the mobile is searched with its link 
address, e.g. IMSI. In 2.5G and 3G cellular networks IP communication is 
of prime concern.  L2 paging areas regardless of IP subnet configuration 
when  the mobile has to be searched with its IP address seems a wrong 
approach to me, its only justification could be to reuse old paging 
areas already configured for 2G networks. Also I don't think IP Paging 
protocol could go into so much to link-related issues.
  Secondly L2 paging areas exist only on cellular network links and not 
of a given to any link.In where it exists (GPRS, 3GPP),  would they be 
interested in  IETF's IP Paging protocol is a big question mark, IMHO.

  Regarding renker draft, firstly renker-00 draft was based on MIPv6 and 
it was home agent based paging. Jim mentioned in one of his previous 
emails the disadvantageous of HA based paging. Now, renker-01 draft is a 
mess as Marco admits, and its architecture is based on lumping 
everything together, which means, the authors do not know what to do 
with each architectural entity, so lets combine them. I also agree with 
Yoshi on the marks given by the assessment team correctly marked it low.

 Regards,

-- 
Behcet