[lisp] LISP, San Francisco, and WG
Jari Arkko <jari.arkko@piuha.net> Fri, 13 March 2009 13:21 UTC
Return-Path: <jari.arkko@piuha.net>
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 7C77528C0DF for <lisp@core3.amsl.com>; Fri, 13 Mar 2009 06:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level:
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
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 loUi11we4Z4K for <lisp@core3.amsl.com>; Fri, 13 Mar 2009 06:21:50 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AD7403A6892 for <lisp@ietf.org>; Fri, 13 Mar 2009 06:21:49 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id BE230198723; Fri, 13 Mar 2009 15:22:25 +0200 (EET)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 54010198671; Fri, 13 Mar 2009 15:22:25 +0200 (EET)
Message-ID: <49BA5DF7.3070802@piuha.net>
Date: Fri, 13 Mar 2009 15:21:59 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: lisp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: [lisp] LISP, San Francisco, and WG
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: Fri, 13 Mar 2009 13:21:58 -0000
All, After considering the input from the various lists, IESG, IAB, etc, I have decided that the best course of action with regards to LISP is to create a tightly scoped WG. The scoping relates to truth in advertising about the readiness of the technology for wide deployment and how the results of the WG will be used. The specifications coming out of the WG will be Experimental RFCs. Please see the charter text below; comments appreciated. And I see that we've already received feedback from Margaret, thanks for that. The group is expected to work on one specific solution, converting that solution to something else is not within the plan. The RRG obviously needs to continue their work with a number of other solutions and analysis of the design space. I plan to keep the door open for other proposals as well (some could argue that 6AI is another solution; that might become a WG too in San Francisco). I don't think anyone believes that either LISP or the other solutions from RRG are ready for prime time; there are significant remaining problems even at the conceptual and incentive levels, let alone protocol bits. But before we get to a final solution, it is very useful to test various designs, to understand their implications. A formal call for IETF-wide comments on the proposed working group and charter will be made in the next few days. You can send input on this list or say something at the meeting. The final approval will happen after San Francisco. At the end of the day we will decide this based on the community feedback, but my expectation is that there is support for letting the LISP folks work on their design in the IETF. Sam Hartman and Darrel Lewis have agreed to chair the group -- thank you! Please talk to the chairs about agenda; we are obviously doing this quite late before the meeting, so a lot of preparation has to happen in a short amount of time. Other than the opportunity for feedback on the WG creation and the charter, I think we should run the meeting as if it were a WG meeting. Jari -------- LISP (Locator/ID Separation Protocol) Last Modified: 2009-03-12 21:01:40 Chair(s): TBD Internet Area Director(s): TBD Routing Area Advisor: TBD Mailing Lists: General Discussion: https://www.ietf.org/mailman/listinfo/lisp Description of Working Group: The IAB's October 2006 workshop on Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system and the impending exhaustion of the IPv4 address space. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "Locator/Identifier separation". The basic idea behind the separation that the Internet architecture combines two functions, Routing Locators, or RLOCs (where you are attached to the network) and Endpoint Identifiers, or EIDs (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple location and identity, thus allowing for efficient aggregation of the RLOC space and providing persistent identity in the EID space. LISP supports the separation of the Internet address space into Endpoint Identifiers and Routing Locators following a network-based map-and-encap scheme (RFC 1955). It employs EIDs that represent a mixture of locators and identifiers; it could also be classified as a multi-level locator scheme. A number of other approaches are being looked at in parallel in the IRTF and IETF. At this time, these proposals are at an early stage. All proposals (including LISP) have potentially harmful side-effects to Internet traffic carried by the involved routers, have parts where deployment incentives may be lacking, and are NOT RECOMMENDED for deployment beyond experimental situations at this stage. Many of the proposals have components (such as the EID-to-RLOC mapping system) where it is not yet known what kind of design alternative is the best one among many. However, despite these issues it would be valuable to write concrete protocol specifications and develop implementations that can be used to understand the characteristics of these designs. The LISP WG is chartered to work on the LISP base protocol (draft-farinacci-lisp-12.txt), the LISP+ALT mapping system (draft-fuller-lisp-alt-05.txt), LISP Interworking (draft-lewis-lisp-interworking-02.txt), LISP Map Server (draft-fuller-lisp-ms-00.txt), and LISP multicast (draft-farinacci-lisp-multicast-01.txt) for these purposes, with the given drafts as a starting point. The working group will encourage and support interoperable LISP implementations as well as defining requirements for alternate mapping systems. The Working Group will also develop security profiles for the ALT and/or other mapping systems. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF (e.g., the Routing Research Group) that attempts to understand which type of a solution is optimal. The LISP WG is NOT chartered to develop the final or standard solution for solving the routing scalability problem. Its specifications are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. This analysis will explain what role LISP can play in scalable routing. The analysis should also look at scalability and levels of state required for encapsulation, decapsulation, liveness, and so on (draft-meyer-loc-id-implications). Goals and Milestones: Mar 2010 Submit base LISP specification to the IESG as Experimental Mar 2010 Submit base ALT specification to the IESG as Experimental Mar 2010 Submit the LISP Interworking specification to the IESG as Experimental June 2010 Submit the LISP Map Server specification to the IESG as Experimental June 2010 Submit Recommendations for Securing the LISP Mapping System to the IESG as Experimental Jul 2010 Submit LISP for Multicast Environments to the IESG as Experimental Dec 2010 Submit a preliminary analysis as Informational Dec 2010 Re-charter or close.
- [lisp] LISP, San Francisco, and WG Jari Arkko