Re: [Seamoby] IP Paging ]Framework discussion

"James Kempf" <kempf@docomolabs-usa.com> Wed, 02 January 2002 21:51 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 QAA11666 for <seamoby-archive@odin.ietf.org>; Wed, 2 Jan 2002 16:51:20 -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 QAA23039; Wed, 2 Jan 2002 16:34:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23008 for <seamoby@ns.ietf.org>; Wed, 2 Jan 2002 16:34:54 -0500 (EST)
Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11219 for <seamoby@ietf.org>; Wed, 2 Jan 2002 16:34:50 -0500 (EST)
Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g02LYMS27530; Wed, 2 Jan 2002 13:34:22 -0800 (PST)
Message-ID: <01fe01c193d5$04e33200$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Behcet Sarikaya <behcet.sarikaya@alcatel.com>
Cc: seamoby@ietf.org
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Wed, 02 Jan 2002 13:32:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit

Behcet,

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

I do not understand your point. If you believe there is something in
the LAHAP draft that can add to the protocol design, then
by all means post it, or send it to Marco. If you don't,
then don't. I don't understand what that does or doesn't
have to do with the protocol assessment. I don't
know how many time I need to say this.

> You seem to refer to Yoshi"s mail on orthogonality and also assume
that
> L2 paging areas always exist.

No, I don't. L2 paging areas may or may not exist. The L3
paging design needs to accommodate both, according to
the requirements.

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

I'm sorry, I don't understand where you are coming from here. If one
defines a L3 paging area independently of the L2 paging area,
what difference does it make what the L2 identifier is? One
can define an abstraction to use.

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

Which IP address? If it's MIP, then there are two. I don't think it
is possible to use the IP address of the MN to page, since one
use of dormant mode is to remove the need to maintain
routes.

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

Sure, that's why it is important to design an appropriate abstraction
for L2 paging identifiers.

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

Well, I don't think existing cellular networks would be all that
interested,
frankly. They have Location Area Identifiers and updates for them
that are based on a paging area to subnet mapping. One of the
goals of the IP paging design is to move to an independent design.

>   Regarding renker draft, firstly renker-00 draft was based on MIPv6
and
> it was home agent based paging.

There were two cases, one with and one without MIPv6. The
requirements say that the protocol must be independent
of mobility protocol  but support existing mobility protocols.
It is up to the working group discussion as to
how to modify draft-renker to do this. Please
state your opinion if you have one.

>Jim mentioned in one of his previous
> emails the disadvantageous of HA based paging. Now, renker-01 draft is
a
> mess as Marco admits,

This is an inaccurate characterization of Marco's email. It was not any
more "a mess" then any of the other drafts. It needs cleaning up
w.r.t. holes and overspecifications.

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

Behcet, instead of posting these negative generalizations of the
assessment
process, the selected draft, etc., I wish you would move on and
try to contribute something positive to actually defining the
protocol. As I've said, I think your team's contributions in
the area of time-slotted paging and L2 paging interface
were good, and your team's experience in this area would
be useful for the end result.

Rough concensus doesn't mean everybody agrees, it means
that almost everyone does. My reading of the list traffic
and the meeting is that we've got rough concensus
on starting the process of harmonizing the designs
based on draft-renker. Let's move on.

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby