From root@core3.amsl.com Fri Oct 2 11:30:02 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1AC7E3A67BD; Fri, 2 Oct 2009 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091002183002.1AC7E3A67BD@core3.amsl.com> Date: Fri, 2 Oct 2009 11:30:01 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-03.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 18:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-03.txt Pages : 14 Date : 2009-10-02 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-ms-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-02111553.I-D@ietf.org> --NextPart-- From vaf@cisco.com Tue Oct 6 03:48:16 2009 Return-Path: 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 693B928C187 for ; Tue, 6 Oct 2009 03:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=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 Gq75TfrXbKrG for ; Tue, 6 Oct 2009 03:48:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 102D728C184 for ; Tue, 6 Oct 2009 03:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=23302; q=dns/txt; s=sjiport01001; t=1254826191; x=1256035791; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Vince=20Fuller=20|Subject:=20upda ted=20LISP-MS=20document=20-=20draft-ietf-lisp-ms-04.txt |Date:=20Tue,=206=20Oct=202009=2003:41:52=20-0700 |Message-ID:=20<20091006104152.GA16884@vaf-lnx1>|To:=20li sp@ietf.org|MIME-Version:=201.0; bh=XWwnq4JiBvmUMIHY7R9sSJelzy4vU5av+8j1/TMgAUw=; b=luiH5LJNfj0afnAKUh0mljY+Bj1yPZyzuh6ZG2hBri+/IY9O6A0htVjt mzVXBY95jc2deb4ZNJPGhkUqZNf6atbta6FtxaD0q3UlPkFhNrqqSHstz RN7yXvCCNBEI3G/xGAUx82p/s6Q3VxXfN8OdMVUnRuJScoWJsu596bBd0 0=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (partially verified [23276 bytes] [TEST]) header.i=vaf@cisco.com X-Files: draft-ietf-lisp-ms-04.txt : 21854 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHq9ykqrR7O6/2dsb2JhbAC7NohjAY8WBoQq X-IronPort-AV: E=Sophos;i="4.44,512,1249257600"; d="txt'?scan'208";a="251494161" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 06 Oct 2009 10:49:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n96AnoDr014264 for ; Tue, 6 Oct 2009 03:49:50 -0700 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n96AnoXt015336 for ; Tue, 6 Oct 2009 10:49:50 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-4) with ESMTP id n96AfqjV017288 for ; Tue, 6 Oct 2009 03:41:52 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n96AfqmQ017285 for lisp@ietf.org; Tue, 6 Oct 2009 03:41:52 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 6 Oct 2009 03:41:52 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20091006104152.GA16884@vaf-lnx1> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=23276; t=1254826190; x=1255690190; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20updated=20LISP-MS=20document=20-=20draft-ietf-l isp-ms-04.txt |Sender:=20; bh=1v36lLjy3EIl3XrvzGtqCI8xx89qemxY1ERpe9mFBKs=; b=YGzNcEwL3Yikb+gcY32tT/6jAClm5d7AX7aHdcBErLleNJRRq3vP7F1OJD LvCWVpmUCnMIik6qZ4PCdn0A2k+ZUCBkW0b0a6apLY+cxDA8fMuguO73wFE2 qBO+E2KdCT; Subject: [lisp] updated LISP-MS document - draft-ietf-lisp-ms-04.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 10:48:16 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This version updates LISP-MS to correspond to draft-ietf-lisp-05.txt. The notable changes are: 1. IPSec AH is no longer used. Map-Register messages now include an authentication field, which is a hash of the msssage using either HMAC-SHA-1-96 (MUST) or HMAC-SHA-128-256 (SHOULD). 2. Encapsulated Map Reqeuests now use UDP port 4342 instead of UDP port 4341. The -03 draft was intended to implement these changes but was incomplete. --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-ietf-lisp-ms-04.txt" Network Working Group V. Fuller Internet-Draft D. Farinacci Intended status: Experimental cisco Systems Expires: April 8, 2010 October 5, 2009 LISP Map Server draft-ietf-lisp-ms-04.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 8, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Fuller & Farinacci Expires April 8, 2010 [Page 1] Internet-Draft LISP Map Server October 2009 Abstract This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Interactions With Other LISP Components . . . . . . . . . . . 7 5.1. ITR EID-to-RLOC Mapping Resolution . . . . . . . . . . . . 7 5.2. ETR/Map-Server EID Prefix Registration . . . . . . . . . . 7 5.3. Map-Server Processing . . . . . . . . . . . . . . . . . . 8 5.4. Map-Resolver Processing . . . . . . . . . . . . . . . . . 8 5.4.1. Anycast Map-Resolver Operation . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Fuller & Farinacci Expires April 8, 2010 [Page 2] Internet-Draft LISP Map Server October 2009 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Fuller & Farinacci Expires April 8, 2010 [Page 3] Internet-Draft LISP Map Server October 2009 2. Introduction LISP [LISP] specifies an architecture and mechanism for replacing the addresses currently used by IP with two separate name spaces: EIDs, used within sites, and RLOCs, used on the transit networks that make up the Internet infrastructure. To achieve this separation, LISP defines protocol mechanisms for mapping from EIDs to RLOCs. In addition, LISP assumes the existence of a database to store and propagate those mappings globally. Several such databases have been proposed, among them: LISP-CONS [CONS], LISP-NERD, [NERD] and LISP+ ALT [ALT], with LISP+ALT being the system that is currently being implemented and deployed on the pilot LISP network. There are two types of operation for a LISP Map-Server: as a Map- Resolver, which accepts Map-Requests from an ITR and "resolves" the EID-to-RLOC mapping using the distributed mapping database, and as a Map-Server, which learns authoratative EID-to-RLOC mappings from an ETR and publish them in the database. A single device may implement one or both types of operation. Conceptually, LISP Map-Servers share some of the same basic configuration and maintenance properties as Domain Name System (DNS) [RFC1035] servers and caching resolvers. With this in mind, this specification borrows familiar terminology (resolver and server) from the DNS specifications. Fuller & Farinacci Expires April 8, 2010 [Page 4] Internet-Draft LISP Map Server October 2009 3. Definition of Terms Map-Server: a network infrastructure component which learns EID-to- RLOC mapping entries from an authoratative source (typically, an ETR, though static configuration or another out-of-band mechanism may be used). A Map-Server publishes these mappings in the distributed mapping database. Map-Resolver: a network infrastructure component which accepts LISP Encapsulated Map-Requests, typically from an ITR, quickly determines whether or not the destination IP address is part of the EID namespace; if it is not, a Negative Map-Reply is immediately returned. Otherwise, the Map-Resolver finds the appropriate EID-to-RLOC mapping by consulting the distributed mapping database system. Encapsulated Map-Request: a LISP Map-Request with an additional LISP header prepended. Sent to UDP destination port 4342. The "outer" addresses are globally-routeable IP addresses, also known as RLOCs. Used by an ITR when sending to a Map-Resolver and by a Map-Server when sending to an ETR. Negative Map-Reply: a LISP Map-Reply that contains an empty locator-set. Returned in response to a Map-Request if the destination EID does not exist in the mapping database. Typically, this means that the "EID" being requested is an IP address connected to a non-LISP site. Map-Register message: a LISP message sent by an ETR to a Map-Server to register its associated EID prefixes. In addition to the set of EID prefixes to register, the message includes one or more RLOCs to be be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please consult the LISP specification [LISP]. Fuller & Farinacci Expires April 8, 2010 [Page 5] Internet-Draft LISP Map Server October 2009 4. Basic Overview A Map-Server is a device which publishes EID-prefix information on behalf of ETRs and connects to the LISP distributed mapping database system to help answer LISP Map-Requests seeking the RLOCs for those EID prefixes. To publish its EID-prefixes, an ETR periodically sends Map-Register messages to the Map-Server. A Map-Register message contains a list of EID-prefixes plus a set of RLOCs that can be used to reach the ETR when a Map-Server needs to forward a Map-Request to it. On the LISP pilot network, which is expected to be a model for deployment of LISP on the Internet, a Map-Server connects to LISP+ALT network and acts as a "last-hop" ALT router. Intermediate ALT routers forward Map-Requests to the Map-Server that advertises a particular EID-prefix and the Map-Server forwards them to the owning ETR, which responds with Map-Reply messages. The LISP Map-Server design also includes the operation of a Map- Resolver, which receives Encapsulated Map-Requests from its client ITRs and uses the distributed mapping database system to find the appropriate ETR to answer those requests. On the pilot network, a Map-Resolver acts as a "first-hop" ALT router. It has GRE tunnels configured to other ALT routers and uses BGP to learn paths to ETRs for different prefixes in the LISP+ALT database. The Map-Resolver uses this path information to forward Map-Requests over the ALT to the correct ETRs. A Map-Resolver may operate in a non-caching mode, where it simply de-capsulates and forwards the Encapsulated Map- Requests that it receives from ITRs. Alternatively, it may operate in a caching mode, where it saves information about oustanding Map- Reqeusts, originates new Map-Requests to the correct ETR(s), accepts and caches the Map-Replies, and finally forwards the Map-Replies to the original ITRs. Note that a single device can implement the functions of both a Map- Server and a Map-Resolver. As is the case with the DNS, however, operational simplicity argues for keeping those functions separate. Fuller & Farinacci Expires April 8, 2010 [Page 6] Internet-Draft LISP Map Server October 2009 5. Interactions With Other LISP Components 5.1. ITR EID-to-RLOC Mapping Resolution An ITR is configured with the address of a Map-Resolver. This address is a "locator" or RLOC in that it must be routeable on the underlying core network; it must not need to be resolved through LISP EID-to-RLOC mapping as that would introduce a circular dependancy. When using a Map-Resolver, an ITR does not need to connect to any other database mapping system. In particular, the ITR need not connect to the LISP+ALT infrastructure or implement the BGP and GRE protocols that it uses. An ITR sends an Encapsulated Map-Request to a configured Map-Resolver when it needs an EID-to-RLOC mapping that is not found in its local map-cache. Using the Map-Resolver greatly reduces both the complexity of the ITR implementation the costs associated with its operation. In response to an Encapsulated Map-Request, the ITR can expect one of the following: o A negative LISP Map-Reply if the Map-Resolver can determine that the requested EID does not exist. The ITR saves EID prefix returned in the Map-Reply in its cache, marking it as non-LISP- capable and knows not to attempt LISP encapsulation for destinations matching it. o A LISP Map-Reply from the ETR that owns the EID-to-RLOC mapping or possibly from a Map-Server answering on behalf of the ETR. Note that the stateless nature of non-caching Map-Resolver forwarding means that the Map-Reply may not be from the Map-Resolver to which the Encapsulated Map-Request was sent unless the target Map- Resolver offers caching (Section 5.4). Note that an ITR may use a Map-Resolver while also participating in another mapping database mechanism. For example, an ITR that runs LISP+ALT can also send Encapsulated Map-Requests to a Map-Resolver. When doing this, an ITR should prefer querying an ETR learned through the ALT network as LISP+ALT provides better information about the set of define EID prefixes. Such a configuration is expected to be very rare, since there is little benefit to using a Map-Resolver if an ITR is already using a mapping database system. 5.2. ETR/Map-Server EID Prefix Registration An ETR publishes its EID prefixes on a Map-Server by sending LISP Map-Register messages. A Map-Register message includes Fuller & Farinacci Expires April 8, 2010 [Page 7] Internet-Draft LISP Map Server October 2009 authentication data, so prior to sending a Map-Register message, the ETR and Map-Server must be configured with a secret shared-key. In addition, a Map-Server will typically perform additional verification checks, such as matching any EID-prefix listed in a Map-Register message against a list of prefixes for which the ETR is known to be an authoritative source. Map-Register messages are sent periodically from an ETR to a Map- Server with a suggested interval between messages of one minute. A Map-Server should time-out and remove an ETR's registration if it has not received a valid Map-Register message within the past three minutes. When first contacting a Map-Server after restart or changes to its EID-to-RLOC database mappings, an ETR may initially send Map- Register messages at an increased frequency, up to one every 20 seconds. This "quick registration" period is limited to five minutes in duration. An ETR which uses a Map-Server to publish its EID-to-RLOC mappings does not need to participate further in the mapping database protocol(s). On the pilot network, for example, this means that the ETR does not need to implement GRE or BGP, which greatly simplifies its configuration and reduces its cost of operation. Note that use of a Map-Server does not preclude an ETR from also connecting to the mapping database (i.e. it could also connect to the LISP+ALT network) but doing so doesn't seem particularly useful as the whole purpose of using a Map-Server is to avoid the complexity of the mapping database protocols. 5.3. Map-Server Processing The operation of a Map-Server, once it has EID-prefixes registered by its client ETRs, is quite simple. In response to a Map-Request (received over the ALT on the pilot network), the Map-Server verifies that the destination EID matches an EID-prefix for which it has one or more registered ETRs, then re-encapsulates and forwards the now- Encapsulated Map-Reqeust to a matching ETR. It does not otherwise alter the Map-Request so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server should never receive Map- Replies; any such messages should be discarded without response, perhaps accompanied by logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic. 5.4. Map-Resolver Processing In response to an Encapsulated Map-Request, a Map-Resolver de- capsulates the message then checks its local database of mapping Fuller & Farinacci Expires April 8, 2010 [Page 8] Internet-Draft LISP Map Server October 2009 entries (statically configured, cached, or learned from associated ETRs). If it finds a matching entry, it returns a non-authoratative LISP Map-Reply with the known mapping. If the Map-Resolver does not have the mapping entry and if it can determine that the requested IP address does not match an EID-prefix in the mapping database, it immediately returns a negative LISP Map- Reply, one which contains an EID prefix and an empty locator-set. To minimize the number of negative cache entries needed by an ITR, the Map-Resolver should return the least-specific prefix which both matches the original query and does not match any EID-prefix known to exist in the LISP-capable infrastructure. If the Map-Resolver does not have sufficient information to know whether the EID exists, it needs to forward the Map-Request to another device which has more information about the EID being requested. This is done in one of two ways: 1. A non-caching Map-Resolver simply forwards the unencapsulated Map-Request, with the original ITR RLOC as the source, on to the distributed mapping database. On the pilot network, the Map- Resolver is connected to the ALT network and sends the Map- Request to the next ALT hop learned from its ALT BGP neighbors. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server which receives the Map-Request over the ALT and responds will do so directly to the ITR. 2. A caching Map-Resolver queues information from the Encapsulated Map-Request, including the ITR RLOC and the original nonce. It then modifies the Map-Request to use its own RLOC, generates a "local nonce" (which is also saved in the request queue entry), and forwards the Map-Request as above. When the Map-Resolver receives a Map-Reply, it looks in its request queue to match the reply nonce to a "local nonce" entry then de-queues the entry and uses the saved original nonce and ITR RLOC to re-write those fields in the Map-Reply before sending to the ITR. The request queue entry is also deleted and the mapping entries from the Map- Reply are saved in the Map-Resolver's cache. 5.4.1. Anycast Map-Resolver Operation A Map-Resolver can be set up to use "anycast", where where the same address is assigned to multiple Map-Resolvers and is propagated through IGP routing, to facilitate the use of a topologically-close Map-Resolver each ITR. Note that Map-Server associations with ETRs should NOT use anycast addresses as doing so could cause unpredictable forwarding of Map-Requests to the ETRs. Fuller & Farinacci Expires April 8, 2010 [Page 9] Internet-Draft LISP Map Server October 2009 6. Security Considerations The 2-way nonce exchange documented in [LISP] can be used to avoid ITR spoofing attacks. To publish an authoratative EID-to-RLOC mapping with a Map-Server, an ETR includes authentication data that is a hash of the message using pair-wise shared key. An implementation MUST support use of HMAC- SHA-1-96 [RFC2404] and SHOULD support use of HMAC-SHA-128-256 [RFC4634]. A key-chaining scheme may also be employed to facilitate re-keying as needed. Fuller & Farinacci Expires April 8, 2010 [Page 10] Internet-Draft LISP Map Server October 2009 7. References 7.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and HMAC-SHA)", RFC 4634, July 2006. 7.2. Informative References [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP-ALT)", draft-ietf-lisp-alt-01.txt (work in progress), March 2009. [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A Content distribution Overlay Network Service for LISP", draft-meyer-lisp-cons-03.txt (work in progress), November 2007. [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-05.txt (work in progress) (work in progress), September 2009. [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-04.txt (work in progress), January 2008. Fuller & Farinacci Expires April 8, 2010 [Page 11] Internet-Draft LISP Map Server October 2009 Appendix A. Acknowledgments The authors would like to thank Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver, and members of the lisp@ietf.org mailing list for their feedback and helpful suggestions. Special thanks are due to Noel Chiappa for his extensive work on caching with LISP-CONS, some of which will be used by Map-Resolvers. Fuller & Farinacci Expires April 8, 2010 [Page 12] Internet-Draft LISP Map Server October 2009 Authors' Addresses Vince Fuller cisco Systems Tasman Drive San Jose, CA 95134 USA Email: vaf@cisco.com Dino Farinacci cisco Systems Tasman Drive San Jose, CA 95134 USA Email: dino@cisco.com Fuller & Farinacci Expires April 8, 2010 [Page 13] --0OAP2g/MAC+5xKAE-- From root@core3.amsl.com Tue Oct 6 04:00:02 2009 Return-Path: X-Original-To: lisp@ietf.org Delivered-To: lisp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2805628C121; Tue, 6 Oct 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091006110002.2805628C121@core3.amsl.com> Date: Tue, 6 Oct 2009 04:00:02 -0700 (PDT) Cc: lisp@ietf.org Subject: [lisp] I-D Action:draft-ietf-lisp-ms-04.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 11:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Map Server Author(s) : V. Fuller, D. Farinacci Filename : draft-ietf-lisp-ms-04.txt Pages : 13 Date : 2009-10-06 This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-lisp-ms-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-06034842.I-D@ietf.org> --NextPart-- From darlewis@cisco.com Fri Oct 9 09:25:57 2009 Return-Path: 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 9637228C132 for ; Fri, 9 Oct 2009 09:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_13=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 SfFRVTTSVyzk for ; Fri, 9 Oct 2009 09:25:56 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9B5973A69C7 for ; Fri, 9 Oct 2009 09:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=1539; q=dns/txt; s=sjiport05001; t=1255105660; x=1256315260; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Darrel=20Lewis=20(darlewis)"=20|Subject:=20FW:=20LISP=20-=20Requested=20sessions=20h ave=20been=20scheduled=20for=20IETF=2076=20|Date:=20Fri, =209=20Oct=202009=2009:27:40=20-0700|Message-ID:=20|To:=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable; bh=MAPO2NiivgC90uv1Krt20t9EOeQUyq3lX4rtEN4Oj8Q=; b=pfkbaizSBBJxadX6MMEW2xZYc7jcXUwG80/JEF0Uh18VBMZZM2SRh/+H eI4nZXIVGPVaA8OV6y5Tz/pg+SeQB3HI2CXq7ZdFgL0h1Q7zOYHM19OWo LKBxR4U7UQh8q1JslDCNfThK4dg00g5OUjzM0yBaMh2fmxizkgRlAsDp+ A=; Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKoBz0qrRN+J/2dsb2JhbADDDphDhCwEgVg X-IronPort-AV: E=Sophos;i="4.44,533,1249257600"; d="scan'208";a="98100732" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Oct 2009 16:27:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id n99GRfds027188 for ; Fri, 9 Oct 2009 16:27:41 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 09:27:40 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 9 Oct 2009 09:27:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LISP - Requested sessions have been scheduled for IETF 76 Thread-Index: AcpGKrDGJGOTzUF5Tg2xW8EUneQ3iAC0nM6Q From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 09 Oct 2009 16:27:40.0982 (UTC) FILETIME=[6C073D60:01CA48FD] Subject: [lisp] FW: LISP - Requested sessions have been scheduled for IETF 76 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 16:25:57 -0000 All, We've asked for an been approved for two sessions in Hiroshima. Please send agenda requests to the chairs. Thanks, -Darrel=20 -----Original Message----- From: IETF Secretariat [mailto:agenda@ietf.org]=20 Sent: Monday, October 05, 2009 7:13 PM To: Darrel Lewis (darlewis) Cc: hartmans-ietf@mit.edu; Ralph Droms (rdroms); jari.arkko@piuha.net; session-request@ietf.org Subject: LISP - Requested sessions have been scheduled for IETF 76=20 Dear Darrel Lewis, The sessions that you have requested have been scheduled. Below is the scheduled session information followed by=20 the information of sessions that you have requested. LISP Session 1 (2 hours) Thursday, Morning Session I 0900-1130 Room Name: Orchid 2 ---------------------------------------------- LISP Session 2 (2 hours) Friday, Morning Session I 0900-1130 Room Name: Orchid 3 ---------------------------------------------- Requested Information: --------------------------------------------------------- Working Group Name: lisp Area Name: Internet Area Session Requester: Darrel Lewis Number of Sessions: 2 Length of Session(s): 2 hours 2 hours =20 Number of Attendees: 150 Conflicts to Avoid: First Priority: saag sasl kitten krb-wg idr grow pim behave Second Priority: mpls isis opsec rtgwg rtgarea v6ops l2vpn l3vpn 6man Third Priority: msec mboned shim6 hip Special Requests: =20 --------------------------------------------------------- From hartmans@mit.edu Fri Oct 9 13:19:19 2009 Return-Path: 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 65F203A6966 for ; Fri, 9 Oct 2009 13:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 82olZT5V6ZLh for ; Fri, 9 Oct 2009 13:19:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8BD773A65A6 for ; Fri, 9 Oct 2009 13:19:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id AE78A2045C; Fri, 9 Oct 2009 16:21:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9C43F445B; Fri, 9 Oct 2009 16:20:48 -0400 (EDT) To: Luigi Iannone References: <4AB9B6BE.6070006@cisco.com> From: Sam Hartman Date: Fri, 09 Oct 2009 16:20:48 -0400 In-Reply-To: (Luigi Iannone's message of "Sat\, 26 Sep 2009 13\:21\:55 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olivier Bonaventure , lisp@ietf.org Subject: Re: [lisp] Call for interest in working on security 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 20:19:19 -0000 >>>>> "Luigi" == Luigi Iannone writes: Luigi> Coming back to you page, I really think that we should Luigi> analyze the mapping system from the inside. What I mean is Luigi> that we do not need to analyze the ALT, or whatever mapping Luigi> system you like, the most appropriate approach is IMO to Luigi> give a set "guidelines/requirements" (I do not have a Luigi> better word right now) for designing a mapping system. I agree we should do this. I think that it's even one of our charter deliverables. Luigi> Discussing if ALT provides the same level of security like Luigi> BGP is IMHO a waste of time. Well, we're also trying to build something practical here. It's all well and good to write up requirements: I certainly have done it many times myself and expect to participate in work of this type in LISP. However, I'm also trying to be practical in a number of ways: * I'm guessing some of the results of the security analysis--I'm guessing we're going to decide that mapping integrity is the big deal for a mapping system. * I'm guessing that designing a PKI for a mapping system may be out of scope for our current efforts * I'm guessing that mandatory-to-use PKIs will not gain consensus in this WG (I doubt I'd support them and I'm fairly pro-security for our population) * However, we need to make sure that absent such a PKI, the mapping system is not worse than today's internet. I don't see how to deal with the last point without getting into the details of alt. Remember also that we're trying to run experiments. * I want to get to a point where I know if alt is secure enough that I'm willing to run my day-to-day traffic over it. I understand some people do, but I need to understand its security properties before I will. * We want to make sure that our experimental results are useful. That means we need our security mechanisms present at least enough to understand their performance impact etc. So, I think we need to dig into the details of alt a bit. Not to develop requirements, but 1) to understand whether alt meets the requirements we do develop 2) to make it good enough for the experiments. Finally, I think I need to motivate my list of threats. I think I should have to answer the question of "why isn't this a problem on the Internet today?" From hartmans@mit.edu Fri Oct 9 14:03:28 2009 Return-Path: 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 C2EA628C1BD for ; Fri, 9 Oct 2009 14:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 2qN0Yak36m2M for ; Fri, 9 Oct 2009 14:03:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id CAD4C28C1AE for ; Fri, 9 Oct 2009 14:03:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F255E202F2; Fri, 9 Oct 2009 17:05:12 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C6837445B; Fri, 9 Oct 2009 17:04:57 -0400 (EDT) To: Luigi Iannone References: <4AB9B6BE.6070006@cisco.com> From: Sam Hartman Date: Fri, 09 Oct 2009 17:04:57 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Olivier Bonaventure , lisp@ietf.org Subject: [lisp] Comments on draft-saucez-lisp-security-00 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Oct 2009 21:03:28 -0000 Hi. I agree with the goals of the approach you're taking as something we should do. I think that my effort and yours can proceed in parallel adapting information from each other. They may merge some day, although I think right now that the taxonomy I'm taking is somewhat different and I don't think it would make sense to merge at this point. One thing I think it would be valuable to adopt is to set out some high level goals for LISP security; perhaps you could use something similar to mine, or describe your own. My high level goals follow: * LISP will not make Internet security worse * LISP will not create an architecture in which ongoing IETF-wide security goals such as the SIDR working group or BCP 84 are made more difficult. The big question is what does it mean to make the Internet security worse and what is the current security model of the Internet. In answering these sorts of questions, Then, I recommend referencing your requirements back to these goals. Section 4.1 When you talk about security of the data stream, what security services are you talking about? Confidentiality? Integrity? Peer entity authentication? Where do these requirements come from for LISP as a routing scalability solution? Why would you propose IPsec inside the tunnel to secure LISP rather than IPsec outside the tunnel? Section 4.2 discusses packet spoofing. How is the work in SAVI applicable? I cannot figure out how to apply what I know of SAVI to LISP? Section 4.3 proposes that the nonce is similar to the L2TP cookie. How is that true? The L2TP cooking is a cookie established between two peers to prevent off-path attacks. If a packet is included in an L2TP tunnel with an improper cookie, that packet is discarded. In what circumstances is a 24-bit nonce long enough to provide protection? In what circumstances can an ETR discard a packet based on a nonce? Section 4.4.1: Another important attack is DOS attacks based on rloc entries. Take a look at the mip6 route optimization security analysis. One attack is to set up a very high bandwidth flow to EIDs you own. Then update your mapping redirecting some or all of that traffic off to some unsuspecting person. This is the attack that motivates the requirement that someone with an RLOC prove that they actually want to accept traffic before you redirect to them. Section 4.6.2: How will ignoring the loc reach bits if nonce/versioning did not change help? Wouldn't an attacker change the nonce/version? Section 4.6.3: How do you deal with missing packets/version numbers changing rapidly enough that one ETR doesn't see a packet of a particular version? Section 4.6.4: How can filtering spoofed EIDs on the ITR remove cache poisoning? How do you actually filter out spoofed EIDs/identify them? Section 4.6.6: How do PITRs effectively filter? What does requiring a source EID be in the mapping cache on the *ETR* accomplish? Section 5.2: I think that there are some significant deployment considerations that generate requirements. For example I think we need a level of security similar to what we get on the Internet today if two clients of the mapping system do not share trust anchors for public-key operations. I think it is reasonable to assume that an ITR and its map resolver share trust, an ETR and a map server share trust. However I think we want to do at least as well as the internet does today without requiring more trust. From hartmans@mit.edu Mon Oct 12 11:34:56 2009 Return-Path: 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 CEF8028C2A1 for ; Mon, 12 Oct 2009 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 rknGc9rIsF0G for ; Mon, 12 Oct 2009 11:34:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B39C628C2A0 for ; Mon, 12 Oct 2009 11:34:54 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DC0BA20356; Mon, 12 Oct 2009 14:34:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D677B445B; Mon, 12 Oct 2009 14:34:53 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 12 Oct 2009 14:34:53 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: marcelo@it.uc3m.es Subject: [lisp] Please read draft-bagnulo-lisp-threat-01.txt 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 18:34:56 -0000 Luigi's security draft contained a reference to Marcelo's earlier threat analysis which I at least had never run across. It's excellent work and I'd strongly encourage everyone in the WG to read it. Stylistically it does a good job of motiving the attack and providing enough detail to explain why the attack is realistic/when the attack is realistic. The draft is somewhat dated. It analyzes LISP 1 (routable EIDs) not LISP 1.5 (what we're doing, I think). Also, several of the attacks described there have been fixed. For example, we have much stronger wording about the problems of gleaning and I think we may even have a consensus that data gleaning is inappropriate for Internet contexts. Also, some of the details have changed. However some of the attacks described seem alive and well against current LISP and definitely seem like the sorts of things we'll need to fix. So, between be an excellent example of how to go about this sort of analysis and containing still-important information for today's LISP, I think it is well worth the read if you have not done so. However, before drawing conclusions, make sure they are still accurate for the LISP of 2009 instead of the LISP of 2007. From darlewis@cisco.com Tue Oct 13 10:34:31 2009 Return-Path: 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 9DC1F3A691B for ; Tue, 13 Oct 2009 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mDI7z-vS4hIK for ; Tue, 13 Oct 2009 10:34:30 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id BAA323A690C for ; Tue, 13 Oct 2009 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=343; q=dns/txt; s=sjiport02001; t=1255455272; x=1256664872; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Darrel=20Lewis=20(darlewis)"=20|Subject:=20Reminder:=20Upcoming=20Draft=20Deadlines |Date:=20Tue,=2013=20Oct=202009=2010:34:31=20-0700 |Message-ID:=20|To:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=nsOJ9Ipkh1ITfiaBsmjRXiNyAe0qnSJ1PTO9GVoNHsQ=; b=AbeOu6NnpFABos62b9neJHMd5Wb4Dsq5Wj7bE7NKewRsLnZHk/EbWhE/ FBnc75zBkegVDt1B4YZxdlBsMJHjY3YU0VzyLHtEj60keIuL5/MvO68ia VszeZSTp8ulJlUh/u35tYlPNP5GEBXpV24KEsIjtbFwxbPATa91agp5/r g=; Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF9X1EqrR7H+/2dsb2JhbADBHZgShC0E X-IronPort-AV: E=Sophos;i="4.44,551,1249257600"; d="scan'208";a="214036005" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 13 Oct 2009 17:34:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9DHYWi7014312 for ; Tue, 13 Oct 2009 17:34:32 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Oct 2009 10:34:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Oct 2009 10:34:31 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: Upcoming Draft Deadlines Thread-Index: AcpMK2viCdXk1xOwQw6ZIViGYs8ohA== From: "Darrel Lewis (darlewis)" To: X-OriginalArrivalTime: 13 Oct 2009 17:34:32.0076 (UTC) FILETIME=[6C7A9CC0:01CA4C2B] Subject: [lisp] Reminder: Upcoming Draft Deadlines 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 17:34:31 -0000 Hi all, as a reminder: Monday, October 19th is the new (-00) draft deadline Monday, October 26th the deadline for updates to existing drafts At this time I haven't received any requests for agenda items, but I'm aware of several potential candidate topics. Please get your requests for time in as soon as possible. =20 -Darrel From hartmans@mit.edu Wed Oct 14 12:11:24 2009 Return-Path: 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 468D128C1EF for ; Wed, 14 Oct 2009 12:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 JI3NIJ-hLiRz for ; Wed, 14 Oct 2009 12:11:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 6F32428C145 for ; Wed, 14 Oct 2009 12:11:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 73647203CF; Wed, 14 Oct 2009 15:11:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 71505413F; Wed, 14 Oct 2009 15:11:16 -0400 (EDT) To: "Darrel Lewis \(darlewis\)" References: From: Sam Hartman Date: Wed, 14 Oct 2009 15:11:16 -0400 In-Reply-To: (Darrel Lewis's message of "Tue\, 13 Oct 2009 10\:34\:31 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: [lisp] Requesting time to discuss my proposed security model 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 19:11:24 -0000 [Speaking very much as an individual] I've started a wiki page at http://tools.ietf.org/wg/lisp/trac/wiki/Security01 . I hope to flesh it out this weekend enough to have something worth discussing at the IETf meeting. I'd like to request time to start discussing this topic. I think WG time could best be used discussing the goals of LISP security--what we're trying to accomplish-- and possibly to give some examples of attacks. After this weekend I'll have a good idea of how much time I could use. Luigi and some other folks are working on a different proposal for how to think about LISP security. We should poll them to figure out if they want time as well. I think the approaches are different enough that combining these may not make sense at this point in the process. From hartmans@mit.edu Wed Oct 14 12:13:28 2009 Return-Path: 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 5042F28C1E8 for ; Wed, 14 Oct 2009 12:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] 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 gFAipGX4Yw1P for ; Wed, 14 Oct 2009 12:13:27 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1583D28C1F3 for ; Wed, 14 Oct 2009 12:13:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 863AD20356 for ; Wed, 14 Oct 2009 15:13:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B0FCA413F; Wed, 14 Oct 2009 15:13:22 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Wed, 14 Oct 2009 15:13:22 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Second call for Agenda items 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 19:13:28 -0000 This time speaking as a chair. Darrel posted a call for agenda items, but it iwsa in a message about draft deadlines. Please, get agenda requests to the chairs. We're meeting on the 20th to discuss the agenda so it will be easier if we have your request before then. Obviously we may be putting together topics of our own to discuss open issues and things that might help move our efforts forward. From darlewis@cisco.com Wed Oct 14 12:15:03 2009 Return-Path: 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 B524D3A68EC for ; Wed, 14 Oct 2009 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DToIyKFVUBVo for ; Wed, 14 Oct 2009 12:15:02 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C75D33A6405 for ; Wed, 14 Oct 2009 12:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=1362; q=dns/txt; s=sjiport06001; t=1255547705; x=1256757305; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Darrel=20Lewis=20(darlewis)"=20|Subject:=20RE:=20Requesting=20time=20to=20discuss=20 my=20proposed=20security=20model|Date:=20Wed,=2014=20Oct =202009=2012:15:04=20-0700|Message-ID:=20|To: =20"Sam=20Hartman"=20|Cc:=20|MIME-Version:=201.0|Content-Transfer-Encoding: =20quoted-printable|In-Reply-To:=20|References:=20=20; bh=fOjEgFolkDPkoGqolIvX9E2jvznkEqoqw/B4cidX7mI=; b=hWnMzmb1OcA3H248ZYOwFllXbgBz2oXcSHAiy6OLuI8fYprX4IEQFWxe 7lvKUHauQf4y57WvGGIICtZwIkiEtPvKsrrlsPqvozWhXEWcHhxkO8MVx FhnKV8ZzAL2sngbdZx/LUACPaLre9073K+T0/CfciQLvuMfskJ0m52sVQ g=; Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIvA1UqrR7Ht/2dsb2JhbADCIJhmhC4Eim0 X-IronPort-AV: E=Sophos;i="4.44,560,1249257600"; d="scan'208";a="409348025" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 14 Oct 2009 19:15:05 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EJF5bK026160; Wed, 14 Oct 2009 19:15:05 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Oct 2009 12:15:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Oct 2009 12:15:04 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requesting time to discuss my proposed security model Thread-Index: AcpNAh7BrP5uHobGRxioVYIrtwgcEwAABmCA References: From: "Darrel Lewis (darlewis)" To: "Sam Hartman" X-OriginalArrivalTime: 14 Oct 2009 19:15:05.0232 (UTC) FILETIME=[A2EEE900:01CA4D02] Cc: lisp@ietf.org Subject: Re: [lisp] Requesting time to discuss my proposed security model 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 19:15:03 -0000 =20 > [Speaking very much as an individual] >=20 >=20 >=20 > I've started a wake page at > http://tools.ietf.org/wg/lisp/trac/wiki/Security01 . I hope to flesh > it out this weekend enough to have something worth discussing at the > IETF meeting. I'd like to request time to start discussing=20 > this topic. Sounds good. >=20 > I think WAG time could best be used discussing the goals of LISP > security--what we're trying to accomplish-- and possibly to give some > examples of attacks. >=20 I agree that face to face time is going to be best used getting on the same page about the overall goals of security in LISP. I might suggest organizing your approach to articulating those goals in a way to limit the scope of the discussions. An obvious first step is data-plane, control plane, and device/infrastructure security. > After this weekend I'll have a good idea of how much time I could use. >=20 Sounds good. > Luigi and some other folks are working on a different proposal for how > to think about LISP security. We should poll them to figure out if > they want time as well. I think the approaches are different enough > that combining these may not make sense at this point in the process. >=20 I'd really like to keep them engaged, so soliciting them directly would be a great thing. -Darrel From hartmans@mit.edu Mon Oct 19 08:51:17 2009 Return-Path: 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 2EF9C3A68AC for ; Mon, 19 Oct 2009 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 qgu9+EAeZPtJ for ; Mon, 19 Oct 2009 08:51:16 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 8AF873A68F8 for ; Mon, 19 Oct 2009 08:51:16 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 284792003E for ; Mon, 19 Oct 2009 11:51:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ABE28446F; Mon, 19 Oct 2009 11:51:19 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 19 Oct 2009 11:51:19 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Who is affected by the RRG LISP conflict Friday morning 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 15:51:17 -0000 Scott Brim points out that the second session of LISP is scheduled opposite the RRG Friday morning. Who here will be negatively affected by that conflict? (In parallel, I'm looking at options for deconflicting, but one input into that process is information about how bad the conflict is.) Darrel and I will coordinate and get approval from Jari before making any changes. From lixia@cs.ucla.edu Mon Oct 19 09:04:08 2009 Return-Path: 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 548413A679C for ; Mon, 19 Oct 2009 09:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 5NPGr8lpTn8X for ; Mon, 19 Oct 2009 09:04:07 -0700 (PDT) Received: from smtp.cs.ucla.edu (smtp.cs.ucla.edu [131.179.128.62]) by core3.amsl.com (Postfix) with ESMTP id 94D5B3A6899 for ; Mon, 19 Oct 2009 09:04:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D30F339E80CF; Mon, 19 Oct 2009 09:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D85SDd6MCFWG; Mon, 19 Oct 2009 09:04:10 -0700 (PDT) Received: from host76.nanog.merit.net (host76.nanog.merit.net [192.35.164.145]) by smtp.cs.ucla.edu (Postfix) with ESMTP id B6BAD39E80B1; Mon, 19 Oct 2009 09:04:09 -0700 (PDT) Message-Id: From: Lixia Zhang To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Oct 2009 09:04:08 -0700 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Who is affected by the RRG LISP conflict Friday morning 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:04:08 -0000 On Oct 19, 2009, at 8:51 AM, Sam Hartman wrote: > Scott Brim points out that the second session of LISP is scheduled > opposite the RRG Friday morning. Who here will be negatively affected > by that conflict? > > (In parallel, I'm looking at options for deconflicting, but one input > into that process is information about how bad the conflict is.) > > Darrel and I will coordinate and get approval from Jari before making > any changes. speaking for myself: the answer probably depends on what's on the RRG agenda. as guilty as I felt: it has not been nailed down yet. Better later than never, we do plan to catch up ASAP I do agree with Scott B that this conflict needs to be resolved. Lixia From ear@intron.com.br Mon Oct 19 10:42:33 2009 Return-Path: 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 94DFB3A69B5 for ; Mon, 19 Oct 2009 10:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] 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 WK+C1VXPOEIb for ; Mon, 19 Oct 2009 10:42:32 -0700 (PDT) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 54DAE3A6954 for ; Mon, 19 Oct 2009 10:42:29 -0700 (PDT) Received: by ywh13 with SMTP id 13so6448225ywh.29 for ; Mon, 19 Oct 2009 10:42:33 -0700 (PDT) MIME-Version: 1.0 Sender: ear@intron.com.br Received: by 10.150.26.3 with SMTP id 3mr8586175ybz.69.1255974153199; Mon, 19 Oct 2009 10:42:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 19 Oct 2009 15:42:33 -0200 X-Google-Sender-Auth: 27c53a1c8db2c239 Message-ID: <45e3c45f0910191042n6a0494ebke8d0673fbfc69f2c@mail.gmail.com> From: =?ISO-8859-1?Q?Eduardo_Ascen=E7o_Reis?= To: Sam Hartman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: lisp@ietf.org Subject: Re: [lisp] Who is affected by the RRG LISP conflict Friday morning 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 17:48:12 -0000 Hi Sam, I agree that it would be better to avoid this conflict. Thanks, --=20 Eduardo Ascen=E7o Reis From jmh@joelhalpern.com Mon Oct 19 11:01:43 2009 Return-Path: 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 7883528C10B for ; Mon, 19 Oct 2009 11:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] 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 rM5J2f4bQVvi for ; Mon, 19 Oct 2009 11:01:42 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D016928C0DD for ; Mon, 19 Oct 2009 11:01:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 442B63231832; Mon, 19 Oct 2009 11:01:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-68.clppva.btas.verizon.net [71.161.50.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id BFFD6323181F; Mon, 19 Oct 2009 11:01:49 -0700 (PDT) Message-ID: <4ADCA98E.70202@joelhalpern.com> Date: Mon, 19 Oct 2009 14:01:50 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lisp@ietf.org Subject: Re: [lisp] Who is affected by the RRG LISP conflict Friday morning 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:01:43 -0000 That would be really bad for me. Please fix! Joel Sam Hartman wrote: > Scott Brim points out that the second session of LISP is scheduled > opposite the RRG Friday morning. Who here will be negatively affected > by that conflict? > > (In parallel, I'm looking at options for deconflicting, but one input > into that process is information about how bad the conflict is.) > > Darrel and I will coordinate and get approval from Jari before making > any changes. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From Fred.L.Templin@boeing.com Mon Oct 19 11:24:26 2009 Return-Path: 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 B3EED3A6954 for ; Mon, 19 Oct 2009 11:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ueQU19eaXBN0 for ; Mon, 19 Oct 2009 11:24:26 -0700 (PDT) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 03ED23A6781 for ; Mon, 19 Oct 2009 11:24:25 -0700 (PDT) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id n9JIOMe1003920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 11:24:23 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id n9JIOLgn012566; Mon, 19 Oct 2009 13:24:21 -0500 (CDT) Received: from XCH-NWHT-08.nw.nos.boeing.com (xch-nwht-08.nw.nos.boeing.com [130.247.25.112]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id n9JIOLni012549 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 19 Oct 2009 13:24:21 -0500 (CDT) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.104]) by XCH-NWHT-08.nw.nos.boeing.com ([130.247.25.112]) with mapi; Mon, 19 Oct 2009 11:24:21 -0700 From: "Templin, Fred L" To: Sam Hartman , "lisp@ietf.org" Date: Mon, 19 Oct 2009 11:24:18 -0700 Thread-Topic: [lisp] Who is affected by the RRG LISP conflict Friday morning Thread-Index: AcpQ1AirltMlbe4vRByiPLT3luWNnQAFSPDA Message-ID: <12F4112206976147A34FEC0277597CCF27A41AC578@XCH-NW-15V.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.0.0.1181-5.600.1016-16956.005 x-tm-as-result: No--47.677300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] Who is affected by the RRG LISP conflict Friday morning 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 18:24:26 -0000 Having already made plans around an all-day RRG meeting on Friday, I don't think its right to have these two meetings conflict. Fred fred.l.templin@boeing.com > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On Behalf Of S= am Hartman > Sent: Monday, October 19, 2009 8:51 AM > To: lisp@ietf.org > Subject: [lisp] Who is affected by the RRG LISP conflict Friday morning >=20 > Scott Brim points out that the second session of LISP is scheduled > opposite the RRG Friday morning. Who here will be negatively affected > by that conflict? >=20 > (In parallel, I'm looking at options for deconflicting, but one input > into that process is information about how bad the conflict is.) >=20 > Darrel and I will coordinate and get approval from Jari before making > any changes. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Mon Oct 19 14:02:26 2009 Return-Path: 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 A99C13A6977 for ; Mon, 19 Oct 2009 14:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 DjqaU-mxi-Gk for ; Mon, 19 Oct 2009 14:02:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ED84C3A683C for ; Mon, 19 Oct 2009 14:02:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B5D1E202F2 for ; Mon, 19 Oct 2009 17:02:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 123EB446F; Mon, 19 Oct 2009 17:02:21 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Mon, 19 Oct 2009 17:02:21 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] http://tools.ietf.org/wg/lisp/trac/wiki/Security01 with significantly more detail 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:02:26 -0000 Folks, in preparation for our meeting in Japan, I have written up a lot more of my comments on security. The current page should be sufficicent for you to review the approach I'm proposing for control plane security and also has a reading list to come up to speed to discuss previous work in the IETF on address mapping security. There has been a lot of thought put into things like this and I think we have a lot to study. I'm hoping that the control plane approach is clear enough that people can review it and possibly join the effort. I'd like to present some of this in Japan. It would be greate if people could come to the meeting having read this proposal and ready to comment. It would of course also be great if people comment before:-) From hartmans@mit.edu Wed Oct 21 10:33:33 2009 Return-Path: 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 C6E793A68F8 for ; Wed, 21 Oct 2009 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] 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 wkbTsmjKwtgR for ; Wed, 21 Oct 2009 10:33:33 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 264B23A67E3 for ; Wed, 21 Oct 2009 10:33:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-18-111-16-52.dyn.mit.edu [18.111.16.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8CE612003E for ; Wed, 21 Oct 2009 13:33:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3BEA1446D; Wed, 21 Oct 2009 13:33:38 -0400 (EDT) To: lisp@ietf.org From: Sam Hartman Date: Wed, 21 Oct 2009 13:33:38 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:33:33 -0000 So far the news is not encouraging for moving LISP away from the RRG. Darrel and I are working on structuring the agenda to minimize impact if people need to skip the Friday session in order to attend the RRG. From mrw@sandstorm.net Wed Oct 21 10:37:52 2009 Return-Path: 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 F18583A67F7 for ; Wed, 21 Oct 2009 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 VkkH5KCkXqmK for ; Wed, 21 Oct 2009 10:37:51 -0700 (PDT) Received: from sirocco.sandstorm.net (sirocco.sandstorm.net [69.33.111.75]) by core3.amsl.com (Postfix) with ESMTP id 267F03A67E3 for ; Wed, 21 Oct 2009 10:37:50 -0700 (PDT) Received: from [10.2.0.20] (ip-69-33-111-74.bos.megapath.net [69.33.111.74]) (authenticated bits=0) by sirocco.sandstorm.net (8.13.8/8.13.3) with ESMTP id n9LHbpmr005104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Oct 2009 13:37:51 -0400 (EDT) (envelope-from mrw@sandstorm.net) Message-Id: <12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net> From: Margaret Wasserman To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Oct 2009 13:37:51 -0400 References: X-Mailer: Apple Mail (2.936) Cc: lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 17:37:52 -0000 Do we actually need two sessions if one of them is going to conflict with the RRG? Or will we have enough people missing that it would be better to just have a single session? Margaret On Oct 21, 2009, at 1:33 PM, Sam Hartman wrote: > > > So far the news is not encouraging for moving LISP away from the RRG. > > Darrel and I are working on structuring the agenda to minimize impact > if people need to skip the Friday session in order to attend the RRG. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From darlewis@cisco.com Wed Oct 21 12:01:26 2009 Return-Path: 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 F03CC28C137 for ; Wed, 21 Oct 2009 12:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 OVtunDxSXtvh for ; Wed, 21 Oct 2009 12:01:25 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 902D93A6A14 for ; Wed, 21 Oct 2009 12:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=1334; q=dns/txt; s=sjiport01001; t=1256151678; x=1257361278; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Darrel=20Lewis=20(darlewis)"=20|Subject:=20RE:=20[lisp]=20Update=20on=20moving=20LIS P|Date:=20Wed,=2021=20Oct=202009=2012:01:00=20-0700 |Message-ID:=20|To:=20"Margaret=20Wasserman"=20 ,=0D=0A=20=20=20=20=20=20=20=20"Sam=20 Hartman"=20|Cc:=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|In-Reply-To:=20<12C05055-3130-4FB0-B491-3561B40 C4E00@sandstorm.net>|References:=20=20<12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net >; bh=Kd2jXjY2RdAwacujMzYHampJkUvuNe9WItzVUn/QPgs=; b=ncJ9HcYfyi2WITueWiLSybJPyAfHmNCu1YBJLVTTyelS73VpMKDZMs7h 3YpZF8FBNrfIVQlQetytU+a4hRwXp16FA6eAzpdU0As1HVjMi0YFpVvlI vBBUoW7FKBTBtOzqYvMsmSvtJ2gzmCm4xn/o8fAUl5nSw5bapuxjV8ijz E=; Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFX33kqrR7H+/2dsb2JhbADDOJhlhDEEiwM X-IronPort-AV: E=Sophos;i="4.44,599,1249257600"; d="scan'208";a="259415149" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 21 Oct 2009 19:00:58 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9LJ0wwZ014478; Wed, 21 Oct 2009 19:00:58 GMT Received: from xmb-sjc-213.amer.cisco.com ([171.70.151.153]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 12:00:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 12:01:00 -0700 Message-ID: In-Reply-To: <12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [lisp] Update on moving LISP Thread-Index: AcpSdT6zPJkIVH6sQEOQO7X1rxq4fQACknsg References: <12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net> From: "Darrel Lewis (darlewis)" To: "Margaret Wasserman" , "Sam Hartman" X-OriginalArrivalTime: 21 Oct 2009 19:00:58.0274 (UTC) FILETIME=[D2FFA020:01CA5280] Cc: lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 19:01:26 -0000 My initial thoughts are that we will need the extra time to get everything we'd like to do done. We'll publish a draft agenda this week to give people some information on which to base their attendance choices. -Darrel=20 > -----Original Message----- > From: lisp-bounces@ietf.org [mailto:lisp-bounces@ietf.org] On=20 > Behalf Of Margaret Wasserman > Sent: Wednesday, October 21, 2009 10:38 AM > To: Sam Hartman > Cc: lisp@ietf.org > Subject: Re: [lisp] Update on moving LISP >=20 >=20 > Do we actually need two sessions if one of them is going to conflict =20 > with the RRG? Or will we have enough people missing that it=20 > would be =20 > better to just have a single session? >=20 > Margaret >=20 > On Oct 21, 2009, at 1:33 PM, Sam Hartman wrote: >=20 > > > > > > So far the news is not encouraging for moving LISP away=20 > from the RRG. > > > > Darrel and I are working on structuring the agenda to=20 > minimize impact > > if people need to skip the Friday session in order to=20 > attend the RRG. > > _______________________________________________ > > lisp mailing list > > lisp@ietf.org > > https://www.ietf.org/mailman/listinfo/lisp >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From hartmans@mit.edu Wed Oct 21 14:01:18 2009 Return-Path: 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 0FCF03A697C for ; Wed, 21 Oct 2009 14:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 d80nZP8kz9Ue for ; Wed, 21 Oct 2009 14:01:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3D5D83A697F for ; Wed, 21 Oct 2009 14:01:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 11BBF2003E; Wed, 21 Oct 2009 17:01:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 910D5446D; Wed, 21 Oct 2009 17:01:21 -0400 (EDT) To: Margaret Wasserman References: <12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net> From: Sam Hartman Date: Wed, 21 Oct 2009 17:01:21 -0400 In-Reply-To: <12C05055-3130-4FB0-B491-3561B40C4E00@sandstorm.net> (Margaret Wasserman's message of "Wed\, 21 Oct 2009 13\:37\:51 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:01:18 -0000 >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Do we actually need two sessions if one of them is going Margaret> to conflict with the RRG? Or will we have enough people Margaret> missing that it would be better to just have a single Margaret> session? I think that once Darrel sends out a draft agenda we can look at this and examine in more detail. One of the questions has to do with how much we value getting input on things related to lisp that are not strictly within charter. Darrel convinced me that a number of these areas are valuable. For example, presentations on research results into lisp mapping scaling are not within our charter, but it seems like they might well inform important items within our charter. Things like Lig are useful to think about in terms of lisp debugging. There's a bit more complexity when we get to things like the mobility draft from last agenda. We've reached a point where discussing it as an item to adopt doesn't make sense. However Darrel convinced me that presentations like that make sense in terms of informing people about how people might use LISP. I do agree that there is a lot of variability in how WGs use time. I'm not attached to a particular model. If the WG wants to say something like "using end of session time for some of these tasks is OK, but overflowing is not," then that works for me. AIf the WG wants to say something broader than's great too. Another factor to consider is of course Jari's availability and preferences. For now, Darrel and I are wanting to be relatively broad in what we accept as informational topics in the interest of building a community fostering discussion and establishing shared context about how LISP is used. However if after looking at the agenda, you think we got it wrong, please let us know. From luigi@net.t-labs.tu-berlin.de Fri Oct 23 00:01:10 2009 Return-Path: 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 D515B3A6915 for ; Fri, 23 Oct 2009 00:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 QUMyRR12vBeA for ; Fri, 23 Oct 2009 00:01:10 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 08BF13A68FB for ; Fri, 23 Oct 2009 00:01:09 -0700 (PDT) Received: from [10.117.55.29] (unknown [212.201.107.29]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id 7666E700D282; Fri, 23 Oct 2009 09:01:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Luigi Iannone In-Reply-To: Date: Fri, 23 Oct 2009 09:01:16 +0200 Content-Transfer-Encoding: 7bit Message-Id: <571887B8-D4E7-4023-A09C-FB7DFAC5D2A9@net.t-labs.tu-berlin.de> References: To: Sam Hartman X-Mailer: Apple Mail (2.1076) Cc: lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 07:01:10 -0000 Hi, As you can remember from the discussion on the versioning, the plan were to submit an updated draft (by the cut off date on monday) and have a discussion at the meeting. Since this topic is not urgent and in order to reduce the length of the meeting (avoiding if possible conflict with RRG), we can postpone the versioning discussion to the 77th IETF. Hope this will ease the work of the chairs. Luigi On Oct 21, 2009, at 19:33 , Sam Hartman wrote: > > > So far the news is not encouraging for moving LISP away from the RRG. > > Darrel and I are working on structuring the agenda to minimize impact > if people need to skip the Friday session in order to attend the RRG. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From hartmans@mit.edu Fri Oct 23 05:55:46 2009 Return-Path: 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 429423A6831 for ; Fri, 23 Oct 2009 05:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 G3CbxPKADBst for ; Fri, 23 Oct 2009 05:55:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 750003A657C for ; Fri, 23 Oct 2009 05:55:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 866762032C; Fri, 23 Oct 2009 08:55:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 89BFE446D; Fri, 23 Oct 2009 08:55:51 -0400 (EDT) To: Luigi Iannone References: <0F04DDD8-A0DB-4ECD-A513-F4D6DC942F1A@net.t-labs.tu-berlin.de> From: Sam Hartman Date: Fri, 23 Oct 2009 08:55:51 -0400 In-Reply-To: <0F04DDD8-A0DB-4ECD-A513-F4D6DC942F1A@net.t-labs.tu-berlin.de> (Luigi Iannone's message of "Sat\, 26 Sep 2009 15\:13\:56 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Clarification on issue #16 Map versioning Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 12:55:46 -0000 >>>>> "Luigi" == Luigi Iannone writes: Luigi> New proposed one: Luigi> draft-iannone-lisp-mapping-versioning-00 proposes Luigi> introducing the optional possibility for LISP header to Luigi> transport map version numbers. Luigi will provide a new Luigi> version of the draft which will include both discussion Luigi> from the mailinglist as well as the discussion with all Luigi> LISP developers. This means that all the details of the map Luigi> versioning support will be detailed in the versioning draft Luigi> and not in the main LISP specs. After publication of the Luigi> new map versioning draft, the WG will discuss its technical Luigi> validity and how to proceed with the work. The major intent in my mind when opening issue #16 was to figure out if we had consensus behind text in LISP 04. (We did not and ended up removing the r-bit). The chairs' consensus call on the issue is attached below. >Darrel and I have discussed the resolution of the map versioning >proposal. > >At this point, the WG has not received a request to adopt Luigi's >draft, although he indicated we might receive such a request in the >future. >The chairs believe that we'd need to see somewhat more support for a >specific proposal than we've seen for map versioning to date in order >to adopt that proposal. If we did receive sufficient support to adopt >something as a WG draft, assigning the flag would be easy. So, I think the next step is to update the draft and to when you are ready to ask the WG if it is interested in adopting the work. We'd want to have discussion on the list and probably discussion in a face-to-face meeting. However we definitely can update the description of an issue in the tracker. From hartmans@mit.edu Fri Oct 23 06:27:53 2009 Return-Path: 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 696B13A68D7 for ; Fri, 23 Oct 2009 06:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 29dky8wNyofh for ; Fri, 23 Oct 2009 06:27:52 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BC5903A688D for ; Fri, 23 Oct 2009 06:27:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4FDEE202F2; Fri, 23 Oct 2009 09:28:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1C606446D; Fri, 23 Oct 2009 09:27:58 -0400 (EDT) To: Luigi Iannone References: <571887B8-D4E7-4023-A09C-FB7DFAC5D2A9@net.t-labs.tu-berlin.de> From: Sam Hartman Date: Fri, 23 Oct 2009 09:27:58 -0400 In-Reply-To: <571887B8-D4E7-4023-A09C-FB7DFAC5D2A9@net.t-labs.tu-berlin.de> (Luigi Iannone's message of "Fri\, 23 Oct 2009 09\:01\:16 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 13:27:53 -0000 I definitely think you should submit the updated draft and start a discussion on the list. We can take things from there and look at your item vs other items on the agenda. Factor will include: * What else we schedule * How much response you get on the list * Comments from participants. * Your input From luigi@net.t-labs.tu-berlin.de Mon Oct 26 05:45:17 2009 Return-Path: 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 06CBC28C278 for ; Mon, 26 Oct 2009 05:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 NOJU0iKSmDPy for ; Mon, 26 Oct 2009 05:45:16 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.252]) by core3.amsl.com (Postfix) with ESMTP id 43E3F28C0F0 for ; Mon, 26 Oct 2009 05:45:16 -0700 (PDT) Received: from dyn102.net.t-labs.tu-berlin.de (dyn102.net.t-labs.tu-berlin.de [130.149.220.102]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTP id F085E7067A67; Mon, 26 Oct 2009 13:45:28 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Luigi Iannone In-Reply-To: Date: Mon, 26 Oct 2009 13:45:28 +0100 Content-Transfer-Encoding: 7bit Message-Id: <509C733F-B683-4691-A55C-CE13B391D6B0@net.t-labs.tu-berlin.de> References: <571887B8-D4E7-4023-A09C-FB7DFAC5D2A9@net.t-labs.tu-berlin.de> To: Sam Hartman X-Mailer: Apple Mail (2.1076) Cc: lisp@ietf.org Subject: Re: [lisp] Update on moving LISP 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:45:17 -0000 Thanks Sam, I will follow the steps you suggest, but not for Hiroshima. I think there is very little time. Ciao Luigi On Oct 23, 2009, at 15:27 , Sam Hartman wrote: > I definitely think you should submit the updated draft and start a > discussion on the list. > We can take things from there and look at your item vs other items > on the agenda. > Factor will include: > * What else we schedule > * How much response you get on the list > * Comments from participants. > * Your input From hannu.flinck@nsn.com Tue Oct 27 05:35:55 2009 Return-Path: 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 9384328C187 for ; Tue, 27 Oct 2009 05:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 7Kaqk4kyjPQT for ; Tue, 27 Oct 2009 05:35:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 4F66628C118 for ; Tue, 27 Oct 2009 05:35:53 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9RCa5M2017136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 27 Oct 2009 13:36:05 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9RCa2TG002142 for ; Tue, 27 Oct 2009 13:36:05 +0100 Received: from FIESEXC014.nsn-intra.net ([10.159.0.22]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 13:36:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Oct 2009 14:34:53 +0200 Message-ID: <2B5F3EA7272CFF47A66518E4FF3BE2350418AB30@FIESEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments to LISP+ALT draft Thread-Index: AcpXAeIAwlTKfGy8RfmFn2F4mKH6Rw== From: "Flinck, Hannu (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 27 Oct 2009 12:36:03.0479 (UTC) FILETIME=[0BE81270:01CA5702] Subject: [lisp] Comments to LISP+ALT draft 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 12:35:55 -0000 Hello=20 After reading the LISP+ALT (draft-ietf-lisp-alt-01) I have following comments, suggestions and questions.=20 General comment: LISP+ALT draft lacks consistency with draft-ietf-lisp-ms-04, instead the term "configuration" is used quite broadly covering the area of the mentioned draft and leaving too much for a reader to fill in the caps. See below what I mean: Section 4=20 Sentence from alt-01: "Note that ETRs are not required to participate (or prevented from participating) in LISP+ALT; they may choose communicate their mappings to their serving LISP+ALT router(s) at subscription time via configuration." This is very true, but ETRs may also choose to use Map-Register messages that contain a list of EID-prefixes plus a set of RLOC as defined in draft-ietf-lisp-ms-04.txt section 4. The issue here is that this is not only subscription time event but a continuous (periodic to be more specific) process as defined in draft-lisp-ms. Section 5 Sentence "A LISP+ALT router near the edge learns EID prefixes originated by authoritative ETRs, either by eBGP peering with them or by configuration." This should be aligned with ietf-lisp-ms-04.txt to cover Map-registering.=20 Section 5.2 "It also implies that an ETR that originates a prefix must maintain BGP sessions with all ALT routers that are configured to originate an aggregate which covers that prefix. " This I find contradictory to the target to keep ETR a simple CPE device as it insists on the use of BGP peering. =20 Section 5.4 "It receives Data Probes and Map-Requests only over GRE tunnel(s) to its "upstream" LISP+ALT router(s) and responds with Map- Replies for the EID prefixes that it "owns". " Here the text is about ETR. I guess that is should say "receives Data Probes and Map-Requests ... FROM its upstream... "=20 Section 6.2 Sentence "these LISP+ALT router(s) the ETR must route Map-Requests and Data Probes to the ETR and contain configuration (in effect, static routes) for the ETR's ..." The first occurrence of "the ETR" looks like a typo. If not more clarification in the text would improve its readability. Notice a again the use of the term of "configuration" in this context. Not really sure if this is the similar configuration that was implied in the earlier part of the text. Section 8.1 "Not only does this greatly improve the scalability of the global routing system but it also allows improved traffic engineering techniques by allowing richer and more fine-grained policies to be applied." But how are the operator policies and the mapping system policies correlated? The network can only apply its existing BGP policies for data packets entering into its network, but not during the map resolution phase? Section 9.1 "As in the case above, the ETR is connected to LISP+ALT router(s) using GRE tunnel(s) but rather than BGP being used, the LISP+ALT router(s) are configured with what are in effect "static routes" for the EID prefixes "owned" by the ETR. " Maybe ETR chooses to use the Map-Register message as in draft-eitf-lisp-ms, or is this what is meant by static routes? In case the ETR happens to have connections to multiple LISP+ALT routers in different parts of the ALT hierarchy how does the ETR know where to register/configure what EID prefix? Best regards Hannu=20 =20 =20 =20 =20 From vaf@cisco.com Tue Oct 27 11:14:16 2009 Return-Path: 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 3352C28C213 for ; Tue, 27 Oct 2009 11:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=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 9uaNNblRrSzl for ; Tue, 27 Oct 2009 11:14:15 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4838228C185 for ; Tue, 27 Oct 2009 11:14:15 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAvV5kqrR7H+/2dsb2JhbADBQJhVhD8E X-IronPort-AV: E=Sophos;i="4.44,634,1249257600"; d="scan'208";a="218407347" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 Oct 2009 18:14:29 +0000 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9RIETi4010672; Tue, 27 Oct 2009 18:14:29 GMT Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [127.0.0.1]) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Debian-6) with ESMTP id n9RI5hpp031218; Tue, 27 Oct 2009 11:05:43 -0700 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.14.3/8.14.3/Submit) id n9RI5gSP031215; Tue, 27 Oct 2009 11:05:42 -0700 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 27 Oct 2009 11:05:42 -0700 From: Vince Fuller To: "Flinck, Hannu (NSN - FI/Espoo)" Message-ID: <20091027180542.GB30615@vaf-lnx1> References: <2B5F3EA7272CFF47A66518E4FF3BE2350418AB30@FIESEXC014.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2B5F3EA7272CFF47A66518E4FF3BE2350418AB30@FIESEXC014.nsn-intra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: lisp@ietf.org Subject: Re: [lisp] Comments to LISP+ALT draft 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 18:14:16 -0000 On Tue, Oct 27, 2009 at 02:34:53PM +0200, Flinck, Hannu (NSN - FI/Espoo) wrote: > Hello > > After reading the LISP+ALT (draft-ietf-lisp-alt-01) I have following > comments, suggestions and questions. > > General comment: > > LISP+ALT draft lacks consistency with draft-ietf-lisp-ms-04, instead the > term "configuration" is used quite broadly covering the area of the > mentioned draft and leaving too much for a reader to fill in the caps. > See below what I mean: Hello Hannu- Thanks for the comments. The LISP+ALT spec authors are reviewing them and considering how best to incorporate your suggestions. I am a little hesitant to simply make all of the changes that you have offered because the LISP+ALT spec pre-dates LISP-MS and is still intended to be independent of it. I do agree that this historical fact has created some inconsistencies between the two documents but need to consider how to modify the wording in LISP+ALT to clarify things without at the same time sacrificing its independence from LISP-MS. --Vince (for the LISP+ALT authors) From hartmans@mit.edu Tue Oct 27 12:53:50 2009 Return-Path: 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 433203A6A5E for ; Tue, 27 Oct 2009 12:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 XqsEU4aFkQm6 for ; Tue, 27 Oct 2009 12:53:49 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 779443A6A2F for ; Tue, 27 Oct 2009 12:53:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6A82820156; Tue, 27 Oct 2009 15:53:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 36CF246BA; Tue, 27 Oct 2009 15:53:53 -0400 (EDT) To: Vince Fuller References: <2B5F3EA7272CFF47A66518E4FF3BE2350418AB30@FIESEXC014.nsn-intra.net> <20091027180542.GB30615@vaf-lnx1> From: Sam Hartman Date: Tue, 27 Oct 2009 15:53:53 -0400 In-Reply-To: <20091027180542.GB30615@vaf-lnx1> (Vince Fuller's message of "Tue\, 27 Oct 2009 11\:05\:42 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lisp@ietf.org Subject: Re: [lisp] Comments to LISP+ALT draft 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:53:50 -0000 >>>>> "Vince" == Vince Fuller writes: Vince> I am a little hesitant to simply make all of the changes Vince> that you have offered because the LISP+ALT spec pre-dates Vince> LISP-MS and is still intended to be independent of it. I do Vince> agree that this historical fact has created some Vince> inconsistencies between the two documents but need to Vince> consider how to modify the wording in LISP+ALT to clarify Vince> things without at the same time sacrificing its Vince> independence from LISP-MS. Speaking as an individual. I think that addressing these comments while preserving independence is quite important. It seems that lisp+alt can distribute mapping information whenever it somehow knows what BGP prefixes to announce. That can happen either because the prefixes are local, because "static routes" are configured, or because the router learns the prefix through something else. One something else is that the router may be a map server (or receive information through some mechanism from a map server). However I don't see any reason why the map server relationship should be special in this specification. I think that during the specification process we want to be careful to define clean architectural interfaces around the components. However I do see the points that are made here and believe that addressing these concerns could be an excellent opportunity to move towards these cleaner interfaces. I look forward to reviewing the editors' proposals for resolving these issues.