RE: [Seamoby] Minutes for Meeting at IETF 53

"Glenn Morrow"<gmorrow@nortelnetworks.com> Mon, 15 April 2002 21:02 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 RAA06651 for <seamoby-archive@odin.ietf.org>; Mon, 15 Apr 2002 17:02:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13757; Mon, 15 Apr 2002 16:56:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13726 for <seamoby@optimus.ietf.org>; Mon, 15 Apr 2002 16:56:21 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06507 for <seamoby@ietf.org>; Mon, 15 Apr 2002 16:56:16 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3FKtnX04836 for <seamoby@ietf.org>; Mon, 15 Apr 2002 15:55:49 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <2Y3TVC8T>; Mon, 15 Apr 2002 15:55:48 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E032A217A@zrc2c012.us.nortel.com>
From: Glenn Morrow <gmorrow@nortelnetworks.com>
To: seamoby@ietf.org
Subject: RE: [Seamoby] Minutes for Meeting at IETF 53
Date: Mon, 15 Apr 2002 15:55:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4BF.EAB5BD30"
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

Excuse me for not being at the WG meeting due to a conflict but I do have
some comments on the meeting minutes.

[The Issue]
It seems that the minutes indicate that people have somehow come to a
conclusion that there is no need for access routers to divulge that they are
geographically adjancent to themselves via the IP infrastructure. The
minutes also seem to indicate that the mobile alone should be the only way
to pass addresses of CARs to source ARs.

[Technical Questions]
O.K. If this is true then how will a mobile pass this information to their
source AR if the mobile only has one NIC and that NIC is only capable of
listening to one media at once? 

Even if the NIC can handle multiple technologies what if it can't do the
multiple technologies simulateneously?

[Business Questions]
What is the legacy NICs are not capable of double-communication as described
above?

What if there are two or more NICs but it chews up the batteries of the
device when both are in use? 

What about the cost ramification and therefore market potential of devices
with more than one or a multimode NIC?

Are these devices just destined to have crapy handoff, low battery life, or
just be expensive?

Of course your existing routers don't do this sort of thing and gee it might
cost some money to develop the new functions - ya - that's because IP wasn't
never designed to deal with node mobility - ya - that's what this working
group is here for, I thought.

[Non-technical commentary - atheism] 
The end to end thing is always a good thing to think of BUT keep in mind
that they only reason you do things to the network if to do something the
hosts can't do or its less expensive to deploy. Nobody ever wants to add
something to the network if they can avoid it. I just think that this might
be one of those cases when you can't avoid it. The IP addresses are not L2
stuff.

[Administrative Commentary]
If the WG just doesn't want to deal with the administrative hassle of making
network based CAR discovery automatic or zero-conf-like similar to dynamic
routing, then just say all we want to do is make this configurable at this
time or spin it off into another WG that does want to agree on a way to
dynamically convey this information. Also as I recall, the early antagonists
of dynamic routing also said it wouldn't scale. Gee you could also pawn it
off on AAA. Whoaa - hot potata - hot patata.

Keep in mind the excuses and needs for dynamic routing are analogous to the
excuses and needs for dynamic CAR discovery. i.e. sometimes you need it and
want it and sometimes ya don't.

Hope this helps,

Glenn

[Solve it for routers and the hosts are a breeze]
p.s. you'll probably bump into the same problem again in the Monet WG where
the correct thing to do should be pretty blatent.