Re: [Seamoby] IP Paging ]Framework discussion

"James Kempf" <kempf@docomolabs-usa.com> Wed, 09 January 2002 19:55 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 OAA13897 for <seamoby-archive@odin.ietf.org>; Wed, 9 Jan 2002 14:55:31 -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 OAA17560; Wed, 9 Jan 2002 14:39:57 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17531 for <seamoby@optimus.ietf.org>; Wed, 9 Jan 2002 14:39:55 -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 OAA13574 for <seamoby@ietf.org>; Wed, 9 Jan 2002 14:39:51 -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 g09JdKS18441; Wed, 9 Jan 2002 11:39:20 -0800 (PST)
Message-ID: <022201c19945$1bb9d040$7e6015ac@T23KEMPF>
From: James Kempf <kempf@docomolabs-usa.com>
To: Behcet Sarikaya <behcet.sarikaya@alcatel.com>, seamoby@ietf.org
References: <3C335823.5030009@alcatel.com> <016f01c193c7$0ae59e80$7e6015ac@T23KEMPF> <3C337390.4000109@alcatel.com> <3C3C2C8B.47776F0C@ccrle.nec.de> <017901c19930$56eda7a0$7e6015ac@T23KEMPF> <3C3C7CAB.1090909@alcatel.com>
Subject: Re: [Seamoby] IP Paging ]Framework discussion
Date: Wed, 09 Jan 2002 11:37:43 -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,

Marco sent you a private email, and I replied privately because the
email was private.
Not everything needs to get said in public.

But, if you insist, I'll repeat the message here. I'd appreciate if we
could
stop arguing about who said what and get down to working on the
protocol.

            jak

----- Original Message -----
From: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
To: <seamoby@ietf.org>
Sent: Wednesday, January 09, 2002 9:23 AM
Subject: Re: [Seamoby] IP Paging ]Framework discussion


> This is a strange trend to keep the discussion away from the WG list?
> I just checked, RFC 3154 which included everybody who was involved
> somehow on the requirements document did NOT contain Marco's name.
> Maybe another source of confusion.
>
>   Pls post any discussion on the mailing list.
>   BTW it seems that there seems to be no archive kept for Seamoby ML.
I
> may be wrong, please negate me.
>   I hope the ADs are reading the mails.
>
> Regards,
>
>
> James Kempf wrote:
>
> >Guys,
> >
> >Let's stop arguing about whose proposal is what and concentrate on
> >getting started doing the protocol, OK?
> >Behcet is entitled to his opinion, Pat and I clearly didn't share it.
> >
> >            jak
> >
> >----- Original Message -----
> >From: "Marco Liebsch" <Marco.Liebsch@ccrle.nec.de>
> >To: "Behcet Sarikaya" <behcet.sarikaya@alcatel.com>
> >Cc: "James Kempf" <kempf@docomolabs-usa.com>; "Ralf Schmitz"
> ><Ralf.Schmitz@ccrle.nec.de>
> >Sent: Wednesday, January 09, 2002 3:42 AM
> >Subject: Re: [Seamoby] IP Paging ]Framework discussion
> >
> >
> >>First: Happy new year.
> >>
> >>Furthermore:
> >>
> >>Behcet,
> >>
> >>as we talked in Salt Lake about several paging issues, you told me,
> >>
> >that
> >
> >>you did not read our concept proposal I-D, but you tried to
'convince
> >>me' that our proposal is MIP/HA based and specific. This is not
true,
> >>
> >as
> >
> >>I tried to explain you in Salt Lake already. The concept is
> >>
> >independent
> >
> >>of the mobility platform, but explains how to integrate the paging
> >>concept into a MIPv6 platform 'as an example' and proposes some
paging
> >>related optimization for MIPv6 as an option. The second draft is not
a
> >>mess in my opinion, therefore, why should I 'admit' anything like
> >>
> >this?
> >
> >>Therefore, please read the draft thoroughly before giving such a
> >>statement. For your info, the first seamoby draft on paging will
have
> >>the MIPv6 related optimizations proposed in he Annex, as already
> >>
> >written
> >
> >>on the list.
> >>
> >>
> >>Regards,
> >>
> >>marco.
> >>
> >>
> >>Behcet Sarikaya wrote:
> >>
> >>>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
> >>>
> >>>
> >>
> >>
> >
>
> --
> Behcet
>
>
>


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