IETF Logo Mail Archive

RE: [RAM] The mapping problem: rendezvous points?

Dave Thaler <dthaler@windows.microsoft.com> Tue, 08 May 2007 23:23 UTC

Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ25-0007iR-II; Tue, 08 May 2007 19:23:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlZ25-0007iK-4i for ram@iab.org; Tue, 08 May 2007 19:23:49 -0400
Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlZ23-00034s-RR for ram@iab.org; Tue, 08 May 2007 19:23:49 -0400
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Tue, 8 May 2007 16:23:46 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Tue, 8 May 2007 16:23:46 -0700
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 May 2007 16:23:46 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RAM] The mapping problem: rendezvous points?
Date: Tue, 08 May 2007 16:23:06 -0700
Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC054EA741@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <A590D37E-7DEC-4695-998E-DA12A205F306@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [RAM] The mapping problem: rendezvous points?
Thread-Index: AceRws6BIF9N3RQbRT6+SvaRdAWD9wABDzjQ
References: <8F47F550-6224-4AFF-8359-CBA98D3F2FAB@muada.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA470@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <62AFA8C7-FDD4-4FF2-B609-966081DDC0D1@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA593@WIN-MSG-21 <B79E458E-F18C-4617-B953-F311E5623E9A@cisco.com> <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <A590D37E-7DEC-4695-998E-DA12A205F306@cisco.com>
From: Dave Thaler <dthaler@windows.microsoft.com>
To: Tony Li <tli@cisco.com>
X-OriginalArrivalTime: 08 May 2007 23:23:46.0025 (UTC) FILETIME=[ECC5BD90:01C791C7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: ram@iab.org
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org

Tony Li [mailto:tli@cisco.com]
> >> I think that your claim is equivalent to saying that you prefer
> >> initial sub-optimality to initial latency.  I'm not yet convinced
by
> >> this.  If the mapping client is in fact the host, it would seem
that
> >> we could mask any initial latency.
> >
> > The host is not incented to change to deal with routing scalability.
> 
> Fortunately, the locator/ID split brings changes to mobility and
> renumbering.  It also morphs the fundamental Internet architecture.
> Don't these also incent the host to change?

Renumbering doesn't incent the host to change.  As I mentioned in the
Intarea presentation, renumbering requires MANY components to change
(hosts, firewalls, IDS's, enterprise inventory applications, etc.)
Changing hosts by themselves doesn't solve anything... we learned this
from IPv6.  Renumbering provides strong incentives to NOT change hosts
but instead change site border routers (or something else outside most
of the network that wants PI space).

Mobility incents _some_ hosts to change... but just the ones that are
mobile.
That's why Mobile IPv6 has an easier deployment model than say HIP...
with MIPv6 someone who changes still gets benefit (with help from a 
Home Agent) when talking to arbitrary correspondent nodes.  The
correspondent nodes aren't strongly incented to change, and don't have
to.

-Dave

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram

v2.23.0 | Report a Bug | By Email