RE: [Seamoby] CAR Discovery Requirements

John Schnizlein <jschnizl@cisco.com> Mon, 14 January 2002 17:59 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 MAA09867 for <seamoby-archive@odin.ietf.org>; Mon, 14 Jan 2002 12:59:32 -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 MAA16336; Mon, 14 Jan 2002 12:43:11 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16306 for <seamoby@optimus.ietf.org>; Mon, 14 Jan 2002 12:43:09 -0500 (EST)
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08995 for <seamoby@ietf.org>; Mon, 14 Jan 2002 12:43:07 -0500 (EST)
Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-595.cisco.com [10.82.242.83]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04151; Mon, 14 Jan 2002 09:42:25 -0800 (PST)
Message-Id: <4.3.2.7.2.20020114123121.0377bf90@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 14 Jan 2002 12:41:19 -0500
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
From: John Schnizlein <jschnizl@cisco.com>
Subject: RE: [Seamoby] CAR Discovery Requirements
Cc: Govind Krishnamurthi <govs23@hotmail.com>, seamoby@ietf.org
In-Reply-To: <DC504E9C3384054C8506D3E6BB012460382DE1@bsebe001.NOE.Nokia. com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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

At 11:57 AM 1/14/2002, Trossen Dirk (NRC/Boston) wrote:

>I'm kind of confused by your comment. 
>Are you questioning the inter-domain handoff or the discovery? 
>Why do I have to resolve which users are subscribers of which 
>domains if I want to discover ARs in my proximity?

I will admit the possibility that I simply don't understand.
My impression is that the discovery is for the purpose of finding
neighbors for potential context hand-off. One way to limit getting
or giving hand-offs to/from domains with which the provider has no
business relationship is to limit forming the neighborhood.

In non-cyber-space, there are sometimes houses closer to mine that
are considered a different neighborhood because their $/sq.ft. are
so different. On just the other side of a street, the children often
attend a different school (with sometimes dramatically different
$/student expenditure).

Is it necessary to preclude this method of operation for mobility?

>We're discussing CAR discovery. I don't see your policy
>interactions, inter-domain roaming, and billing problems in this
>context. However, it is certainly an issue for the actual selection 
>of the target AR, but TAR selection is not within the scope of the
>CAR discovery protocol.

If you operated a network that supported mobility, would you want the
protocol to imply that other operators could discover your routers for
the purpose of handing off subscriber context to you or getting context
from you? Possibly one or the other, depending on who pays whom, but
you might not want to treat other domain's routers according to the
same policy. You might not even want your competitors to know how well
you cover particular regions.

John


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