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

Dino Farinacci <dino@cisco.com> Tue, 11 September 2007 14:27 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 1IV6iR-0001cn-DS; Tue, 11 Sep 2007 10:27:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV6iP-0001cV-Vw for ram@iab.org; Tue, 11 Sep 2007 10:27:45 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV6iO-0004Rk-P1 for ram@iab.org; Tue, 11 Sep 2007 10:27:45 -0400
X-IronPort-AV: E=Sophos;i="4.20,238,1186383600"; d="scan'208";a="175413631"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 11 Sep 2007 07:27:44 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8BERiKu012657; Tue, 11 Sep 2007 07:27:44 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8BERgoZ019693; Tue, 11 Sep 2007 14:27:44 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 07:27:40 -0700
Received: from [10.224.130.4] ([10.21.92.242]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 07:27:39 -0700
In-Reply-To: <20070910230718.DB9E7872FC@mercury.lcs.mit.edu>
References: <20070910230718.DB9E7872FC@mercury.lcs.mit.edu>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7118BA24-929B-4AF9-BEB6-3769F6175A65@cisco.com>
Content-Transfer-Encoding: 7bit
From: Dino Farinacci <dino@cisco.com>
Subject: Re: [RAM] The mapping problem: rendezvous points?
Date: Tue, 11 Sep 2007 07:27:39 -0700
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 11 Sep 2007 14:27:39.0806 (UTC) FILETIME=[E842BBE0:01C7F47F]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1238; t=1189520864; x=1190384864; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20<dino@cisco.com> |Subject:=20Re=3A=20[RAM]=20The=20mapping=20problem=3A=20rendezvous=20poi nts? |Sender:=20; bh=nn2vrTadTdN1bX3vXCPDqI5Nn+gcq7alNvIsONeMzik=; b=r1ZEjyOaBlzJDYGqleSRu0/puO6Q1ZDa+9qzxzr92oHsUp+6DMMh63YVh+sJ3HgABowvIrDY amSCijSRi9bT8zYvVNNFbXgknR+haItIh/5tZFOseqOiVL7uAn/jSVGh;
Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.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

>     > From: Dino Farinacci <dino@cisco.com>
>
>     > if an EID-prefix namespace is routed on another topology  
> where you only
>     > route on IDs (where the Internet topology we know of today  
> routes only
>     > on locator prefixes)
>
> Err, minor terminological nit: one my definitions of "locator" is  
> 'names used
> by the path-selection system'. So if you have a system which is doing
> "rout[ing]" (i.e. doing next-hop selection along the path), then  
> the things
> it is using as the name of the destination are, *by definition*,  
> locators...
> even if you call them EIDs!

I agree with your definition, but in LISP 1 and 1.5, when you copy  
the inner DA to the outer DA, we call the inner DA an EID because it  
is assigned to a host. And we use that EID as a locator in the IGP.  
When it is copied to the outer DA for map resolution, I guess it is  
also a locator outside of the site.

But the semantic of this outer DA, in lieu of map resolution comes  
out of the EID-prefix allocation space and not an ISPs space.

So I know this can be confusing or controversial, but when I look at  
an address, I call it from where it was *allocated* from and not how  
it is used.

Dino

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