[rrg] LISP Versioning vs. Solicit-Map-Request
Robin Whittle <rw@firstpr.com.au> Mon, 09 March 2009 07:50 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 F34F13A6A86 for <rrg@core3.amsl.com>; Mon, 9 Mar 2009 00:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.559
X-Spam-Level:
X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=0.336, 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 78T53dy0U0Dt for <rrg@core3.amsl.com>; Mon, 9 Mar 2009 00:50:27 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 9BE7F3A691B for <rrg@irtf.org>; Mon, 9 Mar 2009 00:50:26 -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 70F63175B96; Mon, 9 Mar 2009 18:33:33 +1100 (EST)
Message-ID: <49B4C654.7080907@firstpr.com.au>
Date: Mon, 09 Mar 2009 18:33:40 +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>, lisp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] LISP Versioning vs. Solicit-Map-Request
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: Mon, 09 Mar 2009 07:50:28 -0000
Short version: The proposed (not at all official) mapping Versioning approach to LISP should work in all circumstances on a direct ETR to ITR basis. However, its equivalent in the current LISP drafts - Solicit-Map-Request - I think will only work when the sending host is on an EID address, which will frequently not be the case. I think one of the advantages of the Versioning approach: http://tools.ietf.org/html/draft-iannone-lisp-mapping-versioning-00 is that the ETR sends a packet directly to the remote ITR which is sending it encapsulated traffic packets, prompting the ITR to request new mapping if its cached mapping version is less than the version number in the message. This should work in all circumstances where the ITR's Map-Request goes to the ETR, including with the use of non-caching Map-Resolvers. http://tools.ietf.org/html/draft-fuller-lisp-ms-00 or with a caching Map-Resolver when the ITR's Map-Request has the A (Authoritative) bit set, causing the caching Map-Resolver not to answer from its cache, but to send the Map-Request to the ALT network, verbatim, with the ITR's address rather than its own. The ETR sends the Map-Reply straight back to the ITR. The Versioning system should also work to some extent when the ITR requests mapping with the A (Authoritative) flag set to zero, via a caching Map-Resolver. In this case, the Map-Resolver requests the mapping (if it doesn't already have it) and the ETR replies to the Map-Resolver. The ETR then could cache the address of the Map-Resolver and send it a Map-Update-Notification Message. The first potential problem here is how the ETR could figure out the Map-Resolver to send the Map-Update-Notification Message to. This is not a problem if the ETR decides to send it to all recent requesters. But if, for some reason (I don't know how) the ETR decided that a particular ITR's behaviour was indicative of it needing to get new mapping, it could be difficult or impossible for the ETR to figure out which caching Map-Requester the errant ITR got its mapping from. The second potential problem is how a Map-Resolver, which has just obtained updated mapping and recognises it differs from the mapping it recently had and recently sent in a Map-Reply to an ITR, could prompt the ITR to get fresh mapping. I guess the Map-Resolver could send the ITR a Map-Update-Notification Message and rely on the ITR requesting the mapping again, ideally with the A bit zeroed, to save the burden on the ALT network and ETR of sending the request all the way to the ETR, rather than the Map-Resolver generating the Map-Reply from its fresh cache. The ETR could always send a Map-Update-Notification Message direct to the ITR. I guess the ITR should then respond by making a Map-Request with the A flag set, so as to ignore any (perhaps or presumably stale) cached mapping in its local caching Map-Resolver. There is no explicit way in the current LISP protocols for the ITR to request the caching Map-Resolver refresh its mapping cache before sending a reply, other than perhaps sending the Map-Resolver a Map-Update-Notification Message, waiting a few seconds and then requesting the mapping again, with A set to zero. However Dino wrote of an implicit technique: http://www.ietf.org/mail-archive/web/rrg/current/msg04575.html ITR sends A=1 Map-Requests with an SMR-bit set. That can tell the Map-Resolver to ask for the Map-Reply back to update it cache. I know there are security issues with this but it's one way of doing it. At least this Versioning system should work in all circumstances on a direct ETR to ITR basis. The existing LISP system of Solicit-Map-Request (SMR): http://tools.ietf.org/html/draft-farinacci-lisp-12#section-6.5.2 won't work when the remote sending host is on an RLOC address, as will be the hosts of ISPs, of end-users who retain BGP-mapped PI addresses and of the many end-users, such as DSL customers at home, who will continue to use PA address space provided by their ISP. SMR would work when the remote sending host is on an EID address, so packets going to it are encapsulated in a local ITR, with the LISP header with its SMR bit set, to be decapsulated by the remote ETR where the SMR bit will be recognised. Then, the remote ETR signals the ITR at that end-user network to request new mapping. As far as I know, there is no provision for an ETR sending a Solicit-Map-Request to a caching Map-Resolver. Maybe it can, but neither "SMR" nor "Solicit" appear in: http://tools.ietf.org/html/draft-fuller-lisp-ms-00 - Robin
- [rrg] LISP Versioning vs. Solicit-Map-Request Robin Whittle