From adrian@olddog.co.uk Wed Dec 14 09:38:48 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442EC21F85A1; Wed, 14 Dec 2011 09:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQL+3QUAwobM; Wed, 14 Dec 2011 09:38:47 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C702E21F84FB; Wed, 14 Dec 2011 09:38:41 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pBEHccBi007798; Wed, 14 Dec 2011 17:38:38 GMT Received: from 950129200 (217.114.116.8.networkplus.customer.ch.easynet.net [217.114.116.8] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id pBEHcYcB007781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Dec 2011 17:38:36 GMT From: "Adrian Farrel" To: , , , , Date: Wed, 14 Dec 2011 17:38:34 -0000 Message-ID: <009801ccba87$36863c60$a392b520$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acy6hzHKHnVyuytBRK+ntRHEAC1QUw== Content-Language: en-gb Subject: [RTG-DIR] FYI: Joint O&M / Routing Area Interim To Discuss Data Center Network Challenges X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 17:38:48 -0000 Please be aware. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 14 December 2011 17:26 > To: IETF Announcement list > Cc: dc@ietf.org > Subject: Joint O&M / Routing Area Interim To Discuss Data Center Network > Challenges > > The IETF Operations and Routing Areas will hold a two-day joint interim meeting > in late January or early February to discuss networking > challenges encountered in data centers. A doodle poll has been posted at > http://www.doodle.com/hiu9xgw7tg7pkrwg in order to gauge interest > and identify a convenient date. While a venue has not yet been chosen, the IETF > is considering sites in the eastern part of the United States > and Canada. An attendance fee may be charged to cover meeting costs. > > Those requesting time on the agenda are asked to submit Internet Drafts in the > following areas: > > - New services offered through data centers > - Networking requirements for the data center > - Network architectures for the data center > - Scaling, resiliency, security issues in the data center networks > > Internet Drafts considered by this meeting will specify motivation, requirements > and constraints for data center networking solutions > to be developed by the IETF. Presentations regarding solutions will be > entertained only if that discussion helps to describe the problem > space and time permits a balanced discussion of candidate technologies. > > All drafts presented at this meeting will be announced and discussed on the IETF > Data Center Mailing List (dc@ietf.org). Those submitting > drafts are asked to announce them to the mailing list upon submission. > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From jari.arkko@piuha.net Tue Dec 20 03:52:35 2011 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E894A21F8B45; Tue, 20 Dec 2011 03:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5kL4fqv8PSc; Tue, 20 Dec 2011 03:52:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B3BBF21F8B44; Tue, 20 Dec 2011 03:52:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 10CE72CC4D; Tue, 20 Dec 2011 13:52:34 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrB9hEKc9VJr; Tue, 20 Dec 2011 13:52:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 1DA3A2CC31; Tue, 20 Dec 2011 13:52:33 +0200 (EET) Message-ID: <4EF07701.2040705@piuha.net> Date: Tue, 20 Dec 2011 13:52:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: IESG , IAB , "ipdir@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Dec 2011 08:03:41 -0800 Cc: rtg-dir@ietf.org, Tony Li , "lisp-chairs@tools.ietf.org" Subject: [RTG-DIR] recharter for the LISP working group X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 11:52:36 -0000 Secretary (bcced): Please put to this on the agenda for the next IESG telechat. IESG, IAB, directorates: The LISP working group has completed its main specifications and submitted them to the IESG. While the approval of the documents is still in progress -- one small document has been approved but there are still many issues with the main ones -- I think the process will complete as planned. The key change that we are working on is ensuring that the documents are even more explicit about the areas where we do not know how well the mechanisms work. These changes are in progress. In the meantime, the group has discussed possible next steps. They would like to recharter to do more, and discussion on the list has converged with the charter below (with me making some edits). I would like to bring this proposed charter to the IESG and get the change reviewed in the IETF and approved. Jari Locator/ID Separation Protocol (lisp) ------------------------------------- Charter Current Status: Active Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 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. 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 is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (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 locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. LISP requires no changes to end-systems or to most routers. LISP aims for an incrementally deployable protocol. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG is chartered to work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - LISP security threats and solutions - MIBs - deployment models - allocation of EID space - alternate mapping system designs In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. 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 LISP and the various LISP 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 to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG 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 as well as the manageability and operability of LISP. Specifically, the group will work on: - documenting areas that need experimentation - summarizing the results of implementation, experiments, and deployment experience - describing the implications of employing LISP - operational guidance for using LISP Goals and Milestones Jun 2012 Forward draft-ietf-lisp-mib to the IESG Jun 2012 Forward draft-ietf-lisp-sec to the IESG Jun 2012 Forward to the IESG an operational document which should include cache management and ETR synchronization techniques (draft-ietf-lisp-deployment). Dec 2013 Publish an example cache management specification. Dec 2013 Forward to the IESG an evaluation of the security threat to cache maintenance (draft-ietf-lisp-threats) Dec 2013 Forward to the IESG a document addressing the areas which require further experimentation. Jun 2014 Evaluate the applicability and coverage for LISP from a reuse of SIDR technology. Jun 2014 Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. Jun 2014 Analyze and document the implications of LISP deployments in Internet topologies and forward to IESG for publication. Dec 2014 Re-charter or close