IETF Logo Mail Archive

Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels

Markus Stenberg <mstenber@cisco.com> Mon, 18 June 2007 02: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 1I06tc-0003BL-Qh; Sun, 17 Jun 2007 22:23:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06tb-00037B-Ae for ram@iab.org; Sun, 17 Jun 2007 22:23:11 -0400
Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I06tZ-0007wK-Ti for ram@iab.org; Sun, 17 Jun 2007 22:23:11 -0400
Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jun 2007 04:23:10 +0200
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5I2N9XM009226; Mon, 18 Jun 2007 04:23:09 +0200
Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5I2MeDh028956; Mon, 18 Jun 2007 02:23:04 GMT
Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 04:22:55 +0200
Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:22:46 +0800
Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:22:45 +0800
Received: from mstenber by emakko.cisco.com with local (Exim 4.63) (envelope-from <mstenber@cisco.com>) id 1I06t9-00048z-Us; Mon, 18 Jun 2007 11:22:44 +0900
From: Markus Stenberg <mstenber@cisco.com>
To: Dino Farinacci <dino@cisco.com>
Subject: Re: [RAM] ViP: Anycast ITRs in the DFZ & mobile tunnels
Organization: cisco Systems, Inc.
References: <46720DED.9090608@firstpr.com.au> <1FDC4EF3-97D4-4CA7-A7EF-5012D4EA5DB8@cisco.com> <46723A5A.9000809@firstpr.com.au> <776CCBA4-FB53-4EC7-9733-C8E1F5CCC67C@cisco.com> <46724429.1040909@firstpr.com.au> <9D449908-6773-4AFB-A2E7-C3C669229F53@cisco.com>
Date: Mon, 18 Jun 2007 11:22:43 +0900
In-Reply-To: <9D449908-6773-4AFB-A2E7-C3C669229F53@cisco.com> (Dino Farinacci's message of "Fri, 15 Jun 2007 00:54:56 -0700")
Message-ID: <87lkeiypak.fsf@emakko.cisco.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 18 Jun 2007 02:22:45.0820 (UTC) FILETIME=[8EB667C0:01C7B14F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=975; t=1182133389; x=1182997389; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mstenber@cisco.com; z=From:=20Markus=20Stenberg=20<mstenber@cisco.com> |Subject:=20Re=3A=20[RAM]=20ViP=3A=20Anycast=20ITRs=20in=20the=20DFZ=20&= 20mobile=20tunnels |Sender:=20; bh=H5CIVM2JDfjeZI40OykPUXS2NjTGWxdULDEPkdlMc5U=; b=Q0OdYaO9nnqelgqxW7sLI6xEbnwDy6/cPPf4Q8NLwv0y55+NPp0H8zQuz5ZjeRuo8TNLm/uE PhP6H+co/gxcWmehM232/ULMc9Z3thLJIiM5mgK/dqfFAiNiL9APSjNP;
Authentication-Results: ams-dkim-2; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: Robin Whittle <rw@firstpr.com.au>, 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

Dino Farinacci <dino@cisco.com> writes:
>> Christian, I think you understand what I am trying to say.  It is
>> not very complex and I don't expect it is very novel.  But since I
>> couldn't think of anything which does exactly this, I wrote it up.
> But you require your address to be routeable all the time. If a site
> requests Provider Independent (PI) addresses, your proposal requires
> them to be routed in the core.
>
> That will not reduce the size of the routing tables.

It does to a degree; if significant chunk of the PI space suddenly pointed
to anycast-ITR of 'the other routing system' (whether you want to call it
LISP or VIP, is academic), it could be aggregated and _not_ have any churn
in it within the normal routing system.

Of course, the question of whether or not the shifting of the routing load
elsewhere really accomplishes anything is still there, but I thought that
was the assumption with the LISP too? 

Cheers,

-Markus

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

v2.23.0 | Report a Bug | By Email