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
- [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion David Frascone
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion Behcet Sarikaya
- Re: [Seamoby] IP Paging ]Framework discussion James Kempf
- Re: [Seamoby] IP Paging ]Framework discussion Marcus Brunner
- Re: [Seamoby] IP Paging ]Framework discussion Scott Bradner
- Re: [Seamoby] IP Paging ]Framework discussion Scott Bradner