[rrg] LISP-NERD-Map-Resolver ~= APT & Ivip
Robin Whittle <rw@firstpr.com.au> Tue, 10 March 2009 03:33 UTC
Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4BF3A6B29 for <rrg@core3.amsl.com>; Mon, 9 Mar 2009 20:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.573
X-Spam-Level:
X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 ozuDYBEicTZH for <rrg@core3.amsl.com>; Mon, 9 Mar 2009 20:33:44 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 64E6A3A67B4 for <rrg@irtf.org>; Mon, 9 Mar 2009 20:33:44 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 5A895175E15; Tue, 10 Mar 2009 14:34:18 +1100 (EST)
Message-ID: <49B5DF43.7090401@firstpr.com.au>
Date: Tue, 10 Mar 2009 14:32:19 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] LISP-NERD-Map-Resolver ~= APT & Ivip
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Mar 2009 03:33:45 -0000
Perhaps the LISP team is contemplating using NERD full push mapping distribution to Map-Resolvers, instead of ALT or CONS. LISP Map Server (and Map-Resolvers) 2009-03-03 http://tools.ietf.org/html/draft-fuller-lisp-ms-00 http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html Dino wrote: "... a Map-Resolver can be a LISP-ALT router/system, a NERD system, or a CONS/DHT system." This "LISP-NERD-Map-Resolver" (my term) architecture would resemble the APT and Ivip architectures in some important ways, since all three architectures involve the global push of mapping to local full-database query servers. I think this approach would replace ALT or CONS entirely. If the mapping was centralised to one or a smallish number of servers, as it is in NERD, then there would be no point in building and running an ALT global query server network too. I think it would be simpler to have the entire system work with Map-Resolvers getting their database updates via the NERD system. These local full database query servers ("Default Mappers" in APT) are typically located in each ISP and handle mapping queries from ITRs in that ISP's network. With Ivip and perhaps LISP, the local query servers (Map-Resolvers for LISP) also handle mapping requests from ITRs in end-user networks which use the ISP. There are profound advantages of this architecture over a global query server architecture such as LISP-ALT or LISP-CONS, including: a - The mapping reply comes back to the ITR nearly instantly. So there is no significant delay for any traffic packets. b - The traffic costs of the request and reply are minimal since they are within the local ISP network and perhaps the end-user network if the ITRs are there too. (But there are traffic costs getting the continual feed of mapping updates to each local query server.) c - A local query server is a much more reliable source of mapping than sending the query over any global query server network such as ALT or CONS. d - No need for Map-Servers or for ETRs to necessarily be the authoritative source of mapping. e - If the Map-Resolver can tell the ITR whenever new mapping arrives, then (depending on how fast the push system is) there is reduced or no reason to fuss with reachability bits, mapping version numbers, ETRs prompting ITRs to get new mapping etc. f - For Ivip, with essentially real-time mapping distribution with direct (previous query nonce secured) push of updates from local query servers to the ITRs which may need it, then there is no need for multiple choice of ETR addresses. The mapping consists of a single ETR address and the ITR has no decision to make regarding which ETR to tunnel packets to. This also completely separates the probing and decision making from the core-edge separation scheme itself, whereas for a slow push system, it has to be integrated, since the ITRs have do this individually. (See recent message: "Concerns about LISP Reachability Bits & Ivip's distributed probing" for a description of the separate probing and decision system. http://www.ietf.org/mail-archive/web/rrg/current/msg04587.html) Of course, in place of the ALT or CONS global query server system, there there needs to be substantial Map-Servers, and a secure robust, global mapping distribution system by which the Map-Servers can boot, get the current mapping and then keep their copy up to date. This is non-trivial, but I am sure it is worth it. APT gets its mapping to its local query servers (Default Mappers) in a totally different manner to Ivip, and NERD (which was originally conceived of being for all ITRs having the full database) does it yet another way, with each device downloading mapping and updates from centralised servers). http://tools.ietf.org/html/draft-farinacci-lisp-12 http://tools.ietf.org/html/draft-lear-lisp-nerd-04 http://tools.ietf.org/html/draft-fuller-lisp-alt-05 http://tools.ietf.org/html/draft-lewis-lisp-interworking-02 http://www.cs.ucla.edu/~meisel/apt-rrg.pdf http://tools.ietf.org/html/draft-jen-apt-01 http://www.firstpr.com.au/ip/ivip/ http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-01 (I plan a much improved, shorter, architectural I-D in the next few months.) - Robin
- [rrg] LISP-NERD-Map-Resolver ~= APT & Ivip Robin Whittle
- Re: [rrg] LISP-NERD-Map-Resolver ~= APT & Ivip Robin Whittle