IETF Logo Mail Archive

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

Tony Li <tli@cisco.com> Tue, 08 May 2007 22:46 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 1HlYSF-0006E1-5D; Tue, 08 May 2007 18:46:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlYSD-0006Dr-Kh for ram@iab.org; Tue, 08 May 2007 18:46:45 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlYSD-0008Ok-7t for ram@iab.org; Tue, 08 May 2007 18:46:45 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 08 May 2007 15:46:45 -0700
X-IronPort-AV: i="4.14,507,1170662400"; d="scan'208"; a="419917009:sNHT117202306"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l48MkhCr022942; Tue, 8 May 2007 15:46:44 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l48Mkh0f019776; Tue, 8 May 2007 22:46:43 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 15:46:43 -0700
Received: from [192.168.0.102] ([10.21.90.204]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 15:46:43 -0700
In-Reply-To: <271CF87FD652F34DBF877CB0CB5D16FC054EA694@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
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>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <A590D37E-7DEC-4695-998E-DA12A205F306@cisco.com>
Content-Transfer-Encoding: 7bit
From: Tony Li <tli@cisco.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Tue, 08 May 2007 15:46:40 -0700
To: Dave Thaler <dthaler@windows.microsoft.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 08 May 2007 22:46:43.0440 (UTC) FILETIME=[C0022F00:01C791C2]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=863; t=1178664404; x=1179528404; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20<tli@cisco.com> |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=jCJIEt0JlsGnD4Gnx9h4J3iM4yv3qWGfQ5rKvM0jBSQ=; b=N/xB58YLzzBs9gs6MTKaY8PeLKjo+S8woVFFS3LfBg6X4Q3mWVKXu/4TDEBp3d/UbAedX4wt oVXGOKT5aHOd+LtYqwbYfx2aChWuEp7uJcNWKxeUzkRjo44MdMWQKSAS;
Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
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

Dave,

>> 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?


> That's why I like the LISP approach, as the changes are done in places
> (and by people) who actually experience the pain.


Unfortunately, doing LISP inside the site or even in the PE router  
isn't exactly co-located with the major pain felt in the core, and it  
results in a solution that is far from optimal.

Tony


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

v2.23.0 | Report a Bug | By Email