Re: [lisp] LISP does not involve separate namespaces

Dino Farinacci <dino@cisco.com> Thu, 30 July 2009 13:54 UTC

Return-Path: <dino@cisco.com>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C017928C189 for <lisp@core3.amsl.com>; Thu, 30 Jul 2009 06:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.153
X-Spam-Level:
X-Spam-Status: No, score=-6.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PF918v1y9fbV for <lisp@core3.amsl.com>; Thu, 30 Jul 2009 06:54:14 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E29DC3A6802 for <lisp@ietf.org>; Thu, 30 Jul 2009 06:54:09 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAE9DcUqrR7PD/2dsb2JhbAC6R4gnkCEFhBGBTg
X-IronPort-AV: E=Sophos;i="4.43,295,1246838400"; d="scan'208";a="180564401"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2009 13:54:11 +0000
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 n6UDsBBZ010872; Thu, 30 Jul 2009 06:54:11 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6UDsBPh013155; Thu, 30 Jul 2009 13:54:11 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.3959); Thu, 30 Jul 2009 06:54:11 -0700
Received: from dhcp-1789.meeting.ietf.org ([10.21.95.169]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 06:54:10 -0700
Message-Id: <A991AE36-B5F5-4A65-90CA-CF5E819B6AED@cisco.com>
From: Dino Farinacci <dino@cisco.com>
To: Scott Brim <scott.brim@gmail.com>
In-Reply-To: <4A71A34A.3080503@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 30 Jul 2009 06:54:08 -0700
References: <20090730031536.1CB5E6BE58C@mercury.lcs.mit.edu> <4A719822.1090000@firstpr.com.au> <2DC01886-6E0D-4135-B65A-0EEF9AF1A1CC@cisco.com> <4A71A34A.3080503@gmail.com>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 30 Jul 2009 13:54:11.0268 (UTC) FILETIME=[37482840:01CA111D]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3536; t=1248962051; x=1249826051; 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[lisp]=20LISP=20does=20not=20involve=20 separate=20namespaces |Sender:=20; bh=gx/FM4LEvhVqbDqA8fyvAu4QXF2c2kQNI/oocFqkqns=; b=mFwpFyuBabdA2PJMfJ+23qwGwKij2NPLLIWrYkbefmt0nOgcKP8XZ+mNCy lGxR+HbeYEclhifUmbZWvn3DF2EZLth4o6hKy1pd4FHLLrjIM8kgmnHw3M71 A5aPfd1dfH;
Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, Robin Whittle <rw@firstpr.com.au>, lisp@ietf.org
Subject: Re: [lisp] LISP does not involve separate namespaces
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 13:54:15 -0000

> Dino Farinacci allegedly wrote on 07/30/2009 15:31 GMT+02:00:
>> So, architecturally, the 2 address spaces are separate and can
>> implemented that way. It could be desirable to have an EID address  
>> out
>> of the 2002::/16 space or a RLOC address out of the 2610:00d0::/32
>> space. But it may not be needed with such a large address space.
>>
>> For IPv4, life is harder because of the vast install base, so the  
>> clear
>> separation is harder to appreciate. But you could have the same  
>> address
>> assigned from each namespace.
>
> Suppose a nameserver or some other piece of critical infrastructure  
> is in RLOC space, and an endpoint wants to talk to it.  What  
> happens?  How does the endpoint's site network, or xTR, tell whether  
> the destination address is an RLOC or an EID if the address spaces  
> overlap?

The ALT tells you if the destination is in EID space or RLOC space.  
But that is not sufficient. You have to consider other cases based on  
the source address of the packet.

If the source address of the site host is not from a list of  
configured EID-prefixes for the site, the ITR "natively forwards" the  
packet (which means it does not encapsulate it). So this would be RLOC- 
to-RLOC communication. If the source address of the site host is from  
a list of configured EID-prefixes for the site, the ITR will natively  
forward based on the first paragraph above. So this would be EID-to- 
RLOC communication.

When an ITR is not attached to the ALT, which is the default setting  
for a LISP site router (because we want it to be as low-opex as  
possible), it will have "negative cache entries, which are coarse  
prefixes that reside in the map-cache, with an action of "natively  
forward". The map-resolver sends these "negative Map-Replies" when it  
finds out that the destination of a Map-Request is not in the ALT.

The negative cache entries are very coarse so we can keep the smallest  
number as possible in the map-cache. I have included some "show ip  
lisp map-cache" output from an ITR on the LISP test network. Notice  
the bit patterns and prefix mask-lengths used based on a single EID- 
prefix block of 153.16.0.0/16 allocated to LISP sites.

Dino

----

LISP IP Mapping Cache for VRF "default", 9 entries

0.0.0.0/1, uptime: 1d07h, expires: 23:54:43, via map-reply
   Negative cache entry, action: forward-native

128.0.0.0/4, uptime: 1d06h, expires: 23:54:43, via map-reply
   Negative cache entry, action: forward-native

152.0.0.0/8, uptime: 20:26:25, expires: 03:33:34, via map-reply
   Negative cache entry, action: forward-native

153.16.10.0/24, uptime: 1d07h, expires: 23:58:49, via map-reply, auth
   Locator          Uptime    State     Priority/Weight  Data|Control  
in/out
   xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  909/910
   xxx.xxx.xxx.xxx  1d07h     up        1/50             0/0  |  910/910

153.16.19.0/24, uptime: 1d02h, expires: 23:58:49, via map-reply, auth
   Locator       Uptime    State     Priority/Weight  Data|Control in/ 
out
   xxx.xxx.xxx.x 1d02h     up        5/100            3/4  |  3065/3066

154.0.0.0/7, uptime: 06:58:14, expires: 17:01:45, via map-reply
   Negative cache entry, action: forward-native

160.0.0.0/3, uptime: 06:50:32, expires: 17:09:27, via map-reply
   Negative cache entry, action: forward-native

192.0.0.0/3, uptime: 06:49:30, expires: 17:10:29, via map-reply
   Negative cache entry, action: forward-native

----