From internet-drafts@ietf.org Thu Mar 1 02:10:30 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83421F86EF; Thu, 1 Mar 2012 02:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAP-hSxmiY8J; Thu, 1 Mar 2012 02:10:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA46D21F863E; Thu, 1 Mar 2012 02:10:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120301101029.21402.74510.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2012 02:10:29 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-threats-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 01 Mar 2012 10:10:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Threats Analysis Author(s) : Damien Saucez Luigi Iannone Olivier Bonaventure Filename : draft-ietf-lisp-threats-01.txt Pages : 31 Date : 2012-03-01 This document analyzes the threats against the security of the Locator/Identifier Separation Protocol and proposes a set of recommendations to mitigate some of the identified security risks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-threats-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-threats-01.txt From internet-drafts@ietf.org Thu Mar 1 12:13:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC2421E824C; Thu, 1 Mar 2012 12:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8x0QIkMFYVC; Thu, 1 Mar 2012 12:13:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9E21E8081; Thu, 1 Mar 2012 12:13:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120301201337.16546.42476.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2012 12:13:37 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-map-versioning-09.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 01 Mar 2012 20:13:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map-Versioning Author(s) : Luigi Iannone Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-map-versioning-09.txt Pages : 24 Date : 2012-03-01 This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-map-versioning-09.txt From internet-drafts@ietf.org Sun Mar 4 13:13:23 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F9221F864F; Sun, 4 Mar 2012 13:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udZnR2NNx1MG; Sun, 4 Mar 2012 13:13:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E612121F8581; Sun, 4 Mar 2012 13:13:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304211322.16347.61001.idtracker@ietfa.amsl.com> Date: Sun, 04 Mar 2012 13:13:22 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-interworking-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 04 Mar 2012 21:13:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : Interworking LISP with IPv4 and IPv6 Author(s) : Darrel Lewis David Meyer Dino Farinacci Vince Fuller Filename : draft-ietf-lisp-interworking-06.txt Pages : 25 Date : 2012-03-04 This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces the Proxy Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-06.txt From darlewis@cisco.com Sun Mar 4 13:22:56 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C2E21F8595; Sun, 4 Mar 2012 13:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.759 X-Spam-Level: X-Spam-Status: No, score=-7.759 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K09yp6jnl-x; Sun, 4 Mar 2012 13:22:52 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D7E4321F860B; Sun, 4 Mar 2012 13:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=49963; q=dns/txt; s=iport; t=1330896173; x=1332105773; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=6skZebU9NxwKFHT2gUmuH23U5/YY1EfkZxVVDyHTPDs=; b=Vib4tFvIJUkay95/dxnfetLdpKovqfG9CtQOyDBTt/7A8C9nVwYHISdf sAJQBLLbmQSuObyZ8u+8TZJvgn4l4ybGdqqKx8ASELKR8qEfzvVIBYFEz S7bv4eFScqWN/em+WMQfV5iD3BzsUcyfjZbvcaWd3DfP9TVZmp1Fpi7KU M=; X-Files: draft-ietf-lisp-interworking-05-to-06-diffs.html : 45807 X-IronPort-AV: E=Sophos;i="4.73,530,1325462400"; d="html'217?scan'217,208,217";a="34299055" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 04 Mar 2012 21:22:52 +0000 Received: from sjc-jcardine-8713.cisco.com (sjc-jcardine-8713.cisco.com [10.19.246.84]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q24LMp5i020391; Sun, 4 Mar 2012 21:22:51 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/mixed; boundary="Apple-Mail=_037D6708-1A17-467C-B29A-42B542B9F070" From: Darrel Lewis In-Reply-To: <20120304211322.16347.61001.idtracker@ietfa.amsl.com> Date: Sun, 4 Mar 2012 13:22:51 -0800 Message-Id: References: <20120304211322.16347.61001.idtracker@ietfa.amsl.com> To: Internet-Drafts@ietf.org X-Mailer: Apple Mail (2.1257) Cc: lisp@ietf.org, i-d-announce@ietf.org Subject: Re: [lisp] I-D Action: draft-ietf-lisp-interworking-06.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Sun, 04 Mar 2012 21:22:56 -0000 --Apple-Mail=_037D6708-1A17-467C-B29A-42B542B9F070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This update is to address Discuss items and Comments which arose during = IESG review of the document. An HTML diff from -05 to -06 is attached: --Apple-Mail=_037D6708-1A17-467C-B29A-42B542B9F070 Content-Disposition: attachment; filename=draft-ietf-lisp-interworking-05-to-06-diffs.html Content-Type: text/html; name="draft-ietf-lisp-interworking-05-to-06-diffs.html" Content-Transfer-Encoding: 7bit wdiff draft-ietf-lisp-interworking-05.txt draft-ietf-lisp-interworking-06.txt 
Network Working Group                                           D. Lewis
Internet-Draft                                                  D. Meyer
Intended status: Experimental                               D. Farinacci
Expires: September 1, 5, 2012                                     V. Fuller
                                                     Cisco Systems, Inc.
                                                       February 29,
                                                           March 4, 2012

                  Interworking LISP with IPv4 and IPv6
                  draft-ietf-lisp-interworking-05.txt
                  draft-ietf-lisp-interworking-06.txt

Abstract

   This document describes techniques for allowing sites running the
   Locator/ID Separation Protocol (LISP) to interoperate with Internet
   sites (which may be using either IPv4, IPv6, or both) but which are
   not running LISP.  A fundamental property of LISP speaking sites is
   that they use Endpoint Identifiers (EIDs), rather than traditional IP
   addresses, in the source and destination fields of all traffic they
   emit or receive.  While EIDs are syntactically identical to IPv4 or
   IPv6 addresses, normally routes to them are not carried in the global
   routing system so an interoperability mechanism is needed for non-
   LISP-speaking sites to exchange traffic with LISP-speaking sites.
   This document introduces three such mechanisms.  The first uses a new
   network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs)
   (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR)
   for non-LISP-speaking hosts.  Second the document adds Network
   Address Translation (NAT) functionality to LISP Ingress and LISP
   Egress Tunnel Routers (xTRs) to substitute routable IP addresses for
   non-routable EIDs.  Finally, this document introduces the Proxy
   Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR
   cannot send packets to non-LISP sites without encapsulation.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."
   This Internet-Draft will expire on September 1, 5, 2012.

Copyright Notice

   Copyright (c) 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Definition of Terms  . . . . . . . . . . . . . . . . . . . . .  6
   3.  LISP Interworking Models . . . . . . . . . . . . . . . . . . .  7
   4.  Routable EIDs  . . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Impact on Routing Table  . . . . . . . . . . . . . . . . .  8
     4.2.  Requirement for sites to use BGP . . . . . . . . . . . . .  8
     4.3.  Limiting the Impact of Routable EIDs . . . . . . . . . . .  8
     4.4.  Use of Routable EIDs for sites transitioning to LISP . . .  8
   5.  Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
     5.1.  Proxy-ITR EID announcements  . . . . . . . . . . . . . . . 10
     5.2.  Packet Flow with Proxy-ITRs  . . . . . . . . . . . . . . . 10
     5.3.  Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11 12
     5.4.  Impact of the Proxy-ITRs placement in the network  . . . . 12 13
     5.5.  Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12 13
   6.  Proxy Egress Tunnel Routers  . . . . . . . . . . . . . . . . . 13 14
     6.1.  Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13 14
   7.  LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 16
     7.1.  Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15 16
     7.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending
           to non-LISP Sites  . . . . . . . . . . . . . . . . . . . . 16 17
     7.3.  LISP Sites with Hosts using RFC 1918 Addresses
           Sending Packets to Other LISP Sites  . . . . . . . . . . . 16 17
     7.4.  LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17 18
   8.  Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and
       Proxy-ETRs (Proxy-ETRs)  . . . . . . . . . . . . . . . . . . . 18 19
     8.1.  How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19 20
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20 21
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21 22
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 23
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 23
     12.2. Informative References . . . . . . . . . . . . . . . . . . 22 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 25

1.  Introduction

   This document describes interoperation mechanisms between LISP [LISP]
   sites which use non-globally-routed EIDs, and non-LISP sites.  A key
   behavior of the separation of Locators and Endpoint IDs is that EID
   prefixes are normally not advertised into the Internet's Default Free
   Zone (DFZ).  (See section 4, for the exception case.)  Specifically,
   only Routing Locators (RLOCs) are carried in the Internet's DFZ.
   Existing Internet sites (and their hosts) which do not run in the
   LISP protocol must still be able to reach sites numbered from LISP
   EID space.  This draft document describes three mechanisms that can be used
   to provide reachability between sites that are LISP-capable and those
   that are not.

   The first mechanism uses a new network element, the LISP Proxy
   Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP
   Ingress Tunnel Router (ITR) for non-LISP-speaking hosts.  The second
   mechanism adds a form of Network Address Translation (NAT)
   functionality to Tunnel Routers (xTRs), to substitute routable IP
   addresses for non-routable EIDs.  The final network element is the
   LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an
   intermediate Egress Tunnel Router (ETR) for LISP sites which need to
   encapsulate LISP packets destined to non-LISP sites.

   More detailed descriptions of these mechanisms and the network
   elements involved may be found in the following sections:

   - Section 2 defines terms used throughout the document

   - Section 2 describes the different cases where interworking
   mechanisms are needed

   - Section 4 describes the relationship between the new EID prefix
   space and the IP address space used by the current Internet

   - Section 5 introduces and describes the operation of Proxy Ingress
   tunnel Routerss

   - Section 6 introduces and describes the operations of Proxy-ETRs

   - Section 7 defines how NAT is used by ETRs to translate non-routable
   EIDs into routable IP addresses.

   - Section 8 describes the relationship between asymmetric and
   symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
   NAT)

   Note that any successful interworking model should be independent of
   any particular EID-to-RLOC mapping algorithm.  This document does not
   comment on the value of any of the particular LISP mapping systems.

   Several areas concerning the Interworking of LISP and non-LISP sites
   remain open for further study.  These areas include an examination of
   the impact of LISP-NAT on Internet traffic and applications,
   understanding the deployment motivations for the deployment and
   operation of Proxy Tunnel Routers, the impact of EID routes
   originated into the Internet's Default Free Zone,and the effects of
   Proxy Tunnel Routers or LISP-NAT on Internet traffic and
   applications.  Until these issues are fully understood, it is
   possible that the interworking mechanisms described in this document
   are hard to deploy, or may have unintended consequences to
   applications.

2.  Definition of Terms

   Default Free Zone:  The Default-Free Zone (DFZ) refers to the
      collection of all Internet autonomous systems that do not require
      a default route to route a packet to any destination.

   LISP Routable (LISP-R) Site:  A LISP site whose addresses are used as
      both globally routable IP addresses and LISP EIDs.

   LISP Non-Routable (LISP-NR) Site:  A LISP site whose addresses are
      EIDs only, these EIDs are not found in the legacy Internet routing
      table.

   LISP Proxy Ingress Tunnel Router (Proxy-ITR):  Proxy-ITRs are used to
      provide connectivity between sites which use LISP EIDs and those
      which do not.  They act as gateways between those parts of the
      Internet which are not using LISP (the legacy Internet) A given
      Proxy-ITR advertises one or more highly aggregated EID prefixes
      into the public Internet and acts as the ITR for traffic received
      from the public Internet.  LISP Proxy-ITRs are described in
      Section 5.

   LISP Network Address Translation (LISP-NAT):  Network Address
      Translation between EID space assigned to a site and RLOC space
      also assigned to that site.  LISP Network Address Translation is
      described in Section 7.

   LISP Proxy Egress Tunnel Router (Proxy-ETR):  Proxy-ETRs provide a
      LISP (Routable or Non-Routable EID) site's ITRs the ability to
      send packets to non-LISP sites in cases where unencapsualted
      packets (the default mechanism) would fail to be delivered.
      Proxy-ETRs function by having an ITR encapsulate all non-LISP
      destined traffic to a pre-configured Proxy-ETR.  LISP Proxy Egress
      Tunnel Routers are described in Section 6.

    EID Sub Namespace:  A power-of-two block of aggregatable locators
      set aside for LISP interworking.

   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].

3.  LISP Interworking Models

   There are 4 unicast connectivity cases which describe how sites can
   send packets to each other:

   1.  non-LISP site to non-LISP site

   2.  LISP site to LISP site

   3.  LISP site to non-LISP site

   4.  non-LISP site to LISP site

   Note that while Cases 3 and 4 seem similar, there are subtle
   differences due to the way packets are originated.

   The first case is the Internet as we know it today and as such will
   not be discussed further here.  The second case is documented in
   [LISP] and there are no new interworking requirements because there
   are no new protocol requirements placed on intermediate non- LISP
   routers.

   In case 3, LISP site to non-LISP site, a LISP site can (in most
   cases) send packets to a non-LISP site because the non-LISP site
   prefixes are routable.  The non-LISP sites need not do anything new
   to receive packets.  The only action the LISP site needs to take is
   to know when not to LISP-encapsulate packets.  An ITR knows
   explicitly that the destination is non-LISP if the destination IP
   address of an IP packet matches a (negative) Map-Cache entry which
   has the action 'Natively-Forward'.

   There could be some situations where (unencapsulated) packets
   originated by a LISP site may not be forwarded to a non-LISP site.
   These cases are reviewed in section 7, (Proxy Egress Tunnel Routers).

   Case 4, typically the most challenging, occurs when a host at a non-
   LISP site wishes to send traffic to a host at a LISP site.  If the
   source host uses a (non-globally-routable) EID as the destination IP
   address, the packet is forwarded inside the source site until it
   reaches a router which cannot forward it (due to lack of a default
   route), at which point the traffic is dropped.  For traffic not to be
   dropped, either some mechanism to make this destination EID routable must be
   in place.  Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) describe
   two such mechanisms.  Case 4 also applies to packets returning to the
   LISP site, in Case 3.

4.  Routable EIDs

   An obvious way to achieve interworking between LISP and non-LISP
   hosts is for a LISP site to simply announce EID prefixes into the
   DFZ, much like the current routing system, effectively treating them
   as "Provider Independent (PI)" prefixes.  Having a site do this is
   undesirable as it defeats one of the primary goals of LISP - to
   reduce global routing system state.

4.1.  Impact on Routing Table

   If EID prefixes are announced into the DFZ, the impact is similar to
   the case in which LISP has not been deployed, because these EID
   prefixes will be no more aggregatable than existing PI addresses.
   Such a mechanism is not viewed as a viable long term solution, but
   may be a viable short term way for a site to transition a portion of
   its address space to EID space without changing its existing routing
   policy.

4.2.  Requirement for sites to use BGP

   Routable EIDs might cause require non-LISP sites today to use BGP to, among
   other things, originate their site's routes into the DFZ, and in order to
   enable ingress traffic engineering.  Relaxing this requirement requirement, (thus
   potentially reducing global DFZ routing state) while still letting
   sites control their ingress traffic engineering policy is another primary a design
   goal of LISP.

4.3.  Limiting the Impact of Routable EIDs

   Two schemes are proposed to limit the impact of having EIDs announced
   in the current global Internet routing table:

   1.  Section 5 discusses the LISP Proxy Ingress Tunnel Router, an
       approach that provides ITR functionality to bridge LISP-capable
       and non-LISP-capable sites.

   2.  Section 7 discusses another approach, LISP-NAT, in which NAT
       [RFC2993] is combined with ITR functionality to limit the impact
       of routable EIDs on the Internet routing infrastructure.

4.4.  Use of Routable EIDs for sites transitioning to LISP

   A primary design goal for LISP (and other Locator/ID separation
   proposals) is to facilitate topological aggregation of namespace used
   for the path computation, and, thus, decrease global routing system
   overhead.  Another goal is to achieve the benefits of improved
   aggregation as soon as possible.  Individual sites advertising their
   own routes for LISP EID prefixes into the global routing system is
   therefore not recommended.

   That being said, single-homed sites (or multi-homed sites that are
   not leaking more specific exceptions) that are already using
   provider-aggregated prefixes can use these prefixes as LISP EIDs
   without adding state to the routing system.  In other words, such
   sites do not cause additional prefixes to be advertised.  For such
   sites, connectivity to a non-LISP site does not require interworking
   machinery because the "PA" EIDs are already routable (they are
   effectively LISP-R type sites).  Their EIDs are found in the LISP
   mapping system, and their (aggregate) PA prefix(es) are found in the
   DFZ of the Internet.

   The continued announcements of an existing site's Provider
   Independent (or "PI") prefix(es) is of course under control of that
   site.  Some period of transition, where a site is found both in the
   LISP mapping system, and as a discrete prefix in the Internet routing
   system, may be a viable transition strategy.  Care should be taken
   not to advertise additional more specific LISP EID prefixes into the
   DFZ.

5.  Proxy Ingress Tunnel Routers

   Proxy Ingress Tunnel Routers (Proxy-ITRs) allow for non-LISP sites to
   send packets to LISP-NR sites.  A Proxy-ITR is a new network element
   that shares many characteristics with the LISP ITR.  Proxy-ITRs allow
   non-LISP sites to send packets to LISP-NR sites without any changes
   to protocols or equipment at the non-LISP site.  Proxy-ITRs have two
   primary functions:

   Originating EID Advertisements:  Proxy-ITRs advertise highly
      aggregated EID-prefix space on behalf of LISP sites so that non-
      LISP sites can reach them.

   Encapsulating Legacy Internet Traffic:  Proxy-ITRs also encapsulate
      non-LISP Internet traffic into LISP packets and route them towards
      their destination RLOCs.

5.1.  Proxy-ITR EID announcements

   A key part of Proxy-ITR functionality is to advertise routes for
   highly- aggregated EID prefixes into parts of the global routing
   system.  Aggressive aggregation is performed to minimize the number
   of new announced routes.  In addition, careful placement of Proxy-
   ITRs can greatly reduce the advertised scope of these new routes.  To
   this end, Proxy-ITRs should be deployed close to non-LISP-speaking
   rather than close to LISP sites.  Such deployment not only limits the
   scope of EID-prefix route advertisements, it also allows traffic
   forwarding load to be spread among many Proxy-ITRs.

5.2.  Packet Flow with Proxy-ITRs

   What follows is an example of the path a packet would take when using
   a Proxy-ITR.  In this example, the LISP-NR site is given the EID
   prefix 192.0.2.0/24.  For the purposes of this example, neither this
   prefix nor any covering aggregate are present in the global routing
   system.  In other words, without the Proxy-ITR announcing
   192.0.2.0/24, if a packet with this destination were to reach a
   router in the "Default Free Zone", it would be dropped.  The
   following diagram describes a high level view of the topology:

                      Internet DFZ

           .--------------------------------.
          /                                  \
          |      Traffic Encap'd to Site's   |
          |    +-----+    RLOC(s)            |        LISP Site:
          |    |P-ITR|=========>             |
          |    +-----+                    +--+      +-----+ |
          |       |                       |PE+------+CE 1 |-|
          |       | Originated Rout       +--+      +-----+ | +----+
          |       V  192.0.2.0/24            |              |-|Host|
          |                               +--|      +-----+ | +----+
          |                               |PE+------+CE 2 |-|  192.0.2.1
          |                +---+          +--+      +-----+ |
          \                |PE |             /
           '---------------+-+-+------------'        Site EID Prefix:
                             |                          192.0.2.0/24
                             |       ^
                             |       |
                          +--+--+    | Traffic
          Non LISP Site:  | CE  |    |  to
                          +--+--+    | 192.168.2.1
                             |       |
                        -----------
                                |
                               +----+
                               |Host|
                               +----+

                Figure 1: Example of Proxy-ITR Packet Flow

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup EID for destination, and gets
       192.0.2.1 in return.

   2.  The source host has a default route to Customer Edge (CE) router
       and forwards the packet to the CE.

   3.  The CE has a default route to its Provider Edge (PE) router, and
       forwards the packet to the PE.

   4.  The PE has a route to 192.0.2.0/24 and the next hop is the Proxy-
       ITR.

   5.  The Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP
       encapsulates the packet.  The outer IP header now has a
       destination address of one of the destination EID's RLOCs.  The
       outer source address of this encapsulated packet is the Proxy-
       ITR's RLOC.

   6.  The Proxy-ITR looks up the RLOC, and forwards LISP packet to the
       next hop, after which, it is forwarded by other routers to the
       ETR's RLOC.

   7.  The ETR decapsulates the packet and delivers the packet to the
       192.0.2.1 host in the destination LISP site.

   8.  Packets from host 192.0.2.1 will flow back through the LISP
       site's ITR.  Such packets are not encapsulated because the ITR
       knows that the destination (the original source) is a non-LISP
       site.  The ITR knows this because it can check the LISP mapping
       database for the destination EID, and on a failure determines
       that the destination site is not LISP enabled.

   9.  Packets are then routed natively and directly to the destination
       (original source) site.

   Note that in this example the return path is asymmetric, so return
   traffic will not go back through the Proxy-ITR.  This is because the
   LISP-NR site's ITR will discover that the originating site is not a
   LISP site, and not encapsulate the returning packet (see [LISP] for
   details of ITR behavior).

   The asymmetric nature of traffic flows allows the Proxy-ITR to be
   relatively simple - it will only have to encapsulate LISP packets.

5.3.  Scaling Proxy-ITRs

   Proxy-ITRs attract traffic by announcing the LISP EID namespace into
   parts of the non-LISP-speaking global routing system.  There are
   several ways that a network could control how traffic reaches a
   particular Proxy-ITR to prevent it from receiving more traffic than
   it can handle:

   1.  The Proxy-ITR's aggregate routes might be selectively announced,
       giving a coarse way to control the quantity of traffic attracted
       by that Proxy-ITR.  For example, some of the routes being
       announced might be tagged with a BGP community and their scope of
       announcement limited by the routing policy of the provider.

   2.  The same address might be announced by multiple Proxy-ITRs in
       order to share the traffic using IP Anycast.  The asymmetric
       nature of traffic flows through the Proxy-ITR means that
       operationally, deploying a set of Proxy-ITRs would be very
       similar to existing Anycasted services like DNS caches.  Multiple
       Proxy-ITRs could advertise the same BGP Next Hop IP address as
       their RLOC, and traffic would be attracted to the nearest Next
       Hop according to the network's IGP.

5.4.  Impact of the Proxy-ITRs placement in the network

   There are several approaches that a network could take in placing
   Proxy-ITRs.  Placing the Proxy-ITR near the source of traffic allows
   for the communication between the non-LISP site and the LISP site to
   have the least "stretch" (i.e. the least number of forwarding hops
   when compared to an optimal path between the sites).

   Some proposals, for example Core Router-Integrated Overlay [CRIO],
   have suggested grouping Proxy-ITRs near an arbitrary subset of ETRs
   and announcing a 'local' subset of EID space.  This model cannot
   guarantee minimum stretch if the EID prefix route advertisement
   points are changed (such a change might occur if a site adds,
   removes, or replaces one or more of its ISP connections).

5.5.  Benefit to Networks Deploying Proxy-ITRs

   When packets destined for LISP-NR sites arrive and are encapsulated
   at a Proxy-ITR, a new LISP packet header is pre-pended.  This causes
   the packet's destination to be set to the destination ETRs RLOC.
   Because packets are thus routed towards RLOCs, it can potentially
   better follow the Proxy-ITR network's traffic engineering policies
   (such as closest exit routing).  This also means that providers which
   are not default-free and do not deploy Proxy-ITRs end up sending more
   traffic to expensive transit links (assuming their upstreams have
   deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to
   which they may well have cheaper and closer connectivity to (via, for
   example, settlement-free peering).  A corollary to this would be that
   large transit providers, deploying Proxy-ITRs may attract more
   traffic, and therefore more revenue, from their customers.

6.  Proxy Egress Tunnel Routers

   Proxy Egress Tunnel Routers (Proxy-ETRs) allow for LISP sites to send
   packets to non-LISP sites in the case where the access network does
   not allow the LISP site to send packets with the source address of
   the site's EID(s).  A Proxy-ETR is a new network element that,
   conceptually, acts as an ETR for traffic destined to non-LISP sites.
   This also has the effect of allowing an ITR avoid having to decide
   whether to encapsulate packets or not - it can always encapsulate
   packets.  An ITR would encapsulate packets destined for LISP sites
   (no change here) and these would be routed directly to the
   corespondent site's ETR.  All other packets (those destined to non-
   LISP sites) will be sent to the originating site's Proxy-ETR.

   There are two primary reasons why sites would want to utilize a
   Proxy-ETR:

   Avoiding strict uRPF failures:  Some provider's access networks
      require the source of the packets emitted to be within the
      addressing scope of the access networks. (see section 9)

   Traversing a different IP Protocol:  A LISP site may want to transmit
      packets to a non-LISP site where some of the intermediate network
      does not support the particular IP protocol desired (v4 or v6).
      Proxy-ETRs can allow this LISP site's data to 'hop over' this by
      utilizing LISP's support for mixed protocol encapsulation.

6.1.  Packet Flow with Proxy Egress Tunnel Routers

   Packets from a LISP site can reach a non-LISP site with the aid of a
   Proxy-ETR (or Proxy-ETR).  An ITR is simply configured to send all
   non-LISP traffic, which it normally would have forwarded natively
   (non-encapsulated), to a Proxy-ETR.  In the case where the ITR uses a
   Map- Resolver(s), the ITR will encapsulate packets that match the
   received Negative Map-Cache to the configured Proxy-ETR(s).  In the
   case where the ITR is connected to the mapping system directly it
   would encapsulate all packets to the configured Proxy-ETR that are
   cache misses.  Note that this outer encapsulation to the Proxy-ETR
   may be in an IP protocol other than the (inner) encapsulated data.
   Routers then use the LISP (outer) header's destination address to
   route the packets toward the configured Proxy-ETR.

   A Proxy-ETR should verify the (inner) source EID of the packet at
   time of decapsulation in order to verify that this is from a
   configured LISP site.  This is to prevent spoofed inner sources from
   being encapsulated through the Proxy-ETR.

   What follows is an example of the path a packet would take when using
   a Proxy-ETR.  In this example, the LISP-NR (or LISP-R) site is given
   the EID prefix 192.0.2.0/24, and it is trying to reach host at a non-
   LISP site with the IP prefix of 198.51.100.0/24.  For the purposes of
   this example, the destination (198.51.100.0/24) is found in the
   Internet's routing system.

   A full protocol exchange example follows:

   1.  The source host makes a DNS lookup for the destination, and gets
       198.51.100.100 (an IP address of a host in the non-LISP site) in
       return.

   2.  The source host has a default route to Customer Edge (CE) router
       and forwards the packet towards the CE.

   3.  The CE is a LISP ITR, and is configured to encapsulate traffic
       destined for non-LISP sites to a Proxy-ETR.

   4.  The Proxy ETR decapsulates the LISP packet and forwards the
       original packet to its next hop.

   5.  The packet is then routed natively and directly to the
       destination (non-LISP) site 198.51.100.0/24.

   Note that in this example the return path is asymmetric, so return
   traffic will not go back through the Proxy-ETR.  This means that in
   order to reach LISP-NR sites, non-LISP sites must still use Proxy-
   ITRs.

7.  LISP-NAT

   LISP Network Address Translation (LISP-NAT) is a limited form of NAT
   [RFC2993].  LISP-NAT is designed to enable the interworking of non-
   LISP sites and LISP-NR sites by ensuring that the LISP-NR's site
   addresses are always routable.  LISP-NAT accomplishes this by
   translating a host's source address from an 'inner' (LISP-NR EID)
   value to an 'outer' (LISP-R) value and keeping this translation in a
   table that it can reference for subsequent packets.

   In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to
   talk to both LISP or non-LISP sites.

   The basic concept of LISP-NAT is that when transmitting a packet, the
   ITR replaces a non-routable EID source address with a routable source
   address, which enables packets to return to the site.  Note that this
   section is intended as rough overview of what could be done and not
   an exhaustive guide to IPv4 NAT.

   There are two main cases that involve LISP-NAT:

   1.  Hosts at LISP sites that use non-routable global EIDs speaking to
       non-LISP sites using global addresses.

   2.  Hosts at LISP sites that use RFC 1918 private EIDs speaking to
       other sites, who may be either LISP or non-LISP sites.

   Note that LISP-NAT is not needed in the case of LISP-R (routable
   global EIDs) sources.  This case occurs when a site is announcing its
   prefix into both the LISP mapping system as well as the Internet DFZ.
   This is because the LISP-R source's address is routable, and return
   packets will be able to natively reach the site.

7.1.  Using LISP-NAT with LISP-NR EIDs

   LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP
   hosts by translating the LISP-NR EID to a globally unique address (a
   LISP-R EID).  This globally unique address may be a either a PI or PA
   address.

   An example of this translation follows.  For this example, a site has
   been assigned a LISP-NR EID of 203.0.113.0/24.  In order to utilize
   LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24,
   and uses the first address (192.0.2.1) as the site's RLOC.  The rest
   of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation
   pool for this site's hosts who need to send packets to non-LISP
   hosts.

   The translation table might look like the following:

          Site NR-EID     Site R-EID     Site's RLOC    Translation Pool
          ==============================================================
          203.0.113.0/24  192.0.2.0/24    192.0.2.1      192.0.2.2-254

                    Figure 1: 2: Example Translation Table

   The host 203.0.113.2 sends a packet (which, for the purposes of this
   example is destined for a non-LISP site) to its default route (the
   ITR).  The ITR receives the packet, and determines that the
   destination is not a LISP site.  How the ITR makes this determination
   is up to the ITRs implementation of the EID-to-RLOC mapping system
   used (see, for example [LISP-ALT]).

   The ITR then rewrites the source address of the packet from
   203.0.113.2 to 192.0.2.2, which is the first available address in the
   LISP-R EID space available to it.  The ITR keeps this translation in
   a table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   Finally, when the ITR forwards this packet without encapsulating it,
   it uses the entry in its LISP-NAT table to translate the returning
   packets' destination IPs to the proper host.

7.2.  LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
      Sites

   In the case where hosts using RFC 1918 addresses desire to send
   packets to non-LISP hosts, the LISP-NAT implementation acts much like
   an existing IPv4 NAT device that is doing address only (not port
   translation.  The ITR providing the NAT service must use LISP-R EIDs
   for its global address pool as well as providing all the standard NAT
   functions required today.

   Note that the RFC 1918 addresses above are private addresses, not
   EIDs, and these RFC 1918 addresses are not found in the LISP mapping
   system.

   The source of the packet must be translated to a LISP-R EID in a
   manner similar to Section 7, and this packet must be forwarded to the
   ITR's next hop for the destination, without LISP encapsulation.

7.3.  LISP Sites with Hosts using RFC 1918 Addresses   Sending Packets
      to Other LISP Sites

   LISP-NAT allows a host with an RFC 1918 address to send packets to
   LISP hosts by translating the RFC 1918 address to a LISP EID.  After
   translation, the communication between source and destination ITR and
   ETRs continues as described in [LISP].

   While the communication of LISP EIDs to LISP EIDs is, strictly
   speaking, outside the scope of Interworking, it is included here in
   order to complete the conceptual framework of LISP-NAT.

   An example of this translation and encapsulation follows.  For this
   example, a host has been assigned a RFC 1918 address of 192.168.1.2.
   In order to utilize LISP-NAT, the site also has been provided the
   LISP-R EID prefix of 192.0.2.0/24, and uses the first address
   (192.0.2.1) as the site's RLOC.  The rest of this PA space (192.0.2.2
   to 192.0.2.254) is used as a translation pool for this site's hosts
   who need to send packets to both non-LISP and LISP hosts.

   The host 192.168.1.2 sends a packet destined for a non-LISP site to
   its default route (the ITR).  The ITR receives the packet and
   determines that the destination is a LISP site.  How the ITR makes
   this determination is up to the ITRs implementation of the EID/RLOC
   mapping system.

   The ITR then rewrites the source address of the packet from
   192.168.1.2 to 192.0.2.2, which is the first available address in the
   LISP EID space available to it.  The ITR keeps this translation in a
   table in order to reverse this process when receiving packets
   destined to 192.0.2.2.

   The ITR then LISP encapsulates this packet (see [LISP] for details).
   The ITR uses the site's RLOC as the LISP outer header's source and
   the translation address as the LISP inner header's source.  Once it
   decapsulates returning traffic, it uses the entry in its LISP-NAT
   table to translate the returning packet's destination IP address and
   then forwards to the proper host.

7.4.  LISP-NAT and multiple EIDs

   With LISP-NAT, there are two EIDs possible for a given host, the
   LISP-R EID and the LISP-NR EID.  When a site has two addresses that a
   host might use for global reachability, name-to-address directories
   may need to be modified.

   This problem, global vs. local addressability, exists for NAT in
   general, but the specific issue described above is unique to
   location/identity separation schemes.  Some of these have suggested
   running a separate DNS instance for new types of EIDs.  This solves
   the problem but introduces complexity for the site.  Alternatively,
   using Proxy-ITRs can mitigate this problem, because the LISP-NR EID
   can be reached in all cases.

8.  Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs
    (Proxy-ETRs)

   In summary, there are three suggested mechanisms for interworking
   LISP with non-LISP Sites (for both IPv4 and IPv6).  In the LISP-NAT
   option the LISP site can manage and control the interworking on its
   own.  In the Proxy-ITR case, the site is not required to manage the
   advertisement of it's EID prefix into the DFZ, with the cost of
   potentially adding stretch to the connections of non-LISP sites
   sending packets to the LISP site.  The third option is Proxy-ETRs,
   which are optionally used by sites relying on Proxy-ITRs to mitigate
   two caveats for LISP sites sending packets to non-LISP sites.  This
   means Proxy-ETRs are not usually expected to be deployed by
   themselves, rather they will be used to assist LISP-NR sites which
   are already using Proxy-ITRs.

8.1.  How Proxy-ITRs and Proxy-ETRs Interact

   There is a subtle difference between Symmetrical (LISP-NAT) vs
   Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
   Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs)
   can (and likely should) be decoupled since Proxy-ITRs are best
   deployed closest to non-LISP sites, and Proxy-ETRs are best located
   close to the LISP sites they are decapsulating for.  This asymmetric
   placement of the two network elements minimizes the stretch imposed
   on each direction of the packet flow, while still allowing for
   coarsely aggregated announcements of EIDs into the Internet's routing
   table.

9.  Security Considerations

   Like any router or LISP ITR, Proxy-ITRs will have the opportunity to
   inspect traffic at the time that they encapsulate.  The location of
   these devices in the network can have implications for discarding
   malicious traffic on behalf of ETRs which request this behavior (via
   the drop action bit in Map-Reply packets for an EID or EID prefix).
   This is an area that would benefit from further experimentation and
   analysis.

   LISP-Interworking via Proxy-ITRs should have no impact on the
   existing network beyond what LISP ITRs and ETRs introduce when
   multihoming.  That is, if a site multi-homes today (with LISP or BGP)
   there is a possibility of asymmetric flows.

   Proxy-ITRs and Proxy-ETRs will likely be operated by organizations
   other than those of the end site receiving or sending traffic.  Care
   should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to
   insure the quality of service meets the site's expectations.

   Proxy-ITRs and Proxy ETRs share many of the same security issues
   discussed of ITRs and ETRs.  For further information, see the
   security considerations section of [LISP].

   As with traditional NAT, LISP-NAT will obscure the actual host
   LISP-NR EID behind the LISP-R addresses used as the NAT pool.

   When LISP sites send packets to non-LISP sites (these non-LISP sites
   rely on Proxy-ITRs to enable Interworking), packets will have the
   site's EID as its source IP address.  These EIDs may not be
   recognized by their Internet Service Provider's Unicast Reverse Path
   Forwarding (uRPF) rules enabled on the Provider Edge Router.  Several
   options are available to the service provider.  For example they
   could enable a less strict version of uRPF, where they only look for
   the existence of the EID prefix in the routing table.  Another, more
   secure, option is to add a static route for the customer on the PE
   router, but not redistribute this route into the provider's routing
   table.  Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF
   check by encapsulating all of their egress traffic destined to non-
   LISP sites to the Proxy-ETR (thus ensuring the outer IP source
   address is the site's RLOC).

10.  Acknowledgments

   Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael
   Menth, and Xuewei Wang, and Noel Chiappa who have made insightful
   comments with respect to LISP Interworking and transition mechanisms.

   A special thanks goes to Scott Brim for his initial brainstorming of
   these ideas and also for his careful review.

11.  IANA Considerations

   This document creates no new requirements on IANA namespaces
   [RFC5226].

12.  References

12.1.  Normative References

   [LISP]     Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-20 (work in progress), January 2012.

   [LISP-ALT]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)",
              draft-ietf-lisp-alt-10.txt (work in progress),
              December 2011.

   [LISP-MS]  Farinacci, D. and V. Fuller, "LISP Map Server",
              draft-ietf-lisp-ms-15.txt (work in progress),
              January 2012.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC4632]  Fuller, V. and T. Li, "Classless Inter-domain Routing
              (CIDR): The Internet Address Assignment and Aggregation
              Plan", BCP 122, RFC 4632, August 2006.

12.2.  Informative References

   [CRIO]     Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
              Scaling IP Routing with the Core Router-Integrated
              Overlay", January 2006.

   [LISP-DEPLOY]
              Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "LISP Network Element
              Deployment Considerations",
              draft-ietf-lisp-deployment-02.txt (work in progress),
              November 2011.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              November 2000.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027,
              January 2001.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

Authors' Addresses

   Darrel Lewis
   Cisco Systems, Inc.

   Email: darlewis@cisco.com

   David Meyer
   Cisco Systems, Inc.

   Email: dmm@cisco.com

   Dino Farinacci
   Cisco Systems, Inc.

   Email: dino@cisco.com

   Vince Fuller
   Cisco Systems, Inc.

   Email: vaf@cisco.com
--Apple-Mail=_037D6708-1A17-467C-B29A-42B542B9F070 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks, -Darrel On Mar 4, 2012, at 1:13 PM, Internet-Drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Interworking LISP with IPv4 and IPv6 > Author(s) : Darrel Lewis > David Meyer > Dino Farinacci > Vince Fuller > Filename : draft-ietf-lisp-interworking-06.txt > Pages : 25 > Date : 2012-03-04 >=20 > This document describes techniques for allowing sites running the > Locator/ID Separation Protocol (LISP) to interoperate with Internet > sites (which may be using either IPv4, IPv6, or both) but which are > not running LISP. A fundamental property of LISP speaking sites is > that they use Endpoint Identifiers (EIDs), rather than traditional = IP > addresses, in the source and destination fields of all traffic they > emit or receive. While EIDs are syntactically identical to IPv4 or > IPv6 addresses, normally routes to them are not carried in the = global > routing system so an interoperability mechanism is needed for non- > LISP-speaking sites to exchange traffic with LISP-speaking sites. > This document introduces three such mechanisms. The first uses a = new > network element, the LISP Proxy Ingress Tunnel Routers (Proxy-ITRs) > (Section 5) to act as a intermediate LISP Ingress Tunnel Router = (ITR) > for non-LISP-speaking hosts. Second the document adds Network > Address Translation (NAT) functionality to LISP Ingress and LISP > Egress Tunnel Routers (xTRs) to substitute routable IP addresses for > non-routable EIDs. Finally, this document introduces the Proxy > Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR > cannot send packets to non-LISP sites without encapsulation. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-lisp-interworking-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-interworking-06.txt >=20 > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --Apple-Mail=_037D6708-1A17-467C-B29A-42B542B9F070-- From internet-drafts@ietf.org Mon Mar 5 09:09:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6821F87BF; Mon, 5 Mar 2012 09:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf43qshqgfKH; Mon, 5 Mar 2012 09:09:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02AEC21F8757; Mon, 5 Mar 2012 09:09:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305170943.28544.84330.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 09:09:43 -0800 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-ms-16.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 17:09:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Map Server Interface Author(s) : Vince Fuller Dino Farinacci Filename : draft-ietf-lisp-ms-16.txt Pages : 16 Date : 2012-03-05 This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-ms-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-ms-16.txt From iesg-secretary@ietf.org Tue Mar 6 07:56:49 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56521F8986; Tue, 6 Mar 2012 07:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxVWt2RowLMQ; Tue, 6 Mar 2012 07:56:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E221F8987; Tue, 6 Mar 2012 07:56:48 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306155648.24197.9643.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 07:56:48 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP Map-Versioning' to Experimental RFC (draft-ietf-lisp-map-versioning-09.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 15:56:49 -0000 The IESG has approved the following document: - 'LISP Map-Versioning' (draft-ietf-lisp-map-versioning-09.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-map-versioning/ Technical Summary This document specifies an in-packet versioning scheme for LISP mapping data. Working Group Summary This is an output from the LISP WG. The WG process for this document was uneventful. Document Quality This document is a companion document and provides an important function in LISP. It has been well reviewed and this document is in good form. Personnel The Document Shepherd is Terry Manderson, and the responsible Area Director is Jari Arkko. RFC Editor Note Make [I-D.ietf-lisp-interworking] a normative reference. From iesg-secretary@ietf.org Tue Mar 6 12:09:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC8421E80CF; Tue, 6 Mar 2012 12:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EH3+-GSn0lN; Tue, 6 Mar 2012 12:09:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF8821E80D0; Tue, 6 Mar 2012 12:09:04 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306200904.8761.57028.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 12:09:04 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'Interworking LISP with IPv4 and IPv6' to Experimental RFC (draft-ietf-lisp-interworking-06.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 20:09:04 -0000 The IESG has approved the following document: - 'Interworking LISP with IPv4 and IPv6' (draft-ietf-lisp-interworking-06.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-interworking/ Technical Summary This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces a Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. Working Group Summary The work group process for this document was uneventful. Document Quality This document is a descriptive tome for techniques in LISP interoperation. It has had significant review as with all other LISP documents. Personnel The Document Shepherd is Terry Manderson and the responsible Area Director is Jari Arkko. From iesg-secretary@ietf.org Thu Mar 8 09:11:09 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1CA721F84B2; Thu, 8 Mar 2012 09:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNBZ94LAevRk; Thu, 8 Mar 2012 09:11:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1921F864E; Thu, 8 Mar 2012 09:11:08 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308171108.657.65510.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 09:11:08 -0800 Cc: lisp mailing list , lisp chair , RFC Editor Subject: [lisp] Document Action: 'LISP Map Server Interface' to Experimental RFC (draft-ietf-lisp-ms-16.txt) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 17:11:10 -0000 The IESG has approved the following document: - 'LISP Map Server Interface' (draft-ietf-lisp-ms-16.txt) as an Experimental RFC This document is the product of the Locator/ID Separation Protocol Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-lisp-ms/ Technical Summary This draft describes the LISP Map Server (LISP-MS), a computing system which provides a simplified 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 reduce implementation and operational complexity 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. Working Group Summary The Last call for this document was extended to try to capture all concerns. There were concerns raised on caching and security effects. These have been included in the document as identified points in the relevant sections given that the document is Experimental. The SECURITY area required consideration of AKM. Document Quality There are 4 confirmed different implementations of LISP including map-server code, and the document has been reviewed at length with all the other LISP drafts reaching last call. Personnel The Document Shepherd is Joel Halpern and the responsible Area Director is Jari Arkko. From jari.arkko@piuha.net Thu Mar 8 09:25:39 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B21321F85C5; Thu, 8 Mar 2012 09:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gos0ai1FlI2c; Thu, 8 Mar 2012 09:25:38 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFD621F858F; Thu, 8 Mar 2012 09:25:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 394BE2DA0D; Thu, 8 Mar 2012 19:25:35 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmC1LCzarC0J; Thu, 8 Mar 2012 19:25:33 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id EC1E72CC3C; Thu, 8 Mar 2012 19:25:32 +0200 (EET) Message-ID: <4F58EB8C.1000700@piuha.net> Date: Thu, 08 Mar 2012 19:25:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> In-Reply-To: <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> Content-Type: multipart/mixed; boundary="------------080007080800030309000004" Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 17:25:39 -0000 This is a multi-part message in MIME format. --------------080007080800030309000004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for your feedback, John. Would a modified charter with these changes work for you: Jari --------------080007080800030309000004 Content-Type: text/plain; name="charter-as-modified.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="charter-as-modified.txt" Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-03-08 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, completing the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routing scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Provide example specifications for performing cache management and ETR synchronization. - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items (architecture, deployment models, impacts) need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Goals and Milestones September 2012: Submit an architecture description to the IESG for publication as an Experimental RFC September 2012: Submit a deployment model document to the IESG for publication as an Experimental RFC September 2012: Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC October 2012: Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC October 2012: Submit an EID allocation document to the IESG for publication as an Experimental RFC January 2013: Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC January 2013: Publish an example cache management specification. January 2013: Publish an example ETR synchronization specification. March 2013: Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC March 2013: Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. --------------080007080800030309000004 Content-Type: text/html; charset=ISO-8859-1; name="charter-as-modifi-from-propos.diff.html" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="charter-as-modifi-from-propos.diff.html" Diff: charter-as-proposed.txt - charter-as-modified.txt
 charter-as-proposed.txt   charter-as-modified.txt 
Locator/ID Separation Protocol (lisp) Locator/ID Separation Protocol (lisp)
------------------------------------- -------------------------------------
Current Status: Active Current Status: Active
Last updated: 2012-02-14 Last updated: 2012-03-08
Chairs: Chairs:
Joel Halpern <jmh@joelhalpern.com> Joel Halpern <jmh@joelhalpern.com>
Terry Manderson <terry.manderson@icann.org> Terry Manderson <terry.manderson@icann.org>
Internet Area Directors: Internet Area Directors:
Ralph Droms <rdroms.ietf@gmail.com> Ralph Droms <rdroms.ietf@gmail.com>
Jari Arkko <jari.arkko@piuha.net> Jari Arkko <jari.arkko@piuha.net>
Internet Area Advisor: Internet Area Advisor:
skipping to change at line 90 skipping to change at line 90
- LISP security threats and solutions: This document will describe the - LISP security threats and solutions: This document will describe the
security analysis of the LISP system, what issues it needs to security analysis of the LISP system, what issues it needs to
protect against, and a solution that helps defend against those protect against, and a solution that helps defend against those
issues. The replay attack problem discussed on the mailing list issues. The replay attack problem discussed on the mailing list
should be included in this work. should be included in this work.
- Allocation of Endpoint IDentifier (EID) space: This document - Allocation of Endpoint IDentifier (EID) space: This document
requests address space to be used for the LISP experiment as requests address space to be used for the LISP experiment as
identifier space identifier space
- Provide example specifications for performing cache management
and ETR synchronization.
- Alternate mapping system designs: Develop alternative mapping - Alternate mapping system designs: Develop alternative mapping
designs to be tested. designs to be tested.
- Data models for management of LISP. - Data models for management of LISP.
The first three items need to be completed first before other items The first three items (architecture, deployment models, impacts) need
can be submitted as RFCs. The three first documents also need to to be completed first before other items can be submitted as RFCs. The
complement each other, by describing how the architecture supports a three first documents also need to complement each other, by
solution for a particular problem area and how the solution can be describing how the architecture supports a solution for a particular
deployed to help with that problem. problem area and how the solution can be deployed to help with that
problem.
In addition, if work chartered in some other IETF WG requires changes In addition, if work chartered in some other IETF WG requires changes
in the LISP base protocol or any items which directly impact LISP in the LISP base protocol or any items which directly impact LISP
protocol structures, then the LISP WG is chartered to work on such protocol structures, then the LISP WG is chartered to work on such
changes. changes.
It is expected that the results of specifying, implementing, and testing It is expected that the results of specifying, implementing, and testing
LISP will be fed to the general efforts at the IETF and IRTF to LISP will be fed to the general efforts at the IETF and IRTF to
understand which type of a solution is optimal. The LISP WG is not understand which type of a solution is optimal. The LISP WG is not
chartered to develop a standard solution for solving the routing chartered to develop a standard solution for solving the routing
skipping to change at line 137 skipping to change at line 141
October 2012: Submit a LISP threats analysis document to the IESG for October 2012: Submit a LISP threats analysis document to the IESG for
publication as an Experimental RFC publication as an Experimental RFC
October 2012: Submit an EID allocation document to the IESG for October 2012: Submit an EID allocation document to the IESG for
publication as an Experimental RFC publication as an Experimental RFC
January 2013: Submit an lternate mapping system designs to the IESG January 2013: Submit an lternate mapping system designs to the IESG
for publication as an Experimental RFC for publication as an Experimental RFC
January 2013: Publish an example cache management specification.
January 2013: Publish an example ETR synchronization specification.
March 2013: Submit a data model (e.g., a MIB) document to the IESG for March 2013: Submit a data model (e.g., a MIB) document to the IESG for
publication as an Experimental RFC publication as an Experimental RFC
March 2013: Summarize results of specifying, implementing, and testing
LISP and forward to IESG and/or IRTF.
 End of changes. 5 change blocks. 
6 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/
--------------080007080800030309000004-- From jmh@joelhalpern.com Thu Mar 8 09:57:48 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A6F21F86D6 for ; Thu, 8 Mar 2012 09:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcXez4WGolFi for ; Thu, 8 Mar 2012 09:57:47 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70621F86B8 for ; Thu, 8 Mar 2012 09:57:47 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 405DDCD3B1 for ; Thu, 8 Mar 2012 09:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8BC011C0907 for ; Thu, 8 Mar 2012 09:57:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 34C351C084B for ; Thu, 8 Mar 2012 09:57:45 -0800 (PST) Message-ID: <4F58F316.7070905@joelhalpern.com> Date: Thu, 08 Mar 2012 12:57:42 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] congratulations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 17:57:48 -0000 I would like to call the working groups attention to an important achievement. Thanks to the tremendous efforts of the authors, with the approval by the IESG of draft-ietf-lisp-ms-16, all 7 LISP documents which we sent to the IESG have now been approved for publication as RFCs. Thank you, Joel & Terry From darlewis@cisco.com Thu Mar 8 10:25:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EFC21F859A for ; Thu, 8 Mar 2012 10:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.002 X-Spam-Level: X-Spam-Status: No, score=-9.002 tagged_above=-999 required=5 tests=[AWL=1.597, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMWkvhlFLAgr for ; Thu, 8 Mar 2012 10:25:16 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 44C2D21F8505 for ; Thu, 8 Mar 2012 10:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=796; q=dns/txt; s=iport; t=1331231110; x=1332440710; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qsXfgrzxvQ9/SZtpxo+8XqyKLi3ppGrY1EFFi7ZgPrw=; b=IoVUkVm8D6cauMpgIsYrtwHMFzfJhKOyDNTqeDQXWMz+LAwvgLrBMooa IkpQokMZ1w2R/T0aNnOYMmnJgiiwDnMHQdGKEZZ/RZCp1bnyU6IFLDcyP Eam6whRNAjImXd/lSpr4rFBddfygcvvtX+N2BMrW8XqZ7A+1Vn5aTphvK Q=; X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="35190449" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 08 Mar 2012 18:25:10 +0000 Received: from [10.154.215.239] ([10.154.215.239]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q28IP9uh022253; Thu, 8 Mar 2012 18:25:09 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <4F58F316.7070905@joelhalpern.com> Date: Thu, 8 Mar 2012 10:25:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F58F316.7070905@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" Subject: Re: [lisp] congratulations X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 18:25:17 -0000 While all the authors worked hard, and the WG as a whole worked hard as = well, I am utterly convinced that without the diligence, insight, = encouragement, and patience of Jari, Joel, and Terry, these documents = would still be in progress. Thanks guys. -Darrel On Mar 8, 2012, at 9:57 AM, Joel M. Halpern wrote: > I would like to call the working groups attention to an important = achievement. > Thanks to the tremendous efforts of the authors, with the approval by = the IESG of draft-ietf-lisp-ms-16, all 7 LISP documents which we sent to = the IESG have now been approved for publication as RFCs. >=20 > Thank you, > Joel & Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jgs@juniper.net Thu Mar 8 12:56:13 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9561C21F8607; Thu, 8 Mar 2012 12:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9XjsAQ-jIaE; Thu, 8 Mar 2012 12:56:12 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4621F85F0; Thu, 8 Mar 2012 12:56:10 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT1kc6YdbjxVyYe28acgDU4lwkqddEkik@postini.com; Thu, 08 Mar 2012 12:56:12 PST Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 8 Mar 2012 12:51:10 -0800 From: John Scudder To: Jari Arkko Date: Thu, 8 Mar 2012 12:51:10 -0800 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Acz9bTEhFSoZro7BRVCb+DADC+uVCQ== Message-ID: <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> In-Reply-To: <4F58EB8C.1000700@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 20:56:13 -0000 Jari, This is pretty good, thank you. I have one further comment. You guys have p= rioritized three of the work items: "The first three items (architecture, deployment models, impacts) need to be completed first before other items can be submitted as RFCs." But it's not clear to me that these (especially architecture and impacts) c= an be said to have been properly analyzed until some of the lower-priority = items (I'm thinking of threats, cache, ETR sync) have been fleshed out. So = although I understand your desire to move these three forward I question wh= ether the strong mandate to do them first is a good idea. Possibly continue= to state that they're a priority without actually gating other work, so th= at the WG can make its own decision about working on dependencies as needed= ? --John On Mar 8, 2012, at 12:25 PM, Jari Arkko wrote: Thanks for your feedback, John. Would a modified charter with these changes= work for you: Jari From jari.arkko@piuha.net Thu Mar 8 13:13:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE7E21F8683; Thu, 8 Mar 2012 13:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMHrb-K-8odw; Thu, 8 Mar 2012 13:13:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id E7C1521F862A; Thu, 8 Mar 2012 13:13:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E70FE2DA0D; Thu, 8 Mar 2012 23:13:36 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqemv3H_6Xlc; Thu, 8 Mar 2012 23:13:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4522B2CC3C; Thu, 8 Mar 2012 23:13:36 +0200 (EET) Message-ID: <4F5920FF.6070502@piuha.net> Date: Thu, 08 Mar 2012 23:13:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> In-Reply-To: <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 21:13:44 -0000 I hear what you are saying. But I think the opinion in the IESG at least was, however, that those three really are high priority, and that other documents before them are not so useful before they are completed. I guess it is a different perspective, whether you do things top-down or bottom-up. I do agree with both points of view, actually. Jari From barryleiba@gmail.com Thu Mar 8 13:34:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC3F21F8648; Thu, 8 Mar 2012 13:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90DNIuNQPA8A; Thu, 8 Mar 2012 13:34:31 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0CC221F8646; Thu, 8 Mar 2012 13:34:30 -0800 (PST) Received: by obbta4 with SMTP id ta4so1334541obb.31 for ; Thu, 08 Mar 2012 13:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=M//lSNI1QWNBzGqAm2ON2EfwXgGqw1kmtItYP9mDw4I=; b=yZ7n9wuzxSl8BHq+EZNAJStaYOBApwouVJROBrajDSpGUfK5FTIeD+s3+AEfXa8Li+ wty+TXsVUt5bIaAl1tUuH/zFclijNpaIdzFKuBjSlIc7DQ618XjBziQR5qpMt0d5AZ/C 1f2n2S8Qsumu9KgohW0VmgA7P9e0uCBTTrOVAV1J1B/KJ1EiVr3nXHED9j05WBYzbHaC IKouDOGgwbmD2OWXHfVXYmSAVI5c+boLf0NlDrZ4wDOFDbWit5gLg49tENPczT7YMnHB py9vGH3Unovqi2u3QgfUod1BvgJAqiZgt+6933jeLWRsAn1NeWPSLfiqD1hlgRBDWt93 gn5Q== MIME-Version: 1.0 Received: by 10.182.75.103 with SMTP id b7mr425364obw.54.1331242470434; Thu, 08 Mar 2012 13:34:30 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 13:34:30 -0800 (PST) In-Reply-To: <4F5920FF.6070502@piuha.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> Date: Thu, 8 Mar 2012 16:34:30 -0500 X-Google-Sender-Auth: qV5aljO7K0nT7rSw8OSPjzF8QuM Message-ID: From: Barry Leiba To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 09 Mar 2012 08:13:57 -0800 Cc: "lisp@ietf.org" , "iesg@ietf.org IESG" , "ietf@ietf.org list" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 08 Mar 2012 21:34:33 -0000 >> But it's not clear to me that these (especially architecture and impacts) can >> be said to have been properly analyzed until some of the lower-priority items >> (I'm thinking of threats, cache, ETR sync) have been fleshed out. > > I hear what you are saying. But I think the opinion in the IESG at least > was, however, that those three really are high priority, and that other > documents before them are not so useful before they are completed. I guess > it is a different perspective, whether you do things top-down or bottom-up. > I do agree with both points of view, actually. The dependencies (threats, cache, ETR sync, and whatever else) can certainly be discussed to the extent needed to lay out the architecture and other priority documents, with notes taken and saved for when other documents need to be produced. That still says that the working group needs to focus on discussion that leads to the completion of the three priority documents first, before tackling the others. Everyone understands that these priority items can't be developed in a vacuum; we just don't want things to wander off into lower-level details such as protocol elements and text that can wait for the next phase. Barry From internet-drafts@ietf.org Mon Mar 12 16:01:43 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3321E819B; Mon, 12 Mar 2012 16:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R35guFyL5jwb; Mon, 12 Mar 2012 16:01:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2333B21E8197; Mon, 12 Mar 2012 16:01:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312230143.32453.61107.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:01:43 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 23:01:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-03.txt Pages : 25 Date : 2012-03-12 This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-03.txt From ljakab@ac.upc.edu Mon Mar 12 16:07:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A421E81C4 for ; Mon, 12 Mar 2012 16:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.698 X-Spam-Level: X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmekVLhcnQmY for ; Mon, 12 Mar 2012 16:07:08 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.edu [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8E22521E81BD for ; Mon, 12 Mar 2012 16:07:07 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id q2CN75cA016571; Tue, 13 Mar 2012 00:07:05 +0100 Received: from [192.168.0.192] (unknown [89.7.81.27]) by gw.ac.upc.edu (Postfix) with ESMTP id 900942D0017; Tue, 13 Mar 2012 00:07:03 +0100 (CET) Message-ID: <4F5E8197.9010003@ac.upc.edu> Date: Tue, 13 Mar 2012 00:07:03 +0100 From: =?ISO-8859-1?Q?Lor=E1nd_Jakab?= Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: lisp@ietf.org References: <20120312230143.32453.61107.idtracker@ietfa.amsl.com> In-Reply-To: <20120312230143.32453.61107.idtracker@ietfa.amsl.com> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: multipart/mixed; boundary="------------050402010208070802070009" Subject: Re: [lisp] I-D Action: draft-ietf-lisp-deployment-03.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 23:07:12 -0000 This is a multi-part message in MIME format. --------------050402010208070802070009 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, We added a new section with step-by-step instructions for both service providers and their customers on migrating a BGP site to LISP. Diff attached. See you in Paris! Lorand Jakab, on behalf of the authors On 03/13/12 00:01, internet-drafts@ietf.org wrote: > 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 Network Element Deployment Considerations > Author(s) : Lorand Jakab > Albert Cabellos-Aparicio > Florin Coras > Jordi Domingo-Pascual > Darrel Lewis > Filename : draft-ietf-lisp-deployment-03.txt > Pages : 25 > Date : 2012-03-12 > > This document discusses the different scenarios for the deployment of > the new network elements introduced by the Locator/Identifier > Separation Protocol (LISP). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-lisp-deployment-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-deployment-03.txt > > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp --------------050402010208070802070009 Content-Type: text/html; name="draft-ietf-lisp-deployment-02-03.diff.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-02-03.diff.htm" wdiff draft-ietf-lisp-deployment-02.txt draft-ietf-lisp-deployment-03.txt 

Network Working Group                                           L. Jakab
Internet-Draft                                      A. Cabellos-Aparicio
Intended status: Informational                                  F. Coras
Expires: May 4, September 13, 2012                           J. Domingo-Pascual
                                                 Technical University of
                                                               Catalonia
                                                                D. Lewis
                                                           Cisco Systems
                                                        November 1, 2011
                                                          March 12, 2012

             LISP Network Element Deployment Considerations
                   draft-ietf-lisp-deployment-02.txt
                   draft-ietf-lisp-deployment-03.txt

Abstract

   This document discusses the different scenarios for the deployment of
   the new network elements introduced by the Locator/Identifier
   Separation Protocol (LISP).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 4, September 13, 2012.

Copyright Notice

   Copyright (c) 2011 2012 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Split ITR/ETR  . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Inter-Service Provider Traffic Engineering . . . . . . . .  8
     2.5.  Tunnel Routers Behind NAT  . . . . . . . . . . . . . . . . 10
       2.5.1.  ITR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.2.  ETR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.6.  Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
   3.  Map-Resolvers and Map-Servers  . . . . . . . . . . . . . . . . 11
     3.1.  Map-Servers  . . . . . . . . . . . . . . . . . . . . . . . 11
     3.2.  Map-Resolvers  . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13
     4.1.  P-ITR  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.2.  P-ETR  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Migration to LISP  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
     5.3.  Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
     5.4.  Migration Summary  . . . . . . . . . . . . . . . . . . . . 19
   6.  Step-by-Step BGP to LISP Migration Procedure . . . . . . . . . 20
     6.1.  Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20
     6.2.  Customer Activating LISP Service . . . . . . . . . . . . . 21
     6.3.  Cut-Over Provider Preparation and Changes  . . . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7. 22
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8. 23
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9. 23
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1. 23
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2. 23
     10.2. Informative References . . . . . . . . . . . . . . . . . . 21 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 24

1.  Introduction

   The Locator/Identifier Separation Protocol (LISP) addresses the
   scaling issues of the global Internet routing system by separating
   the current addressing scheme into Endpoint IDentifiers (EIDs) and
   Routing LOCators (RLOCs).  The main protocol specification
   [I-D.ietf-lisp] describes how the separation is achieved, which new
   network elements are introduced, and details the packet formats for
   the data and control planes.

   While the boundary between the core and edge is not strictly defined,
   one widely accepted definition places it at the border routers of
   stub autonomous systems, which may carry a partial or complete
   default-free zone (DFZ) routing table.  The initial design of LISP
   took this location as a baseline for protocol development.  However,
   the applications of LISP go beyond of just decreasing the size of the
   DFZ routing table, and include improved multihoming and ingress
   traffic engineering (TE) support for edge networks, and even
   individual hosts.  Throughout the draft we will use the term LISP
   site to refer to these networks/hosts behind a LISP Tunnel Router.
   We formally define it as:

   LISP site:  A single host or a set of network elements in an edge
      network under the administrative control of a single organization,
      delimited from other networks by LISP Tunnel Router(s).

   Since LISP is a protocol which can be used for different purposes, it
   is important to identify possible deployment scenarios and the
   additional requirements they may impose on the protocol specification
   and other protocols.  The main specification [I-D.ietf-lisp] mentions
   positioning of tunnel routers, but without an in-depth discussion.
   This document fills that gap, by exploring the most common cases.
   While the theoretical combinations of device placements are quite
   numerous, the more practical scenarios are given preference in the
   following.

   Additionally, this documents is intended as a guide for the
   operational community for LISP deployments in their networks.  It is
   expected to evolve as LISP deployment progresses, and the described
   scenarios are better understood or new scenarios are discovered.

   Each subsection considers an element type, discussing the impact of
   deployment scenarios on the protocol specification.  For definition
   of terms, please refer to the appropriate documents (as cited in the
   respective sections).

   Comments and discussions about this memo should be directed to the
   LISP working group mailing list: lisp@ietf.org.

2.  Tunnel Routers

   LISP is a map-and-encap protocol, with the main goal of improving
   global routing scalability.  To achieve its goal, it introduces
   several new network elements, each performing specific functions
   necessary to separate the edge from the core.  The device that is the
   gateway between the edge and the core is called Tunnel Router (xTR),
   performing one or both of two separate functions:

   1.  Encapsulating packets originating from an end host to be
       transported over intermediary (transit) networks towards the
       other end-point of the communication

   2.  Decapsulating packets entering from intermediary (transit)
       networks, originated at a remote end host.

   The first function is performed by an Ingress Tunnel Router (ITR),
   the second by an Egress Tunnel Router (ETR).

   Section 8 of the main LISP specification [I-D.ietf-lisp] has a short
   discussion of where Tunnel Routers can be deployed and some of the
   associated advantages and disadvantages.  This section adds more
   detail to the scenarios presented there, and provides additional
   scenarios as well.

2.1.  Customer Edge

   LISP was designed with deployment at the core-edge boundary in mind,
   which can be approximated as the set of DFZ routers belonging to non-
   transit ASes.  For the purposes of this document, we will consider
   this boundary to be consisting of the routers connecting LISP sites
   to their upstreams.  As such, this is the most common expected
   scenario for xTRs, and this document considers it the reference
   location, comparing the other scenarios to this one.

                                ISP1    ISP2
                                 |        |
                                 |        |
                               +----+  +----+
                            +--|xTR1|--|xTR2|--+
                            |  +----+  +----+  |
                            |                  |
                            |     LISP site    |
                            +------------------+

                    Figure 1: xTRs at the customer edge

   From the LISP site perspective the main advantage of this type of
   deployment (compared to the one described in the next section) is
   having direct control over its ingress traffic engineering.  This
   makes it is easy to set up and maintain active/active, active/backup,
   or more complex TE policies, without involving third parties.

   Being under the same administrative control, reachability information
   of all ETRs is easier to synchronize, because the necessary control
   traffic can be allowed between the locators of the ETRs.  A correct
   synchronous global view of the reachability status is thus available,
   and the Loc-Status-Bits can be set correctly in the LISP data header
   of outgoing packets.

   By placing the tunnel router at the edge of the site, existing
   internal network configuration does not need to be modified.
   Firewall rules, router configurations and address assignments inside
   the LISP site remain unchanged.  This helps with incremental
   deployment and allows a quick upgrade path to LISP.  For larger sites
   with many external connections, distributed in geographically diverse
   PoPs, and complex internal topology, it may however make more sense
   to both encapsulate and decapsulate as soon as possible, to benefit
   from the information in the IGP to choose the best path (see
   Section 2.3 for a discussion of this scenario).

   Another thing to consider when placing tunnel routers are MTU issues.
   Since encapsulating packets increases overhead, the MTU of the end-
   to-end path may decrease, when encapsulated packets need to travel
   over segments having close to minimum MTU.  Some transit networks are
   known to provide larger MTU than the typical value of 1500 bytes of
   popular access technologies used at end hosts (e.g., IEEE 802.3 and
   802.11).  However, placing the LISP router connecting to such a
   network at the customer edge could possibly bring up MTU issues,
   depending on the link type to the provider as opposed to the
   following scenario.

2.2.  Provider Edge

   The other location at the core-edge boundary for deploying LISP
   routers is at the Internet service provider edge.  The main incentive
   for this case is that the customer does not have to upgrade the CE
   router(s), or change the configuration of any equipment.
   Encapsulation/decapsulation happens in the provider's network, which
   may be able to serve several customers with a single device.  For
   large ISPs with many residential/business customers asking for LISP
   this can lead to important savings, since there is no need to upgrade
   the software (or hardware, if it's the case) at each client's
   location.  Instead, they can upgrade the software (or hardware) on a
   few PE routers serving the customers.  This scenario is depicted in
   Figure 2.

                  +----------+        +------------------+
                  |   ISP1   |        |       ISP2       |
                  |          |        |                  |
                  |  +----+  |        |  +----+  +----+  |
                  +--|xTR1|--+        +--|xTR2|--|xTR3|--+
                     +----+              +----+  +----+
                        |                  |       |
                        |                  |       |
                        +--<[LISP site]>---+-------+

                          Figure 2: xTR at the PE

   While this approach can make transition easy for customers and may be
   cheaper for providers, the LISP site looses one of the main benefits
   of LISP: ingress traffic engineering.  Since the provider controls
   the ETRs, additional complexity would be needed to allow customers to
   modify their mapping entries.

   The problem is aggravated when the LISP site is multihomed.  Consider
   the scenario in Figure 2: whenever a change to TE policies is
   required, the customer contacts both ISP1 and ISP2 to make the
   necessary changes on the routers (if they provide this possibility).
   It is however unlikely, that both ISPs will apply changes
   simultaneously, which may lead to inconsistent state for the mappings
   of the LISP site.  Since the different upstream ISPs are usually
   competing business entities, the ETRs may even be configured to
   compete, either to attract all the traffic or to get no traffic.  The
   former will happen if the customer pays per volume, the latter if the
   connectivity has a fixed price.  A solution could be to have the
   mappings in the Map-Server(s), and have their operator give control
   over the entries to customer, much like in today's DNS.

   Additionally, since xTR1, xTR2, and xTR3 are in different
   administrative domains, locator reachability information is unlikely
   to be exchanged among them, making it difficult to set Loc-Status-
   Bits correctly on encapsulated packets.

   Compared to the customer edge scenario, deploying LISP at the
   provider edge might have the advantage of diminishing potential MTU
   issues, because the tunnel router is closer to the core, where links
   typically have higher MTUs than edge network links.

2.3.  Split ITR/ETR

   In a simple LISP deployment, xTRs are located at the border of the
   LISP site (see Section 2.1).  In this scenario packets are routed
   inside the domain according to the EID.  However, more complex
   networks may want to route packets according to the destination RLOC.

   This would enable them to choose the best egress point.

   The LISP specification separates the ITR and ETR functionality and
   considers that both entities can be deployed in separated network
   equipment.  ITRs can be deployed closer to the host (i.e., access
   routers).  This way packets are encapsulated as soon as possible, and
   packets exit the network through the best egress point in terms of
   BGP policy.  In turn, ETRs can be deployed at the border routers of
   the network, and packets are decapsulated as soon as possible.
   Again, once decapsulated packets are routed according to the EID, and
   can follow the best path according to internal routing policy.

   In the following figure we can see an example.  The Source (S)
   transmits packets using its EID and in this particular case packets
   are encapsulated at ITR_1.  The encapsulated packets are routed
   inside the domain according to the destination RLOC, and can egress
   the network through the best point (i.e., closer to the RLOC's AS).
   On the other hand, inbound packets are received by ETR_1 which
   decapsulates them.  Then packets are routed towards S according to
   the EID, again following the best path.

      +---------------------------------------+
      |                                       |
      |       +-------+                   +-------+         +-------+
      |       | ITR_1 |---------+         | ETR_1 |-RLOC_A--| ISP_A |
      |       +-------+         |         +-------+         +-------+
      |  +-+        |           |             |
      |  |S|        |    IGP    |             |
      |  +-+        |           |             |
      |       +-------+         |         +-------+         +-------+
      |       | ITR_2 |---------+         | ETR_2 |-RLOC_B--| ISP_B |
      |       +-------+                   +-------+         +-------+
      |                                       |
      +---------------------------------------+

                     Figure 3: Split ITR/ETR Scenario

   This scenario has a set of implications:

   o  The site must carry at least partial BGP routes in order to choose
      the best egress point, increasing the complexity of the network.
      However, this is usually already the case for LISP sites that
      would benefit from this scenario.

   o  If the site is multihomed to different ISPs and any of the
      upstream ISPs is doing uRPF filtering, this scenario may become
      impractical.  ITRs need to determine the exit ETR, for setting the
      correct source RLOC in the encapsulation header.  This adds
      complexity and reliability concerns.

   o  In LISP, ITRs set the reachability bits when encapsulating data
      packets.  Hence, ITRs need a mechanism to be aware of the liveness
      of ETRs.

   o  ITRs encapsulate packets and in order to achieve efficient
      communications, the MTU of the site must be large enough to
      accommodate this extra header.

   o  In this scenario, each ITR is serving fewer hosts than in the case
      when it is deployed at the border of the network.  It has been
      shown that cache hit ratio grows logarithmically with the amount
      of users [cache].  Taking this into account, when ITRs are
      deployed closer to the host the effectiveness of the mapping cache
      may be lower (i.e., the miss ratio is higher).  Another
      consequence of this is that the site will transmit a higher amount
      of Map-Requests, increasing the load on the distributed mapping
      database.

2.4.  Inter-Service Provider Traffic Engineering

   With LISP, two LISP sites can route packets among them and control
   their ingress TE policies.  Typically, LISP is seen as applicable to
   stub networks, however the LISP protocol can also be applied to
   transit networks recursively.

   Consider the scenario depicted in Figure 4.  Packets originating from
   the LISP site Stub1, client of ISP_A, with destination Stub4, client
   of ISP_B, are LISP encapsulated at their entry point into the ISP_A's
   network.  The external IP header now has as the source RLOC an IP
   from ISP_A's address space and destination RLOC from ISP_B's address
   space.  One or more ASes separate ISP_A from ISP_B. With a single
   level of LISP encapsulation, Stub4 has control over its ingress
   traffic.  However, ISP_B only has the current tools (such as BGP
   prefix deaggregation) to control on which of his own upstream or
   peering links should packets enter.  This is either not feasible (if
   fine-grained per-customer control is required, the very specific
   prefixes may not be propagated) or increases DFZ table size.

                                  _.--.
    Stub1 ...   +-------+      ,-''     `--.      +-------+   ... Stub3
             \  |   R_A1|----,'             `. ---|R_B1   |  /
              --|   R_A2|---(     Transit     )   |       |--
    Stub2 .../  |   R_A3|-----.             ,' ---|R_B2   |  \... Stub4
                +-------+      `--.     _.-'      +-------+
          ...     ISP_A            `--''            ISP_B     ...

               Figure 4: Inter-Service provider TE scenario

   A solution for this is to apply LISP recursively.  ISP_A and ISP_B
   may reach a bilateral agreement to deploy their own private mapping
   system.  ISP_A then encapsulates packets destined for the prefixes of
   ISP_B, which are listed in the shared mapping system.  Note that in
   this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3
   as source and R_B1 or R_B2 as destination in the example above).
   ISP_B's ETR removes the outer, second layer of LISP encapsulation
   from the incoming packet, and routes it towards the original RLOC,
   the ETR of Stub4, which does the final decapsulation.

   If ISP_A and ISP_B agree to share a private distributed mapping
   database, both can control their ingress TE without the need of
   disaggregating prefixes.  In this scenario the private database
   contains RLOC-to-RLOC bindings.  The convergence time on the TE
   policies updates is expected to be fast, since ISPs only have to
   update/query a mapping to/from the database.

   This deployment scenario includes two important recommendations.
   First, it is intended to be deployed only between two ISPs (ISP_A and
   ISP_B in Figure 4).  If more than two ISPs use this approach, then
   the xTRs deployed at the participating ISPs must either query
   multiple mapping systems, or the ISPs must agree on a common shared
   mapping system.  Second, the scenario is only recommended for ISPs
   providing connectivity to LISP sites, such that source RLOCs of
   packets to be reencapsulated belong to said ISP.  Otherwise the
   participating ISPs must register prefixes they do not own in the
   above mentioned private mapping system.  Failure to follow these
   recommendations may lead to operational and security issues when
   deploying this scenario.

   Besides these recommendations, the main disadvantages of this
   deployment case are:

   o  Extra LISP header is needed.  This increases the packet size and,
      for efficient communications, it requires that the MTU between
      both ISPs can accommodate double-encapsulated packets.

   o  The ISP ITR must encapsulate packets and therefore must know the
      RLOC-to-RLOC binding.  These bindings are stored in a mapping
      database and may be cached in the ITR's mapping cache.  Cache
      misses lead to an extra lookup latency, unless NERD
      [I-D.lear-lisp-nerd] is used for the lookups.

   o  The operational overhead of maintaining the shared mapping
      database.

   o  If an IPv6 address block is reserved for EID use, as specified in
      [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first
      level) can avoid LISP processing altogether for non-LISP
      destinations.  The ISP tunnel routers however will not be able to
      take advantage of this optimization, all RLOC-to-RLOC mappings
      need a lookup in the private database (or map-cache, once results
      are cached).

2.5.  Tunnel Routers Behind NAT

   NAT in this section refers to IPv4 network address and port
   translation.

2.5.1.  ITR

   Packets encapsulated by an ITR are just UDP packets from a NAT
   device's point of view, and they are handled like any UDP packet,
   there are no additional requirements for LISP data packets.

   Map-Requests sent by an ITR, which create the state in the NAT table
   have a different 5-tuple in the IP header than the Map-Reply
   generated by the authoritative ETR.  Since the source address of this
   packet is different from the destination address of the request
   packet, no state will be matched in the NAT table and the packet will
   be dropped.  To avoid this, the NAT device has to do the following:

   o  Send all UDP packets with source port 4342, regardless of the
      destination port, to the RLOC of the ITR.  The most simple way to
      achieve this is configuring 1:1 NAT mode from the external RLOC of
      the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
      broadband routers).

   o  Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
      the payload.

   This setup supports a single ITR behind the NAT device.

2.5.2.  ETR

   An ETR placed behind NAT is reachable from the outside by the
   Internet-facing locator of the NAT device.  It needs to know this
   locator (and configure a loopback interface with it), so that it can
   use it in Map-Reply and Map-Register messages.  Thus support for
   dynamic locators for the mapping database is needed in LISP
   equipment.

   Again, only one ETR behind the NAT device is supported.

   An implication of the issues described above is that LISP sites with
   xTRs can not be behind carrier based NATs, since two different sites
   would collide on the port forwarding.

2.6.  Summary and Feature Matrix

          Feature                         CE    PE    Split   Rec.
          --------------------------------------------------------
          Control of ingress TE            x     -      x      x
          No modifications to existing
             int. network infrastructure   x     x      -      -
          Loc-Status-Bits sync             x     -      x      x
          MTU/PMTUD issues minimized       -     x      -      x

3.  Map-Resolvers and Map-Servers

3.1.  Map-Servers

   The Map-Server learns EID-to-RLOC mapping entries from an
   authoritative source and publishes them in the distributed mapping
   database.  These entries are learned through authenticated Map-
   Register messages sent by authoritative ETRs.  Also, upon reception
   of a Map-Request, the Map-Server verifies that the destination EID
   matches an EID-prefix for which it is authoritative for, and then re-
   encapsulates and forwards it to a matching ETR.  Map-Server
   functionality is described in detail in [I-D.ietf-lisp-ms].

   The Map-Server is provided by a Mapping Service Provider (MSP).  A
   MSP can be any of the following:

   o  EID registrar.  Since the IPv4 address space is nearing
      exhaustion, IPv4 EIDs will come from already allocated Provider
      Independent (PI) space.  The registrars in this case remain the
      current five Regional Internet Registries (RIRs).  In the case of
      IPv6, the possibility of reserving a /16 block as EID space is
      currently under consideration [I-D.ietf-lisp-eid-block].  If
      granted by IANA, the community will have to determine the body
      responsible for allocations from this block, and the associated
      policies.  For already allocated IPv6 prefixes the principles from
      IPv4 should be applied.

   o  Third parties.  Participating in the LISP mapping system is
      similar to participating in global routing or DNS: as long as
      there is at least another already participating entity willing to
      forward the newcomer's traffic, there is no barrier to entry.
      Still, just like routing and DNS, LISP mappings have the issue of
      trust, with efforts underway to make the published information
      verifiable.  When these mechanisms will be deployed in the LISP
      mapping system, the burden of providing and verifying trust should
      be kept away from MSPs, which will simply host the secured
      mappings.  This will keep the low barrier of entry to become an
      MSP for third parties.

   In all cases, the MSP configures its Map-Server(s) to publish the
   prefixes of its clients in the distributed mapping database and start
   encapsulating and forwarding Map-Requests to the ETRs of the AS.
   These ETRs register their prefix(es) with the Map-Server(s) through
   periodic authenticated Map-Register messages.  In this context, for
   some LISP end sites, there is a need for mechanisms to:

   o  Automatically distribute EID prefix(es) shared keys between the
      ETRs and the EID-registrar Map-Server.

   o  Dynamically obtain the address of the Map-Server in the ETR of the
      AS.

   The Map-Server plays a key role in the reachability of the EID-
   prefixes it is serving.  On the one hand it is publishing these
   prefixes into the distributed mapping database and on the other hand
   it is encapsulating and forwarding Map-Requests to the authoritative
   ETRs of these prefixes.  ITRs encapsulating towards EIDs under the
   responsibility of a failed Map-Server will be unable to look up any
   of their covering prefixes.  The only exception are the ITRs that
   already contain the mappings in their local cache.  In this case ITRs
   can reach ETRs until the entry expires (typically 24 hours).  For
   this reason, redundant Map-Server deployments are desirable.  A set
   of Map-Servers providing high-availability service to the same set of
   prefixes is called a redundancy group.  ETRs are configured to send
   Map-Register messages to all Map-Servers in the redundancy group.  To
   achieve fail-over (or load-balancing, if desired), current known BGP
   practices can be used on the LISP+ALT BGP overlay network.

   Additionally, if a Map-Server has no reachability for any ETR serving
   a given EID block, it should not originate that block into the
   mapping system.

3.2.  Map-Resolvers

   A Map-Resolver a is a network infrastructure component which accepts
   LISP encapsulated Map-Requests, typically from an ITR, and finds the
   appropriate EID-to-RLOC mapping by either consulting its local cache
   or by consulting the distributed mapping database.  Map-Resolver
   functionality is described in detail in [I-D.ietf-lisp-ms].

   Anyone with access to the distributed mapping database can set up a
   Map-Resolver and provide EID-to-RLOC mapping lookup service.  In the
   case of the LISP+ALT mapping system, the Map-Resolver needs to become
   part of the ALT overlay so that it can forward packets to the
   appropriate Map-Servers.  For more detail on how the ALT overlay
   works, see [I-D.ietf-lisp-alt]

   For performance reasons, it is recommended that LISP sites use Map-
   Resolvers that are topologically close to their ITRs.  ISPs
   supporting LISP will provide this service to their customers,
   possibly restricting access to their user base.  LISP sites not in
   this position can use open access Map-Resolvers, if available.
   However, regardless of the availability of open access resolvers, the
   MSP providing the Map-Server(s) for a LISP site should also make
   available Map-Resolver(s) for the use of that site.

   In medium to large-size ASes, ITRs must be configured with the RLOC
   of a Map-Resolver, operation which can be done manually.  However, in
   Small Office Home Office (SOHO) scenarios a mechanism for
   autoconfiguration should be provided.

   One solution to avoid manual configuration in LISP sites of any size
   is the use of anycast RLOCs for Map-Resolvers similar to the DNS root
   server infrastructure.  Since LISP uses UDP encapsulation, the use of
   anycast would not affect reliability.  LISP routers are then shipped
   with a preconfigured list of well know Map-Resolver RLOCs, which can
   be edited by the network administrator, if needed.

   The use of anycast also helps improving mapping lookup performance.
   Large MSPs can increase the number and geographical diversity of
   their Map-Resolver infrastructure, using a single anycasted RLOC.
   Once LISP deployment is advanced enough, very large content providers
   may also be interested running this kind of setup, to ensure minimal
   connection setup latency for those connecting to their network from
   LISP sites.

   While Map-Servers and Map-Resolvers implement different
   functionalities within the LISP mapping system, they can coexist on
   the same device.  For example, MSPs offering both services, can
   deploy a single Map-Resolver/Map-Server in each PoP where they have a
   presence.

4.  Proxy Tunnel Routers

4.1.  P-ITR

   Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP
   transition mechanism, allowing non-LISP sites to reach LISP sites.

   They announce via BGP certain EID prefixes (aggregated, whenever
   possible) to attract traffic from non-LISP sites towards EIDs in the
   covered range.  They do the mapping system lookup, and encapsulate
   received packets towards the appropriate ETR.  Note that for the
   reverse path LISP sites can reach non-LISP sites simply by not
   encapsulating traffic.  See [I-D.ietf-lisp-interworking] for a
   detailed description of P-ITR functionality.

   The success of new protocols depends greatly on their ability to
   maintain backwards compatibility and inter-operate with the
   protocol(s) they intend to enhance or replace, and on the incentives
   to deploy the necessary new software or equipment.  A LISP site needs
   an interworking mechanism to be reachable from non-LISP sites.  A
   P-ITR can fulfill this role, enabling early adopters to see the
   benefits of LISP, similar to tunnel brokers helping the transition
   from IPv4 to IPv6.  A site benefits from new LISP functionality
   (proportionally with existing global LISP deployment) when going
   LISP, so it has the incentives to deploy the necessary tunnel
   routers.  In order to be reachable from non-LISP sites it has two
   options: keep announcing its prefix(es) with BGP, or have a P-ITR
   announce prefix(es) covering them.

   If the goal of reducing the DFZ routing table size is to be reached,
   the second option is preferred.  Moreover, the second option allows
   LISP-based ingress traffic engineering from all sites.  However, the
   placement of P-ITRs significantly influences performance and
   deployment incentives.  Section Section 5 is dedicated to the
   migration to a LISP-enabled Internet, and includes deployment
   scenarios for P-ITRs.

4.2.  P-ETR

   In contrast to P-ITRs, P-ETRs are not required for the correct
   functioning of all LISP sites.  There are two cases, where they can
   be of great help:

   o  LISP sites with unicast reverse path forwarding (uRPF)
      restrictions, and

   o  LISP sites without native IPv6 communicating with LISP nodes with
      IPv6-only locators.

   In the first case, uRPF filtering is applied at their upstream PE
   router.  When forwarding traffic to non-LISP sites, an ITR does not
   encapsulate packets, leaving the original IP headers intact.  As a
   result, packets will have EIDs in their source address.  Since we are
   discussing the transition period, we can assume that a prefix
   covering the EIDs belonging to the LISP site is advertised to the
   global routing tables by a P-ITR, and the PE router has a route
   towards it.  However, the next hop will not be on the interface
   towards the CE router, so non-encapsulated packets will fail uRPF
   checks.

   To avoid this filtering, the affected ITR encapsulates packets
   towards the locator of the P-ETR for non-LISP destinations.  Now the
   source address of the packets, as seen by the PE router is the ITR's
   locator, which will not fail the uRPF check.  The P-ETR then
   decapsulates and forwards the packets.

   The second use case is IPv4-to-IPv6 transition.  Service providers
   using older access network hardware, which only supports IPv4 can
   still offer IPv6 to their clients, by providing a CPE device running
   LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
   sites, with IPv6-only locators.  Packets originating from the client
   LISP site for these destinations would be encapsulated towards the
   P-ETR's IPv4 locator.  The P-ETR is in a native IPv6 network,
   decapsulating and forwarding packets.  For non-LISP destination, the
   packet travels natively from the P-ETR.  For LISP destinations with
   IPv6-only locators, the packet will go through a P-ITR, in order to
   reach its destination.

   For more details on P-ETRs see the [I-D.ietf-lisp-interworking]
   draft.

   P-ETRs can be deployed by ISPs wishing to offer value-added services
   to their customers.  As is the case with P-ITRs, P-ETRs too may
   introduce path stretch.  Because of this the ISP needs to consider
   the tradeoff of using several devices, close to the customers, to
   minimize it, or few devices, farther away from the customers,
   minimizing cost instead.

   Since the deployment incentives for P-ITRs and P-ETRs are different,
   it is likely they will be deployed in separate devices, except for
   the CDN case, which may deploy both in a single device.

   In all cases, the existence of a P-ETR involves another step in the
   configuration of a LISP router.  CPE routers, which are typically
   configured by DHCP, stand to benefit most from P-ETRs.  To enable
   autoconfiguration of the P-ETR locator, a DHCP option would be
   required.

   As a security measure, access to P-ETRs should be limited to
   legitimate users by enforcing ACLs.

5.  Migration to LISP

   This section discusses a deployment architecture to support the
   migration to a LISP-enabled Internet.  The loosely defined terms of
   "early transition phase", "late transition phase", and "LISP Internet
   phase" refer to time periods when LISP sites are a minority, a
   majority, or represent all edge networks respectively.

5.1.  LISP+BGP

   For sites wishing to go LISP with their PI prefix the least
   disruptive way is to upgrade their border routers to support LISP,
   register the prefix into the LISP mapping system, but keep announcing
   it with BGP as well.  This way LISP sites will reach them over LISP,
   while legacy sites will be unaffected by the change.  The main
   disadvantage of this approach is that no decrease in the DFZ routing
   table size is achieved.  Still, just increasing the number of LISP
   sites is an important gain, as an increasing LISP/non-LISP site ratio
   will slowly decrease the need for BGP-based traffic engineering that
   leads to prefix deaggregation.  That, in turn, may lead to a decrease
   in the DFZ size in the late transition phase.

   This scenario is not limited to sites that already have their
   prefixes announced with BGP.  Newly allocated EID blocks could follow
   this strategy as well during the early LISP deployment phase,
   depending on the cost/benefit analysis of the individual networks.
   Since this leads to an increase in the DFZ size, the following
   architecture should be preferred for new allocations.

5.2.  Mapping Service Provider (MSP) P-ITR Service

   In addition to publishing their clients' registered prefixes in the
   mapping system, MSPs with enough transit capacity can offer them
   P-ITR service as a separate service.  This service is especially
   useful for new PI allocations, to sites without existing BGP
   infrastructure, that wish to avoid BGP altogether.  The MSP announces
   the prefix into the DFZ, and the client benefits from ingress traffic
   engineering without prefix deaggregation.  The downside of this
   scenario is path stretch, which may be greater than 1.

   Routing all non-LISP ingress traffic through a third party which is
   not one of its ISPs is only feasible for sites with modest amounts of
   traffic (like those using the IPv6 tunnel broker services today),
   especially in the first stage of the transition to LISP, with a
   significant number of legacy sites.  When the LISP/non-LISP site
   ratio becomes high enough, this approach can prove increasingly
   attractive.

   Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
   deaggregation for traffic engineering purposes, resulting in slower
   routing table increase in the case of new allocations and potential
   decrease for existing ones.  Moreover, MSPs serving different clients
   with adjacent aggregable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

5.3.  Proxy-ITR Route Distribution (PITR-RD)

   Instead of a LISP site, or the MSP, announcing their EIDs with BGP to
   the DFZ, this function can be outsourced to a third party, a P-ITR
   Service Provider (PSP).  This will result in a decrease of the
   operational complexity both at the site and at the MSP.

   The PSP manages a set of distributed P-ITR(s) that will advertise the
   corresponding EID prefixes through BGP to the DFZ.  These P-ITR(s)
   will then encapsulate the traffic they receive for those EIDs towards
   the RLOCs of the LISP site, ensuring their reachability from non-LISP
   sites.

   While it is possible for a PSP to manually configure each client's
   EID routes to be announced, this approach offers little flexibility
   and is not scalable.  This section presents a scalable architecture
   that offers automatic distribution of EID routes to LISP sites and
   service providers.

   The architecture requires no modification to existing LISP network
   elements, but it introduces a new (conceptual) network element, the
   EID Route Server, defined as a router that either propagates routes
   learned from other EID Route Servers, or it originates EID Routes.
   The EID-Routes that it originates are those that it is authoritative
   for.  It propagates these routes to Proxy-ITRs within the AS of the
   EID Route Server.  It is worth to note that a BGP capable router can
   be also considered as an EID Route Server.

   Further, an EID-Route is defined as a prefix originated via the Route
   Server of the mapping service provider, which should be aggregated if
   the MSP has multiple customers inside a single netblock.  This prefix
   is propagated to other P-ITRs both within the MSP and to other P-ITR
   operators it peers with.  EID Route Servers are operated either by
   the LISP site, MSPs or PSPs, and they may be collocated with a Map-
   Server or P-ITR, but are a functionally discrete entity.  They
   distribute EID-Routes, using BGP, to other domains, according to
   policies set by participants.

                              MSP (AS64500)
                              RS ---> P-ITR
                               |        /
                               |  _.--./
                              ,-''    /`--.
             LISP site   ---,' |     v     `.
                           (   |   DFZ       )----- Mapping system
         non-LISP site   ----. |    ^      ,'
                              `--. /   _.-'
                               |  `--''
                               v /
                             P-ITR
                             PSP (AS64501)

            Figure 5: The P-ITR Route Distribution architecture

   The architecture described above decouples EID origination from route
   propagation, with the following benefits:

   o  Can accurately represent business relationships between P-ITR
      operators

   o  More mapping system agnostic (no reliance on ALT)

   o  Minor changes to P-ITR implementation, no changes to other
      components

   In the example in the figure we have a MSP providing services to the
   LISP site.  The LISP site does not run BGP, and gets an EID
   allocation directly from a RIR, or from the MSP, who may be a LIR.
   Existing PI allocations can be migrated as well.  The MSP ensures the
   presence of the prefix in the mapping system, and runs an EID Route
   Server to distribute it to P-ITR service providers.  Since the LISP
   site does not run BGP, the prefix will be originated with the AS
   number of the MSP.

   In the simple case depicted in Figure 5 the EID-Route of LISP Site
   will be originated by the Route Server, and announced to the DFZ by
   the PSP's P-ITRs with AS path 64501 64500.  From that point on, the
   usual BGP dynamics apply.  This way, routes announced by P-ITR are
   still originated by the authoritative Route Server.  Note that the
   peering relationships between MSP/PSPs and those in the underlying
   forwarding plane may not be congruent, making the AS path to a P-ITR
   shorter than it is in reality.

   The non-LISP site will select the best path towards the EID-prefix,
   according to its local BGP policies.  Since AS-path length is usually
   an important metric for selecting paths, a careful placement of P-ITR
   could significantly reduce path-stretch between LISP and non-LISP
   sites.

   The architecture allows for flexible policies between MSP/PSPs.
   Consider the EID Route Server networks as control plane overlays,
   facilitating the implementation of policies necessary to reflect the
   business relationships between participants.  The results are then
   injected to the common underlying forwarding plane.  For example,
   some MSP/PSPs may agree to exchange EID-Prefixes and only announce
   them to each of their forwarding plane customers.  Global
   reachability of an EID-prefix depends on the MSP the LISP site buys
   service from, and is also subject to agreement between the mentioned
   parties.

   In terms of impact on the DFZ, this architecture results in a slower
   routing table increase for new allocations, since traffic engineering
   will be done at the LISP level.  For existing allocations migrating
   to LISP, the DFZ may decrease since MSPs may be able to aggregate the
   prefixes announced.

   Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix
   deaggregation for traffic engineering purposes, resulting in slower
   routing table increase in the case of new allocations and potential
   decrease for existing ones.  Moreover, MSPs serving different clients
   with adjacent aggregable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

   The flexibility and scalability of this architecture does not come
   without a cost however: A PSP operator has to establish either
   transit or peering relationships to improve their connectivity.

5.4.  Migration Summary

   The following table presents the expected effects of the different
   transition scenarios during a certain phase on the DFZ routing table
   size:

    Phase            | LISP+BGP     | MSP P-ITR       | PITR-RD
    -----------------+--------------+-----------------+----------------
    Early transition | no change    | slower increase | slower increase
    Late transition  | may decrease | slower increase | slower increase
    LISP Internet    |             considerable decrease

   It is expected that PITR-RD will co-exist with LISP+BGP during the
   migration, with the latter being more popular in the early transition
   phase.  As the transition progresses and the MSP P-ITR and PITR-RD
   ecosystem gets more ubiquitous, LISP+BGP should become less
   attractive, slowing down the increase of the number of routes in the
   DFZ.

6.  Security Considerations

   Security implications of LISP deployments are  Step-by-Step BGP to be discussed in
   separate documents.  [I-D.saucez-lisp-security] gives an overview LISP Migration Procedure

6.1.  Customer Pre-Install and Pre-Turn-up Checklist

   1.  Determine how many current physical service provider connections
       the customer has and their existing bandwidth and traffic
       engineering requirements.

       This information will determine the number of routing locators,
       and the priorities and weights that should be configured on the
       xTRs.

   2.  Make sure customer router has LISP threat models, while securing mapping lookups capabilities.

       *  Obtain output of 'show version' from the CE router.

          This information can be used to determine if the platform is discussed
          appropriate to support LISP, in
   [I-D.ietf-lisp-sec].

7.  IANA Considerations

   This memo includes no request order to IANA.

8.  Acknowledgements

   Many thanks determine if a
          software and/or hardware upgrade is required.

       *  Have customer upgrade (if necessary, software and/or hardware)
          to Margaret Wasserman for her contribution be LISP capable.

   3.  Obtain current running configuration of CE router.  A suggested
       LISP router configuration example can be customized to the IETF76
   presentation
       customer's existing environment.

   4.  Verify MTU Handling

       *  Request increase in MTU to (1556) on service provider
          connections.  Prior to MTU change verify that kickstarted this work.  The authors would also like 1500 byte packet
          from P-xTR to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
   Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and
   everyone else who provided input.

9.  References

9.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, RLOC with do not fragment (DF-bit) bit set.

       *  Ensure they are not filtering ICMP unreachable or time-
          exceeded on their firewall or router.

       LISP, like any tunneling protocol, will increase the size of
       packets when the LISP header is appended.  If increasing the MTU
       of the access links is not possible, care must be taken that ICMP
       is not being filtered in order to allow for Path MTU Discovery to
       take place.

   5.  Validate member prefix allocation.

       This step is to check if the prefix used by the customer is a
       direct (Provider Independent), or if it is a prefix assigned by a
       physical service provider (Provider Allocated).  If the prefixes
       are assigned by other service provivers then a Letter of
       Agreement is required to announce prefixes through the Proxy
       Service Provider.

   6.  Verify the member RLOCs and their reachability.

       This step ensures that the RLOCs configured on the CE router are
       in fact reachable and working.

   7.  Prepare for cut-over.

       *  If possible, have a host outside of all security and filtering
          policies connected to the console port of the edge router or
          switch.

       *  Make sure customer has access to the router in order to
          configure it.

6.2.  Customer Activating LISP Service

   1.  Customer configures LISP on CE router(s) from service provider
       recommended configuration.

       The LISP configuration consists of the EID prefix, the locators,
       and the weights and priorities of the mapping between the two
       values.  In addition, the xTR must be configured with Map-
       Resolver(s), Map-Server(s) and the shared key for registering to
       Map-Server(s).  If required, Proxy-ETR(s) may be configured as
       well.

       In addition to the LISP configuration, the following:

       *  Ensure default route(s) to next-hop external neighbors are
          included and RLOCs are present in configuration.

       *  If two or more routers are used, ensure all RLOCs are included
          in the LISP configuration on all routers.

       *  It will be necessary to redistribute default route via IGP
          between the external routers.

   2.  When transition is ready perform a soft shutdown on existing eBGP
       peer session(s)

       *  From CE router, use LIG to ensure registration is successful.

       *  To verify LISP connectivity, ping LISP connected sites.  See
          http://www.lisp4.net/ and/or http://www.lisp6.net/ for
          potential candidates.

       *  To verify connectivity to non-LISP sites, try accessing major
          Internet sites via a web browser.

6.3.  Cut-Over Provider Preparation and Changes

   1.  Verify site configuration and then active registration on Map-
       Server(s)

       *  Authentication key

       *  EID prefix

   2.  Add EID space to map-cache on proxies

   3.  Add networks to BGP advertisement on proxies

       *  Modify route-maps/policies on P-xTRs

       *  Modify route policies on core routers (if non-connected
          member)

       *  Modify ingress policers on core routers

       *  Ensure route announcement in looking glass servers, RouteViews

   4.  Perform traffic verification test

       *  Ensure MTU handling is as expected (PMTUD working)

       *  Ensure proxy-ITR map-cache population

       *  Ensure access from traceroute/ping servers around Internet

       *  Use a looking glass, to check for external visibility of
          registration via several Map-Resolvers (e.g.,
          http://lispmon.net/).

7.  Security Considerations

   Security implications of LISP deployments are to be discussed in
   separate documents.  [I-D.saucez-lisp-security] gives an overview of
   LISP threat models, while securing mapping lookups is discussed in
   [I-D.ietf-lisp-sec].

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Acknowledgements

   Many thanks to Margaret Wasserman for her contribution to the IETF76
   presentation that kickstarted this work.  The authors would also like
   to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
   Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and
   everyone else who provided input.

10.  References

10.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-15 (work in progress), July 2011.

   [I-D.ietf-lisp-alt]
              Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
              Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09
              (work in progress), September 2011.

   [I-D.ietf-lisp-interworking]
              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-02 (work in progress),
              June 2011.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server Interface",
              draft-ietf-lisp-ms-12 (work in progress), October 2011.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
              and O. Bonaventure, "LISP-Security (LISP-SEC)",
              draft-ietf-lisp-sec-00 (work in progress), July 2011.

   [I-D.saucez-lisp-security]
              Saucez, D., Iannone, L., and O. Bonaventure, "LISP
              Security Threats", draft-saucez-lisp-security-03 (work in
              progress), March 2011.

9.2.

10.2.  Informative References

   [I-D.ietf-lisp-eid-block]
              Iannone, L.,
              Lewis, D., Meyer, D., Iannone, L., and V. Fuller, "LISP
              EID Block", draft-ietf-lisp-eid-block-01 (work in
              progress), October 2011.

   [I-D.lear-lisp-nerd]
              Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08 (work in progress), March 2010.

   [cache]    Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
              performance and the effectiveness of caching", 2002.

Authors' Addresses

   Lorand Jakab
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: ljakab@ac.upc.edu

   Albert Cabellos-Aparicio
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: acabello@ac.upc.edu

   Florin Coras
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: fcoras@ac.upc.edu
   Jordi Domingo-Pascual
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: jordi.domingo@ac.upc.edu

   Darrel Lewis
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--------------050402010208070802070009-- From internet-drafts@ietf.org Mon Mar 12 16:28:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263221E8191; Mon, 12 Mar 2012 16:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq60k4VMcwVZ; Mon, 12 Mar 2012 16:28:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C0721E801F; Mon, 12 Mar 2012 16:28:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312232816.18069.14229.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:28:16 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-sec-02.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 23:28:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Workin= g Group of the IETF. Title : LISP-Security (LISP-SEC) Author(s) : Fabio Maino Vina Ermagan Albert Cabellos Damien Saucez Olivier Bonaventure Filename : draft-ietf-lisp-sec-02.txt Pages : 20 Date : 2012-03-12 This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lisp-sec-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-lisp-sec-02.txt From vaf@cisco.com Mon Mar 12 17:14:08 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF911E8072 for ; Mon, 12 Mar 2012 17:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.907 X-Spam-Level: X-Spam-Status: No, score=-8.907 tagged_above=-999 required=5 tests=[AWL=1.692, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFX3qLTqrde5 for ; Mon, 12 Mar 2012 17:14:08 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 629AE21F88E0 for ; Mon, 12 Mar 2012 17:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=vaf@cisco.com; l=2597; q=dns/txt; s=iport; t=1331597648; x=1332807248; h=date:from:to:subject:message-id:mime-version; bh=TE6tLShY92MjPVRMDeFq3+4GiAtwW51Pu0gR2h+/Raw=; b=LlbLVz7/h46jPi7YXX6f7FF6JaenorqAy7B9HVoocBp5DAlha/IxA46U MKKt2Xr6yqpcE1MLQwk8i2GzN3DPe7ihXOJSrTCdFkSLIA8NWPPfhK+/b LmcH98PofMpq4gjz2f5hlEC0tMcDzgMVnNG5pVFh7QZNXMdl69m+vZJaJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAC6RXk+rRDoH/2dsb2JhbABCtV2BB4IJAQEBBQEBDwEnNDcDAQJDEwUaBwIhCRmHZwELm1uBJwGfCo1Hgj9jBIhUjHeLL4R1gwM X-IronPort-AV: E=Sophos;i="4.73,574,1325462400"; d="scan'208";a="32856881" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 13 Mar 2012 00:14:08 +0000 Received: from vaf-mac1.cisco.com (vaf-mac1.cisco.com [128.107.165.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2D0E8PX030937 for ; Tue, 13 Mar 2012 00:14:08 GMT Received: by vaf-mac1.cisco.com (Postfix, from userid 113818) id 542A11F74C2A; Mon, 12 Mar 2012 17:14:07 -0700 (PDT) Date: Mon, 12 Mar 2012 17:14:07 -0700 From: Vince Fuller To: lisp@ietf.org Message-ID: <20120313001407.GA29071@vaf-mac1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [lisp] Fwd: I-D Action: draft-fuller-lisp-ddt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 00:14:09 -0000 This version includes a new section (9) describing an authentication mechanism for DDT plus changes to replace the "done" indication with a more general "action" field in Map-Referral messages that is used to signal how a DDT Map-Resolver should proceed with following a referral. Currently, use of the "action" field is only described in section 7; the authors are aware that additional text is needed in sections 5, 6, and 8 but wanted to get a preliminary description of this new functionality published ahead of the IETF 83 I-D deadline. --Vince (for the DDT authors) ----- Forwarded message from internet-drafts@ietf.org ----- Date: Mon, 12 Mar 2012 16:45:50 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-fuller-lisp-ddt-01.txt X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only Errors-To: i-d-announce-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : LISP Delegated Database Tree Author(s) : Vince Fuller Darrel Lewis Filename : draft-fuller-lisp-ddt-01.txt Pages : 35 Date : 2012-03-12 This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fuller-lisp-ddt-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-fuller-lisp-ddt-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From terry.manderson@icann.org Mon Mar 12 21:15:14 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09B21F87E2 for ; Mon, 12 Mar 2012 21:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tF4X7H61PUd for ; Mon, 12 Mar 2012 21:15:13 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id AAA8821F87DC for ; Mon, 12 Mar 2012 21:15:13 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 12 Mar 2012 21:15:11 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 12 Mar 2012 21:15:07 -0700 Thread-Topic: IETF 83 LISP agenda. Thread-Index: Ac0Az99ofMY5LaC2KEihDqk1tD9guA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [lisp] IETF 83 LISP agenda. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 04:15:14 -0000 Folks, I have posted a draft agenda for the LISP session. http://tools.ietf.org/wg/lisp/agenda?item=3Dagenda-83-lisp.txt Please review it and email me any required changes. Due to the number of presentation slots requested, some folk have shorter time slices than originally asked for. Presenters, you will need to adjust your presentation to suit and keeping to the salient points or discussion. Please email me presentations by 9am Tuesday morning (Paris time) in the usual formats. This helps those who participate remotely. Cheers Terry From darlewis@cisco.com Tue Mar 13 10:29:16 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C5821F8675 for ; Tue, 13 Mar 2012 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.102 X-Spam-Level: X-Spam-Status: No, score=-9.102 tagged_above=-999 required=5 tests=[AWL=1.497, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ioj189QB0TaA for ; Tue, 13 Mar 2012 10:29:15 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82421F8674 for ; Tue, 13 Mar 2012 10:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=3435; q=dns/txt; s=iport; t=1331659755; x=1332869355; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zujbpAp7hdLkEm5OpYBuenVRfx/+CgrQ6heWpTtxDfw=; b=bZSYvXGFPt9Br7IKSvwG6G+4qIDLIkXJmaNJll7h7AcQMkq3RYEwgnSe mIotAdYji7Kg0EMihG3i8KwwQP+LQE/6LnGsAs+sRDwBdUh8GpnORqXwV XuaF1mKcGlIFdOobNRSUId2n0TItmKmAFzY2zBEKs+NSULe/fD/3/MqO1 s=; X-IronPort-AV: E=Sophos;i="4.73,578,1325462400"; d="scan'208";a="35830492" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 13 Mar 2012 17:29:15 +0000 Received: from sjc-vpn1-95.cisco.com (sjc-vpn1-95.cisco.com [10.21.96.95]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2DHTEOB010343; Tue, 13 Mar 2012 17:29:14 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <20120313001407.GA29071@vaf-mac1.cisco.com> Date: Tue, 13 Mar 2012 10:29:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <35358BAA-1DFF-4D06-96B8-1BB49B104565@cisco.com> References: <20120313001407.GA29071@vaf-mac1.cisco.com> To: lisp@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [lisp] I-D Action: draft-fuller-lisp-ddt-01.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 17:29:16 -0000 This version, unfortunately, did _not_ include the updates we had = pending for the acknoledgement section. Dino Farinacci, Job Snijders, = Damien Saucez, and Fabio Maino all contributed greatly to the 01 version = of this document, as well as to the implementations and experimentations = going on in support of the mapping systems effort in general. My apologies for not thanking you in this version, we will be sure to = include this in the -02 version. -Darrel On Mar 12, 2012, at 5:14 PM, Vince Fuller wrote: > This version includes a new section (9) describing an authentication > mechanism for DDT plus changes to replace the "done" indication with a > more general "action" field in Map-Referral messages that is used to > signal how a DDT Map-Resolver should proceed with following a = referral. >=20 > Currently, use of the "action" field is only described in section 7; = the > authors are aware that additional text is needed in sections 5, 6, and = 8 > but wanted to get a preliminary description of this new functionality > published ahead of the IETF 83 I-D deadline. >=20 > --Vince > (for the DDT authors) >=20 > ----- Forwarded message from internet-drafts@ietf.org ----- >=20 > Date: Mon, 12 Mar 2012 16:45:50 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-fuller-lisp-ddt-01.txt > X-Original-To: i-d-announce@ietfa.amsl.com > Delivered-To: i-d-announce@ietfa.amsl.com > X-Test-IDTracker: no > X-IETF-IDTracker: 4.00 > Precedence: list > Reply-To: internet-drafts@ietf.org > List-Id: Internet Draft Announcements only > Errors-To: i-d-announce-bounces@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : LISP Delegated Database Tree > Author(s) : Vince Fuller > Darrel Lewis > Filename : draft-fuller-lisp-ddt-01.txt > Pages : 35 > Date : 2012-03-12 >=20 > This draft describes the LISP Delegated Database Tree (LISP-DDT), a > hierarchical, distributed database which embodies the delegation of > authority to provide mappings from LISP Endpoint Identifiers (EIDs) > to Routing Locators (RLOCs). It is a statically-defined = distribution > of the EID namespace among a set of LISP-speaking servers, called = DDT > nodes. Each DDT node is configured as "authoritative" for one or > more EID-prefixes, along with the set of RLOCs for Map-Servers or > "child" DDT nodes to which more-specific EID-prefixes are delegated. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-fuller-lisp-ddt-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-fuller-lisp-ddt-01.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > ----- End forwarded message ----- > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From jgs@juniper.net Tue Mar 13 11:38:17 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142FC21E8059; Tue, 13 Mar 2012 11:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfRAgCTUypW9; Tue, 13 Mar 2012 11:38:16 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id B132321E8019; Tue, 13 Mar 2012 11:38:15 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+UABF4xCzr8WQwdQWFCibuBj2wyazH@postini.com; Tue, 13 Mar 2012 11:38:16 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Tue, 13 Mar 2012 11:37:06 -0700 From: John Scudder To: Barry Leiba Date: Tue, 13 Mar 2012 11:37:05 -0700 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Ac0BSEoZUP3kQBwNQNeUNM+ApKZgZA== Message-ID: <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "lisp@ietf.org" , "iesg@ietf.org IESG" , "ietf@ietf.org list" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 18:38:17 -0000 Barry and all, On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote: ... >>> But it's not clear to me that these (especially architecture and impact= s) can >>> be said to have been properly analyzed until some of the lower-priority= items >>> (I'm thinking of threats, cache, ETR sync) have been fleshed out. >>=20 >> I hear what you are saying. But I think the opinion in the IESG at least >> was, however, that those three really are high priority, and that other >> documents before them are not so useful before they are completed. I gue= ss >> it is a different perspective, whether you do things top-down or bottom-= up. >> I do agree with both points of view, actually. >=20 > The dependencies (threats, cache, ETR sync, and whatever else) can > certainly be discussed to the extent needed to lay out the > architecture and other priority documents, with notes taken and saved > for when other documents need to be produced. That still says that > the working group needs to focus on discussion that leads to the > completion of the three priority documents first, before tackling the > others. Everyone understands that these priority items can't be > developed in a vacuum; we just don't want things to wander off into > lower-level details such as protocol elements and text that can wait > for the next phase. You don't want to boil the ocean; that's fine. My point is that without cov= ering (at least) cache management and ETR synchronization, the architecture= will not be done. Think about the old joke about the mathematical proof th= at includes "... then a miracle occurs" as one of its steps (http://star.ps= y.ohio-state.edu/coglab/Miracle.html). Similarly, threats and the impacts d= ocument. One way to handle this (other than what I've already suggested) might be to= explicitly note that the respective documents should cover these topics. F= or example (edits set off by [[ ]]): - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. [[The document will cover relevant issues including though not limited to cache management and ETR synchronization.]] and - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. [[The document will discuss potential security- related impacts, whether positive or negative.]]=20 =20 Regards, --John= From jmh@joelhalpern.com Tue Mar 13 12:04:44 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6321E8060; Tue, 13 Mar 2012 12:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8twS8KkXQDU; Tue, 13 Mar 2012 12:04:43 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5495721E8057; Tue, 13 Mar 2012 12:04:43 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E413FCCFC8; Tue, 13 Mar 2012 12:04:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6291926152B; Tue, 13 Mar 2012 12:04:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 423EB2613AC; Tue, 13 Mar 2012 12:04:40 -0700 (PDT) Message-ID: <4F5F9A44.4020600@joelhalpern.com> Date: Tue, 13 Mar 2012 15:04:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> In-Reply-To: <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 19:04:44 -0000 Actually John, I would have to disagree with your assertion about what it takes to describe the archtiecture. It may take engineering and evaluating some cache management schemes before one can decide whether the archtiecture is a good one. But that is very different from being able to describe the archteicture so that one can understand the system level behavior. Yours, Joel On 3/13/2012 2:37 PM, John Scudder wrote: > Barry and all, > > On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote: > ... >>>> But it's not clear to me that these (especially architecture and impacts) can >>>> be said to have been properly analyzed until some of the lower-priority items >>>> (I'm thinking of threats, cache, ETR sync) have been fleshed out. >>> >>> I hear what you are saying. But I think the opinion in the IESG at least >>> was, however, that those three really are high priority, and that other >>> documents before them are not so useful before they are completed. I guess >>> it is a different perspective, whether you do things top-down or bottom-up. >>> I do agree with both points of view, actually. >> >> The dependencies (threats, cache, ETR sync, and whatever else) can >> certainly be discussed to the extent needed to lay out the >> architecture and other priority documents, with notes taken and saved >> for when other documents need to be produced. That still says that >> the working group needs to focus on discussion that leads to the >> completion of the three priority documents first, before tackling the >> others. Everyone understands that these priority items can't be >> developed in a vacuum; we just don't want things to wander off into >> lower-level details such as protocol elements and text that can wait >> for the next phase. > > You don't want to boil the ocean; that's fine. My point is that without covering (at least) cache management and ETR synchronization, the architecture will not be done. Think about the old joke about the mathematical proof that includes "... then a miracle occurs" as one of its steps (http://star.psy.ohio-state.edu/coglab/Miracle.html). Similarly, threats and the impacts document. > > One way to handle this (other than what I've already suggested) might be to explicitly note that the respective documents should cover these topics. For example (edits set off by [[ ]]): > > - Architecture description: This document will describe the > architecture of the entire LISP system, making it easier to read the > rest of the LISP specifications and providing a basis for discussion > about the details of the LISP protocols. [[The document will > cover relevant issues including though not limited to cache > management and ETR synchronization.]] > > and > > - A description of the impacts of LISP: This document will describe > the problems that LISP is intended to address and the impacts that > employing LISP has. While the work on LISP was initiated by Internet > routing scaling concerns, there has also been an interest on > improved solutions to a number of different problems, such as > traffic engineering. This document should describe problem areas > (such as scaling or traffic engineer) where LISP is expected to have > a positive effect, as well as any tradeoffs that are caused by > LISP's design. [[The document will discuss potential security- > related impacts, whether positive or negative.]] > > Regards, > > --John > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > From jgs@juniper.net Tue Mar 13 12:24:35 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA1721E806A; Tue, 13 Mar 2012 12:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BauAJlo+Nju2; Tue, 13 Mar 2012 12:24:33 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6104121E8024; Tue, 13 Mar 2012 12:24:33 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+e41BhkNLNhETxSD92BOHp6x0TEljf@postini.com; Tue, 13 Mar 2012 12:24:33 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 13 Mar 2012 12:23:21 -0700 From: John Scudder To: "Joel M. Halpern" Date: Tue, 13 Mar 2012 12:23:20 -0700 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Ac0BTsCkcu2c2EazTrO88abiPtK/mg== Message-ID: <754A7276-FC6F-4C76-8627-4AEDB5FBB4C4@juniper.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> In-Reply-To: <4F5F9A44.4020600@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 19:24:35 -0000 Joel, Re cache management schemes, I think that depends on whether you mean "syst= em level behavior" of a small-scale system, or one operating at large scale= or under some kind of stress. The earlier discussion notwithstanding, for = practical purposes caching is central to LISP; as such, it's a little weird= to say it's architecturally unimportant. Re ETR sync, I think not even that much wiggle room exists. --John On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote: Actually John, I would have to disagree with your assertion about what it takes to describe the archtiecture. It may take engineering and evaluating some cache management schemes before one can decide whether the archtiecture is a good one. But that is very different from being able to describe the archteicture so that one can understand the system level behavior. Yours, Joel On 3/13/2012 2:37 PM, John Scudder wrote: Barry and all, On Mar 8, 2012, at 4:34 PM, Barry Leiba wrote: ... But it's not clear to me that these (especially architecture and impacts) c= an be said to have been properly analyzed until some of the lower-priority ite= ms (I'm thinking of threats, cache, ETR sync) have been fleshed out. I hear what you are saying. But I think the opinion in the IESG at least was, however, that those three really are high priority, and that other documents before them are not so useful before they are completed. I guess it is a different perspective, whether you do things top-down or bottom-up. I do agree with both points of view, actually. The dependencies (threats, cache, ETR sync, and whatever else) can certainly be discussed to the extent needed to lay out the architecture and other priority documents, with notes taken and saved for when other documents need to be produced. That still says that the working group needs to focus on discussion that leads to the completion of the three priority documents first, before tackling the others. Everyone understands that these priority items can't be developed in a vacuum; we just don't want things to wander off into lower-level details such as protocol elements and text that can wait for the next phase. You don't want to boil the ocean; that's fine. My point is that without cov= ering (at least) cache management and ETR synchronization, the architecture= will not be done. Think about the old joke about the mathematical proof th= at includes "... then a miracle occurs" as one of its steps (http://star.ps= y.ohio-state.edu/coglab/Miracle.html). Similarly, threats and the impacts d= ocument. One way to handle this (other than what I've already suggested) might be to= explicitly note that the respective documents should cover these topics. F= or example (edits set off by [[ ]]): - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. [[The document will cover relevant issues including though not limited to cache management and ETR synchronization.]] and - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. [[The document will discuss potential security- related impacts, whether positive or negative.]] Regards, --John _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From lear@cisco.com Tue Mar 13 12:43:53 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4621F8496; Tue, 13 Mar 2012 12:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVYNvXw5PiTW; Tue, 13 Mar 2012 12:43:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B76D421F8484; Tue, 13 Mar 2012 12:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=698; q=dns/txt; s=iport; t=1331667832; x=1332877432; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=OUk2bvCpX8AP+OOxoU10AZriwLM6bnpkMJcV2oMmKq0=; b=VxyP16yFJmKjluT/FoGMM6jyQT8dYsBQdglgWa15VglAZmO1y6QVpPsJ A6pPzw4xogyp+yRBCM0sz731zL1EwF8zkKnULhRPSPlendHuKIW+VPNmi DYrzQ1OyG+6Lf7CcdGoURiZ4WFjIU5tM3kN/x+v1dMdDlgK4OoW8y4+ey A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHOiX0+Q/khL/2dsb2JhbABDhTqwMoEHggkBAQEEEgEQVhALDgQGAgIFIQICDwI4DgYNAQcBAR6HaJx8AYxxkg6BL44ggRYElVCQI4Jm X-IronPort-AV: E=Sophos;i="4.73,579,1325462400"; d="scan'208";a="132220039" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2012 19:43:50 +0000 Received: from dhcp-10-61-99-194.cisco.com (dhcp-10-61-99-194.cisco.com [10.61.99.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DJho8V022595; Tue, 13 Mar 2012 19:43:50 GMT Message-ID: <4F5FA375.20908@cisco.com> Date: Tue, 13 Mar 2012 20:43:49 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <754A7276-FC6F-4C76-8627-4AEDB5FBB4C4@juniper.net> In-Reply-To: <754A7276-FC6F-4C76-8627-4AEDB5FBB4C4@juniper.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , Barry Leiba , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 19:43:53 -0000 John, On 3/13/12 8:23 PM, John Scudder wrote: > Re cache management schemes, I think that depends on whether you mean "system level behavior" of a small-scale system, or one operating at large scale or under some kind of stress. The earlier discussion notwithstanding, for practical purposes caching is central to LISP; as such, it's a little weird to say it's architecturally unimportant. I don't think Joel is saying that it is architecturally unimportant, but rather that within the architecture it various caching schemes may work better than others, and that experience may dictate the answer to this. What are system effects, by the way, is its own interesting question. Eliot From jnc@mercury.lcs.mit.edu Tue Mar 13 12:53:28 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCC321F8637; Tue, 13 Mar 2012 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrCJkNUvUsoT; Tue, 13 Mar 2012 12:53:27 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E037421F8636; Tue, 13 Mar 2012 12:53:26 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CE16B18C0BA; Tue, 13 Mar 2012 15:53:25 -0400 (EDT) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20120313195325.CE16B18C0BA@mercury.lcs.mit.edu> Date: Tue, 13 Mar 2012 15:53:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: iesg@ietf.org, jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 19:53:28 -0000 > From: John Scudder > Re cache management schemes, I think that depends on whether you > mean "system level behavior" of a small-scale system, or one > operating at large scale or under some kind of stress. The earlier > discussion notwithstanding, for practical purposes caching is > central to LISP; as such, it's a little weird to say it's > architecturally unimportant. I didn't hear him say that. I think he said 'the details of particular cache management algorithm(s) aren't important to an _architectural_ understanding of LISP'. Now, what you mean by 'architectural understanding' and what I (and probably Joel) mean by 'architectural understanding' may be two different things, which may be the source of the problem. What I mean by that term is 'how is the entire system broken up into subsystems' (i.e. what are the functional units), and 'how do they interact'. I.e. a very high-level view of how the system as a whole operates - an overview in which more detailed views of individual subsystems can be slotted. That is something totally different from 'a complete model/understanding of how the system operates in various operational environments', which is somewhere in the direction of what you seem to want? Now, clearly the latter is something useful to have, but I'd like to point out that in its maximum generality it may be a 'boil the ocean' kind of goal. E.g. to have a complete and total understanding of how, say, the Internet path selection system as whole operates, you'd have to model every last piece of it (every router, etc, etc), because there's no analytical proof that it operates in any particular way. However, of necessity, any such a model is probably infeasible - we can build smaller models, and see how they operate, but they can only offer limited insight (how limited, we cannot say for sure) into just how the full-scale system is going to work. To do that, we just built it (why do multi-dimensional mice come to mind here?), and we can instrument it and watch it (as numerous studies have done, e.g. the very fine work by Craig Leibowitz and Abha Ahuja some years ago). But any sub-full-scale model is necessarily going to be 'an incomplete description of reality', to use the fine phrase from EPR. Which is not to say that better understanding of how the caching in LISP works in various operating environments (e.g. under various kinds of attack/stress), and how different potential cache management algorithms would work across a range of operational scenarios, is not useful and/or desirable. Of course it would be. (Do we have any volunteers? A considerable amount of work on caching simulation has already been done, but of course there's an infinite space of possible things to explore, both on the algorithm side and the operational scenario side.) However, i) such work is not a 'description of the architecture' as I understand it, nor ii) is it _absolutely_ necessary before trying a system in large scale, because to do it 'perfectly' is an impossible 'chicken and egg' situation: there is no perfect model _other than the system itself_. The only way to _really_ see how it works is to build it. Or am I too misunderstanding something? Noel From dino@cisco.com Tue Mar 13 21:07:02 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EE121E803A; Tue, 13 Mar 2012 21:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.544 X-Spam-Level: X-Spam-Status: No, score=-8.544 tagged_above=-999 required=5 tests=[AWL=2.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mood94f7Xl0b; Tue, 13 Mar 2012 21:07:02 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 72A4121E800F; Tue, 13 Mar 2012 21:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=507; q=dns/txt; s=iport; t=1331698021; x=1332907621; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=M0ZAlKs7Kx625UmWCSPJSHH28X53dKfv/4VuneONPv4=; b=QOm431QjYJNhMjdsJSJYWwf9A7HqhVZnGiupKd8GxvJt6FuQs9sDLDVY VWAUZJdvDi5TxD26iMkQTMVRNmNWbsPfEanHmyPR/m3Mj7reejBF3J7Vj 2RuFGBGCvU58cJslawOMXAJekWCA0TcQ/DvlyxD/YiUaNaooTnl6iVyc2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHgYYE+rRDoG/2dsb2JhbABDtXiBB4IJAQEBAwESASc/BQsLDgQ0SQ4GNYdjBJ0TAZ52kBNjBIhVjHuQI4MF X-IronPort-AV: E=Sophos;i="4.73,582,1325462400"; d="scan'208";a="36034430" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 14 Mar 2012 04:07:01 +0000 Received: from sjc-vpn6-920.cisco.com (sjc-vpn6-920.cisco.com [10.21.123.152]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2E4703t005754; Wed, 14 Mar 2012 04:07:00 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <754A7276-FC6F-4C76-8627-4AEDB5FBB4C4@juniper.net> Date: Tue, 13 Mar 2012 21:07:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <754A7276-FC6F-4C76-8627-4AEDB5FBB4C4@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1251.1) Cc: "iesg@ietf.org IESG" , "ietf@ietf.org list" , Barry Leiba , "lisp@ietf.org" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 04:07:03 -0000 > Re ETR sync, I think not even that much wiggle room exists. I beg to differ. What happens if an iBGP mesh is not configured = properly? Does that mean the BGP architecture is broken?=20 We have said in the past, several times, that if the ETRs are out of = sync, then the ITR that gets a Map-Reply from one of them, then the ITR = uses the locators configured from that ETR. The system works, if it is = misconfigured, it works less well. So I believe the issue could be closed IMO. Dino From jgs@juniper.net Wed Mar 14 07:41:16 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D819E21F87F4; Wed, 14 Mar 2012 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnPwkWNVU0A1; Wed, 14 Mar 2012 07:41:16 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id C862921F86DC; Wed, 14 Mar 2012 07:41:14 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT2CuB7PrVbh6xX/ZhYJ5yic0xog7j5VC@postini.com; Wed, 14 Mar 2012 07:41:15 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 14 Mar 2012 07:40:37 -0700 From: John Scudder To: "Joel M. Halpern" Date: Wed, 14 Mar 2012 07:40:36 -0700 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Ac0B8Gt+smnlt48ASum0SgXOaKipqw== Message-ID: <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> In-Reply-To: <4F5F9A44.4020600@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Barry Leiba , "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 14:41:17 -0000 One further remark: On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote: ... > It may take engineering and evaluating some cache management schemes=20 > before one can decide whether the archtiecture is a good one. ... Agreed. Isn't it relevant to the architecture document, that it be possible for a r= eader to judge whether the architecture is a good one or not? --John= From jmh@joelhalpern.com Wed Mar 14 07:46:41 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B121F8810; Wed, 14 Mar 2012 07:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uPPap1VZRbt; Wed, 14 Mar 2012 07:46:40 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8D21F880F; Wed, 14 Mar 2012 07:46:40 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 627CF103D71; Wed, 14 Mar 2012 07:46:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E91C11C0870; Wed, 14 Mar 2012 07:46:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E7D421C0801; Wed, 14 Mar 2012 07:46:38 -0700 (PDT) Message-ID: <4F60AF4D.1090506@joelhalpern.com> Date: Wed, 14 Mar 2012 10:46:37 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John Scudder References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> In-Reply-To: <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 14:46:41 -0000 Relevant? Yes. Gating? No. In fact, I would put it the other way around. The architecture documentis very useful, almost necessary, for deciding whether the solution is a good one. The cache management evaluations are another component of such an evaluation. Even understanding the cache management quesiton is made significantly easier by having a clean architecture description. Yours, Joel On 3/14/2012 10:40 AM, John Scudder wrote: > One further remark: > > On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote: > ... >> It may take engineering and evaluating some cache management schemes >> before one can decide whether the archtiecture is a good one. > ... > > Agreed. > > Isn't it relevant to the architecture document, that it be possible for a reader to judge whether the architecture is a good one or not? > > --John From jgs@juniper.net Wed Mar 14 08:21:07 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2578D21E805F; Wed, 14 Mar 2012 08:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.503 X-Spam-Level: X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMpqI37gThNi; Wed, 14 Mar 2012 08:21:06 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id D13F121E8054; Wed, 14 Mar 2012 08:21:05 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT2C3XO2x9QV1wWEcgUg68uEeZ8+wLoQI@postini.com; Wed, 14 Mar 2012 08:21:06 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 14 Mar 2012 08:20:27 -0700 From: John Scudder To: Barry Leiba Date: Wed, 14 Mar 2012 08:20:26 -0700 Thread-Topic: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) Thread-Index: Ac0B9fxBhSt98SA/Tw+ckfZkDHOfBw== Message-ID: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> <4F60AF4D.1090506@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 15:21:07 -0000 Barry, On Mar 14, 2012, at 11:02 AM, Barry Leiba wrote: Relevant? Yes. Gating? No. In fact, I would put it the other way around. The architecture documentis very useful, almost necessary, for deciding whether the solution is a good one. The cache management evaluations are another component of such an evaluation. Even understanding the cache management question is made significantly easier by having a clean architecture description. Indeed. At the risk of straining things with an analogy, I'll liken this to architecture of a building. At the architecture level, we do have to consider, say, bathrooms, and it's reasonable at that level to talk about having bathrooms on each floor, and perhaps the extent to which accessible bathrooms are needed. Deciding whether to have two pairs or three per floor is something that can be left to the detailed post-architecture specifications, and things like what sorts of fixtures to put in them *absolutely* come later. No one is saying that some discussion of caching issues (etc) won't be needed in defining and specifying the architecture. We're just saying that it's not necessary to do the caching document before, as long as the related discussion that happens at the architecture stage is preserved for when it's time to work on the caching doc. Analogies are always risky, but I'll continue. I don't think the proper ana= logy is a bathroom. Everyone knows you can build bathrooms that work, havin= g seen successful examples in the past. You might instead think of a buildi= ng which includes a perpetual motion machine [*] as a key element. --John [*] Forgive me, press of time prevents me from finding an example which is = both less inflammatory, and still has the property "something whose practic= ability is debatable." Feel free to fill in your favorite. From jnc@mercury.lcs.mit.edu Wed Mar 14 14:30:33 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A9B11E8080; Wed, 14 Mar 2012 14:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r68iWKiSzuHz; Wed, 14 Mar 2012 14:30:33 -0700 (PDT) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B411E807F; Wed, 14 Mar 2012 14:30:32 -0700 (PDT) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1419F18C0B1; Wed, 14 Mar 2012 17:30:32 -0400 (EDT) To: ietf@ietf.org, lisp@ietf.org Message-Id: <20120314213032.1419F18C0B1@mercury.lcs.mit.edu> Date: Wed, 14 Mar 2012 17:30:32 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 21:30:33 -0000 > From: John Scudder > On Mar 13, 2012, at 3:04 PM, Joel M. Halpern wrote: >> It may take engineering and evaluating some cache management >> schemes > Isn't it relevant to the architecture document, that it be possible > for a reader to judge whether the architecture is a good one or not? Yes and no. At the _architectural_ level, the details of the algorithms are not generally visible - and, more importantly, as explained below, in a 'good' architecture, it's _designed_ so that algorithms can be changed. (As Corbato so neatly put it in his Multics design paper, without the ability to change course, one has a boat without a rudder.) So in one sense, no, it's not an 'architectural' issue. However, an architecture might be a failure if there is _no possible_ algorithm which can perform a certain required function. But that condition is awfully hard to ascertain (it's hard to prove a negative). For some insight into this, look at TCP: _could_ you say, looking at the TCP specs circa 1977, that it was "[architecturally] a good [design] or not"? Even more importantly, was it right to go off and build the Internet, with the retransmission/etc algorithms we had in TCP in the late 1970s? (Especially given that the retransmission algorithms later turned out to be colossally wrong, leading to congestive collapse of the network about 5 years later.) Sometimes you just gotta go build it and see what happens, and see if smart people can figure out ways around whatever issues crop up. Not being able to absolutely, cast-iron prove, a priori up front, that it's feasible, is not a reasonable requirement: had we had that in place in the late 1970s, we'd never have built the Internet. _At an architectural level_, TCP did have one thing going for it with regard to its algorithms: the retransmission, window management, etc, algorithms could be replaced piece-meal (i.e. we did not have to have a co-ordinated flag day). That really saved our bacon when it turned out they had issues (and not just with retranmission - I actually remember Silly Window Syndrome). The same thing is true of the cache management algorithm(s) in the xTRs. There's no requirement that everyone run the same one, and if the current cache management algorithms turns out to have issues, it will be no more hassle to change them than it was to change TCP's retransmission algorithm. So, at the _architectural level_, LISP's cache management does have that desirable property: we can experiment with new ones, and deploy better ones, whenever we want. Also, some sites might have load patterns that are different from othersm, so that we might want to run different cache management algorithms in different places. Again, _at an architectural level_, this turns out to be trivial to do. Noel From barryleiba@gmail.com Wed Mar 14 08:02:57 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB921F87E3; Wed, 14 Mar 2012 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyC5PS+oZJdj; Wed, 14 Mar 2012 08:02:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3BC321F87DE; Wed, 14 Mar 2012 08:02:56 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2184956ghb.31 for ; Wed, 14 Mar 2012 08:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TXhmMWoIbKpL1RsyCpTUJRDMKzKgXXw/SUDxW5eAmdY=; b=iOnzqVniaFlhpvogkfKaNdQhsARW9u3k0LamsT2PhaYV5++q0dzueTmjVKKHECqz4/ jMEzb6xtyieORIw10QkBrj0eJexZ2rA12/bH5wlrV5Ni49pmvyeIugsO6S/ouFLqtrue cEVUcgH1BS0lycD103zWf1wdKiuslAIb5XBZZ/EENkOl8PCblzf6+w3vFKPsguzLV7NE iTiGrcQYGJP2pOiUjqIpg1pab/sWmDNkudldrggf41sT96DUlVEsEROmJUf87mW+mzBA aGhUHolORszqzpEWyPoimZdY4gHbkHg7ejTSO/JeajWww/kuVoJghYXUX/hRBHd7Etn6 hiXQ== MIME-Version: 1.0 Received: by 10.60.3.226 with SMTP id f2mr3652820oef.44.1331737376285; Wed, 14 Mar 2012 08:02:56 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Wed, 14 Mar 2012 08:02:56 -0700 (PDT) In-Reply-To: <4F60AF4D.1090506@joelhalpern.com> References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> <4F60AF4D.1090506@joelhalpern.com> Date: Wed, 14 Mar 2012 11:02:56 -0400 X-Google-Sender-Auth: uWi4mvr14vVtrLitAePYCs5zLz8 Message-ID: From: Barry Leiba To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 15 Mar 2012 08:37:45 -0700 Cc: "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 15:02:57 -0000 > Relevant? =A0Yes. > Gating? =A0No. > > In fact, I would put it the other way around. > The architecture documentis very useful, almost necessary, for deciding > whether the solution is a good one. > The cache management evaluations are another component of such an > evaluation. > Even understanding the cache management question is made significantly > easier by having a clean architecture description. Indeed. At the risk of straining things with an analogy, I'll liken this to architecture of a building. At the architecture level, we do have to consider, say, bathrooms, and it's reasonable at that level to talk about having bathrooms on each floor, and perhaps the extent to which accessible bathrooms are needed. Deciding whether to have two pairs or three per floor is something that can be left to the detailed post-architecture specifications, and things like what sorts of fixtures to put in them *absolutely* come later. No one is saying that some discussion of caching issues (etc) won't be needed in defining and specifying the architecture. We're just saying that it's not necessary to do the caching document before, as long as the related discussion that happens at the architecture stage is preserved for when it's time to work on the caching doc. Barry From barryleiba@gmail.com Wed Mar 14 08:30:09 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E631F21F862F; Wed, 14 Mar 2012 08:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-bk5V2IlO2U; Wed, 14 Mar 2012 08:30:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 044EB21F871C; Wed, 14 Mar 2012 08:30:01 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2221844yhp.31 for ; Wed, 14 Mar 2012 08:30:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=A/hKsbHXToTiiTvyMO1zk/8V0PvtnZhFxGx2+ays9qM=; b=mb6CTmYDSSNLSIGcnwZEWnXPonM638nTFC9X3riS7jTAF6t4ratMaGRH9kVVSnAsIY kPY//A2PWLk+wS44gAt+H3h9wf55fO5fSeVKVKzc2HoBxcyARyfAw/L4ZKk5ftYuHkt7 piqkevCvG/tkDOD6QG4/jFAdBixKvZaohAQs9AKoIi7kWsqmIf67jaG5eo42hCwpDlH4 Ceh/9iYYKuz3XfKtUsnes/VOaoFN4JQEYNTie0L/EOxoXDYLJcmYc5a0UI/V+StBQbkb te1XFLPJh3cYWR/xJoyonD2AR8x6LWdglHYY9Xu1JUIULGBLoneDP9PRTR0uGMCZ3H5S pUUw== MIME-Version: 1.0 Received: by 10.60.3.2 with SMTP id 2mr3948340oey.0.1331739001561; Wed, 14 Mar 2012 08:30:01 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Wed, 14 Mar 2012 08:30:01 -0700 (PDT) In-Reply-To: References: <20120214222316.CF29521E800E@ietfa.amsl.com> <201202152131.q1FLVB9E028114@cichlid.raleigh.ibm.com> <4F3E4EDB.7070509@piuha.net> <0E0C6A25-FBA6-4E11-9E89-DEBFFCF41108@juniper.net> <4F58EB8C.1000700@piuha.net> <70EB276F-D77E-45AE-851C-AB08A8D56D0A@juniper.net> <4F5920FF.6070502@piuha.net> <1D2FF8E9-8E60-4126-AC30-12DFDC854BC6@juniper.net> <4F5F9A44.4020600@joelhalpern.com> <7CDFAED4-30C6-4CC4-BA91-F8B34857C9B4@juniper.net> <4F60AF4D.1090506@joelhalpern.com> Date: Wed, 14 Mar 2012 11:30:01 -0400 X-Google-Sender-Auth: ZIQ2weE9InOLHI5QRL4r2TvigIA Message-ID: From: Barry Leiba To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 15 Mar 2012 08:37:45 -0700 Cc: "ietf@ietf.org list" , "lisp@ietf.org" , "iesg@ietf.org IESG" Subject: Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 15:30:10 -0000 > I don't think the proper analogy > is a bathroom. Everyone knows you can build bathrooms that work, having > seen successful examples in the past. You might instead think of a building > which includes a perpetual motion machine [*] as a key element. Fair enough, and now I understand where you fall on the issue. I agree that my analogy wasn't fully to the point. But here's the question: Do you really think the entire discussion has to finish in order to do a meaningful architecture? Is it not possible for the architecture document to have a section about perpetual-motion machines caching that talks about the needs, the benefits, the drawbacks, and the tradeoffs, and leaves the final design and decisions for later? Such a section might well explain why the required caching is difficult, bordering on impossible to get right, or whatever. At this level, do we need to *resolve* the questions and all the design points? Or is it possible to have a useful document that helps everyone understand the issues, while leaving many of those issues unresolved until later? Barry From iesg-secretary@ietf.org Mon Mar 19 09:40:40 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8021F887D; Mon, 19 Mar 2012 09:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diiUroTv6RW1; Mon, 19 Mar 2012 09:40:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115C321F87E2; Mon, 19 Mar 2012 09:40:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120319164040.8576.20854.idtracker@ietfa.amsl.com> Date: Mon, 19 Mar 2012 09:40:40 -0700 Cc: lisp@ietf.org Subject: [lisp] WG Action: RECHARTER: Locator/ID Separation Protocol (lisp) X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 16:40:41 -0000 The Locator/ID Separation Protocol (lisp) working group in the Internet = Area of the IETF has been rechartered. For additional information, = please contact the Area Directors or the working group Chairs. Locator/ID Separation Protocol (lisp) ------------------------------------- Current Status: Active Last updated: 2012-03-15 Chairs: Joel Halpern Terry Manderson Internet Area Directors: Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Secretaries: Wassim Haddad Luigi Iannone Mailing Lists: General Discussion: lisp@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/lisp Archive: http://www.ietf.org/mail-archive/web/lisp/current/= maillist.html Description of Working Group: The IAB's October 2006 Routing and Addressing Workshop (RFC 4984) rekindled interest in scalable routing and addressing architectures for the Internet. Among the many issues driving this renewed interest are concerns about the scalability of the routing system. Since the IAB workshop, several proposals have emerged which attempt to address the concerns expressed there and elsewhere. In general, these proposals are based on the "locator/identifier separation". The basic idea behind the separation is that the Internet architecture combines two functions, routing locators, (where you are attached to the network) and identifiers (who you are) in one number space: The IP address. Proponents of the separation architecture postulate that splitting these functions apart will yield several advantages, including improved scalability for the routing system. The separation aims to decouple locators and identifiers, thus allowing for efficient aggregation of the routing locator space and providing persistent identifiers in the identifier space. A number of approaches are being looked at in parallel in other contexts. The IRTF RRG examined several proposals, some of which were published as IRTF-track Experimental RFCs. The LISP WG has completed the first set of Experimental RFCs describing the Locator/ID Separation Protocol. LISP requires no changes to end-systems or to routers that do not directly participate in the LISP deployment. LISP aims for an incrementally deployable protocol. The LISP WG is chartered to continue work on the LISP base protocol, comple= ting the ongoing work, and any items which directly impact LISP protocol structures and which are related to using LISP for improving Internet routi= ng scalability. Specifically, the group will work on: - Architecture description: This document will describe the architecture of the entire LISP system, making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. The document will include a description of the cache management and ETR synchronization essential characteristics needed to ensure the correct operation of the protocol. - Deployment models: This document will describe what kind of deployments can be expected for LISP, and give operational advice on how they can be set up. - A description of the impacts of LISP: This document will describe the problems that LISP is intended to address and the impacts that employing LISP has. While the work on LISP was initiated by Internet routing scaling concerns, there has also been an interest on improved solutions to a number of different problems, such as traffic engineering. This document should describe problem areas (such as scaling or traffic engineer) where LISP is expected to have a positive effect, as well as any tradeoffs that are caused by LISP's design. - LISP security threats and solutions: This document will describe the security analysis of the LISP system, what issues it needs to protect against, and a solution that helps defend against those issues. The replay attack problem discussed on the mailing list should be included in this work. - Allocation of Endpoint IDentifier (EID) space: This document requests address space to be used for the LISP experiment as identifier space - Alternate mapping system designs: Develop alternative mapping designs to be tested. - Data models for management of LISP. The first three items (architecture, deployment models, impacts) need to be completed first before other items can be submitted as RFCs. The three first documents also need to complement each other, by describing how the architecture supports a solution for a particular problem area and how the solution can be deployed to help with that problem. In addition, if work chartered in some other IETF WG requires changes in the LISP base protocol or any items which directly impact LISP protocol structures, then the LISP WG is chartered to work on such changes. It is expected that the results of specifying, implementing, and testing LISP will be fed to the general efforts at the IETF and IRTF to understand which type of a solution is optimal. The LISP WG is not chartered to develop a standard solution for solving the routing scalability problem at this time. The specifications developed by the WG are Experimental and labeled with accurate disclaimers about their limitations and not fully understood implications for Internet traffic. In addition, as these issues are understood, the working group will analyze and document the implications of LISP on Internet traffic, applications, routers, and security. Goals and Milestones September 2012: Submit an architecture description to the IESG for publication as an Experimental RFC September 2012: Submit a deployment model document to the IESG for publication as an Experimental RFC September 2012: Submit a LISP impact discussion document to the IESG for publication as an Experimental RFC October 2012: Submit a LISP threats analysis document to the IESG for publication as an Experimental RFC October 2012: Submit an EID allocation document to the IESG for publication as an Experimental RFC January 2013: Submit an lternate mapping system designs to the IESG for publication as an Experimental RFC March 2013: Submit a data model (e.g., a MIB) document to the IESG for publication as an Experimental RFC March 2013: Summarize results of specifying, implementing, and testing LISP and forward to IESG and/or IRTF. From terry.manderson@icann.org Mon Mar 26 00:43:15 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0A21F856A for ; Mon, 26 Mar 2012 00:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.534 X-Spam-Level: X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38w3nEjYfe7N for ; Mon, 26 Mar 2012 00:43:14 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7F90F21F8555 for ; Mon, 26 Mar 2012 00:43:14 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 26 Mar 2012 00:43:14 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Mon, 26 Mar 2012 00:43:12 -0700 Thread-Topic: IETF 83 LISP agenda. Thread-Index: Ac0Az99ofMY5LaC2KEihDqk1tD9guAKVDkA5 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [lisp] IETF 83 LISP agenda. X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 07:43:15 -0000 Just a reminder to presenters. Slides as soon as you can please. I put on my grumpy face 9:01am Tuesday ;-) Cheers Terry On 13/03/12 2:15 PM, "Terry" wrote: >=20 > Please email me presentations by 9am Tuesday morning (Paris time) in the = usual > formats. This helps those who participate remotely. >=20 > Cheers > Terry From robert@raszuk.net Tue Mar 27 12:51:45 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8521E80EC for ; Tue, 27 Mar 2012 12:51:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiIUIrttGXpq for ; Tue, 27 Mar 2012 12:51:44 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D2DB221E8143 for ; Tue, 27 Mar 2012 12:51:43 -0700 (PDT) Received: (qmail 8206 invoked by uid 399); 27 Mar 2012 19:51:43 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:m42@mojaklasa.info@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 27 Mar 2012 19:51:43 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F721A51.4040901@raszuk.net> Date: Tue, 27 Mar 2012 21:51:45 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "lisp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net 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 Mar 2012 19:51:45 -0000 Hi, During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and LISP-DDT Database Transfer stated that this is very much like DNS. Likewise the drafts say it too: http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer. http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt Think of a LISP-DDT query as the analog to a DNS name server (NS) query, and a LISP map request as the analog to a DNS address (A) query (LISP-DDT does not store the EID to RLOC mappings returned in a map request). Said this I would like to ask why not use new instance of DNS with DNSSEC completely independent on current name resolution DNS here ? It walks like a duck .. it quacks like a duck .. it must be a duck ! Defining new set of records and leveraging a lot of work which went into (and still going) into DNS one could think would make a lot of sense rather then reinventing the wheel. If not .. if DDT approach can not be serviced by DNS architecture I think it would be very useful to document why. Also in the same time it would be great to announce plans for open source DDT support ? Many thx, R. From olivier.bonaventure@uclouvain.be Tue Mar 27 13:08:41 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0960F21F8526 for ; Tue, 27 Mar 2012 13:08:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XojteocSNdeg for ; Tue, 27 Mar 2012 13:08:40 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id E4DD721F852C for ; Tue, 27 Mar 2012 13:08:39 -0700 (PDT) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 71F8B1C5D05; Tue, 27 Mar 2012 22:08:32 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 71F8B1C5D05 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1332878912; bh=BJ6UklOBSLeWLiFEU+ydWQ9WZayPDvYkLyzZ5WcLxgo=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=unIluohhfpb3wrm4bkV2BRQM5Ymio/tk9Ar6X7pmLmlNfl+tgFafN5oCddBxvIX72 wwpjGIMarLDnKBi/NkD61app0XZXr2QmhJY0so5f37p80mRzAhzhs4T5JECDDm78DY KIkhMvvzQSiak7bas+Vq0IJ4ED7MKK7U3fPZ76Rc= Message-ID: <4F721E40.8030806@uclouvain.be> Date: Tue, 27 Mar 2012 22:08:32 +0200 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: robert@raszuk.net References: <4F721A51.4040901@raszuk.net> In-Reply-To: <4F721A51.4040901@raszuk.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 71F8B1C5D05.A4EC0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be 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 Mar 2012 20:08:41 -0000 Robert, > > During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and > LISP-DDT Database Transfer stated that this is very much like DNS. See also the original LISP-TREE paper for more details on the benefits of such a mapping system http://inl.info.ucl.ac.be/publications/lisp-tree-dns-hierarchy-support-lisp-mapping-system > > Said this I would like to ask why not use new instance of DNS with > DNSSEC completely independent on current name resolution DNS here ? > > It walks like a duck .. it quacks like a duck .. it must be a duck ! > > Defining new set of records and leveraging a lot of work which went into > (and still going) into DNS one could think would make a lot of sense > rather then reinventing the wheel. > > If not .. if DDT approach can not be serviced by DNS architecture I > think it would be very useful to document why. Also in the same time it > would be great to announce plans for open source DDT support ? One of the issues that I see in reusing the DNS is the LISP would have to support the (very old) history of DNS and the various protocol extensions. Bitlabel would seem the best way of encoding mappings, but bitlabels have been deprecated http://tools.ietf.org/html/rfc3363 which means that LISP could not simply reuse existing DNS servers. If there are modifications required to the DNS, then seems more realistic to avoid using an already overloaded protocol like the DNS. Although I was initially in favor of reusing the DNS, I changed my mind... Olivier -- INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be From robert@raszuk.net Tue Mar 27 13:24:58 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3724921F8757 for ; Tue, 27 Mar 2012 13:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYG3tXYb7HjR for ; Tue, 27 Mar 2012 13:24:57 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAEE21F8743 for ; Tue, 27 Mar 2012 13:24:57 -0700 (PDT) Received: (qmail 7757 invoked by uid 399); 27 Mar 2012 20:24:43 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 27 Mar 2012 20:24:43 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F72220C.8080002@raszuk.net> Date: Tue, 27 Mar 2012 22:24:44 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Olivier.Bonaventure@uclouvain.be References: <4F721A51.4040901@raszuk.net> <4F721E40.8030806@uclouvain.be> In-Reply-To: <4F721E40.8030806@uclouvain.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net 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 Mar 2012 20:24:58 -0000 Hello Olivier, Let me clarify. I am not suggesting to reuse existing DNS servers at all. I am just suggesting (well not even that .. trying to understand why this is bad idea) to reuse existing DNS/DNSSEC code on completely opaque to the DNS and DNS infrastructure deployment. Effectively to fully follow LISP DDT principals however reused existing DNS bind with all of the latest enhancements. Best regards, R. > Robert, >> >> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and >> LISP-DDT Database Transfer stated that this is very much like DNS. > > > See also the original LISP-TREE paper for more details on the benefits > of such a mapping system > http://inl.info.ucl.ac.be/publications/lisp-tree-dns-hierarchy-support-lisp-mapping-system >> >> Said this I would like to ask why not use new instance of DNS with >> DNSSEC completely independent on current name resolution DNS here ? >> >> It walks like a duck .. it quacks like a duck .. it must be a duck ! >> >> Defining new set of records and leveraging a lot of work which went into >> (and still going) into DNS one could think would make a lot of sense >> rather then reinventing the wheel. >> >> If not .. if DDT approach can not be serviced by DNS architecture I >> think it would be very useful to document why. Also in the same time it >> would be great to announce plans for open source DDT support ? > > > One of the issues that I see in reusing the DNS is the LISP would have > to support the (very old) history of DNS and the various protocol > extensions. Bitlabel would seem the best way of encoding mappings, but > bitlabels have been deprecated http://tools.ietf.org/html/rfc3363 which > means that LISP could not simply reuse existing DNS servers. If there > are modifications required to the DNS, then seems more realistic to > avoid using an already overloaded protocol like the DNS. > > Although I was initially in favor of reusing the DNS, I changed my mind... > > > Olivier > From dino@cisco.com Tue Mar 27 15:25:54 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAAC21E813E for ; Tue, 27 Mar 2012 15:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.728 X-Spam-Level: X-Spam-Status: No, score=-8.728 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0j6pIX8fyAc for ; Tue, 27 Mar 2012 15:25:53 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CB84321E813D for ; Tue, 27 Mar 2012 15:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dino@cisco.com; l=1853; q=dns/txt; s=iport; t=1332887153; x=1334096753; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=c+ZFCDPPsIV3voBLMgV2CFYW78IwFzcBuZUCtWs6vtQ=; b=HpXoeVKeQgReaZ58avN08ZIBmw7HJcphlMsTxr1RqQD9XiAcwQzvT7e3 ZH80ccVRmTj4TPc97mv/lOrPpUOfp3e5Ih51pgeYafSMo8HHZ8arzQumM 5TXHvZLn29AHA/peNnSPxIL8i2gE+1ggZrRyzwqtmk1KP/OLKRdP2VsBL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABE+ck+rRDoG/2dsb2JhbABFuGWBB4IJAQEBAwEBAQEPASc0CwULCxI0JyIOEAkih2MEDJsMnwaNa4JBYwSIWI0JgRGNNIFogwc X-IronPort-AV: E=Sophos;i="4.73,659,1325462400"; d="scan'208";a="37841062" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 27 Mar 2012 22:25:53 +0000 Received: from sjc-vpn5-223.cisco.com (sjc-vpn5-223.cisco.com [10.21.88.223]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2RMPqx5022486; Tue, 27 Mar 2012 22:25:52 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Dino Farinacci In-Reply-To: <4F721A51.4040901@raszuk.net> Date: Tue, 27 Mar 2012 15:25:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E0371CC-F242-4A70-8C4F-1B7BB1D6FE73@cisco.com> References: <4F721A51.4040901@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 22:25:54 -0000 > Hi, >=20 > During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and > LISP-DDT Database Transfer stated that this is very much like DNS. >=20 > Likewise the drafts say it too: >=20 > http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 >=20 > Conceptually, > this is similar to the way that a client of the Domain Name System > (DNS) follows referrals (DNS responses that contain only NS records) > from a series of DNS servers until it finds an answer. >=20 > http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt >=20 > Think of a LISP-DDT query as the analog to a DNS name server (NS) > query, and a LISP map request as the analog to a DNS address (A) > query (LISP-DDT does not store the EID to RLOC mappings returned in = a > map request). What we mean is that it uses the same models as DNS. It does not use the = DNS protocol. > Said this I would like to ask why not use new instance of DNS with = DNSSEC completely independent on current name resolution DNS here ? >=20 > It walks like a duck .. it quacks like a duck .. it must be a duck ! Because it is too hard to encode long power-of-2 addresses in the DNS = name string. > Defining new set of records and leveraging a lot of work which went = into (and still going) into DNS one could think would make a lot of = sense rather then reinventing the wheel. And we did not want features like recursive lookups and DNSSEC, per = spec. > If not .. if DDT approach can not be serviced by DNS architecture I = think it would be very useful to document why. Also in the same time it = would be great to announce plans for open source DDT support ? Dino >=20 > Many thx, > R. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From damien.saucez@gmail.com Tue Mar 27 16:09:18 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9321E8024 for ; Tue, 27 Mar 2012 16:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okExM8EwwHWf for ; Tue, 27 Mar 2012 16:09:17 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A178B21E801B for ; Tue, 27 Mar 2012 16:09:17 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so282886wgb.13 for ; Tue, 27 Mar 2012 16:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wFoEqKUYIwoVcQ9euexDm+iVZIsXcM8+8BWWgsdnRDU=; b=vpluDXoogWAYPchrrHmmL38ol0827cV7J1K2fczlz47kWz95sfjPzVsvjpGjZwq/aL +N6PelLDySUSH7Txxc88f7QGCp6Smg2pALGdf9UbAPwSbkUFKh68rCdXmBXlYr9xuUf8 uD2JDKZ5ukjnB+XKFNxEK9TgSTIL/5fSFFa7KVw3QnWZSAGVZqPt03H2qCuw7DhnrSTh R4UndskM9IYpmvpq3zV54uQrZU48p8/G5BJy3GLYDYB7HAqdcmA0i5mRC5tPFTu7YeBM VkNKiJvzAgBZ5C3qzwUcWLUgqrNGI5HSqsccjpWKKJcN6MB2T1J6bjMoZOFYkBVmcKRX SPKA== Received: by 10.216.196.29 with SMTP id q29mr3598743wen.12.1332889756383; Tue, 27 Mar 2012 16:09:16 -0700 (PDT) Received: from [192.168.0.146] (AMontsouris-152-1-62-180.w83-202.abo.wanadoo.fr. [83.202.72.180]) by mx.google.com with ESMTPS id j3sm5209308wiw.1.2012.03.27.16.09.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 16:09:14 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <3E0371CC-F242-4A70-8C4F-1B7BB1D6FE73@cisco.com> Date: Wed, 28 Mar 2012 01:09:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F721A51.4040901@raszuk.net> <3E0371CC-F242-4A70-8C4F-1B7BB1D6FE73@cisco.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1257) Cc: LISP mailing list list Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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 Mar 2012 23:09:18 -0000 On 28 Mar 2012, at 00:25, Dino Farinacci wrote: >> Hi, >>=20 >> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and >> LISP-DDT Database Transfer stated that this is very much like DNS. >>=20 >> Likewise the drafts say it too: >>=20 >> http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 >>=20 >> Conceptually, >> this is similar to the way that a client of the Domain Name System >> (DNS) follows referrals (DNS responses that contain only NS records) >> from a series of DNS servers until it finds an answer. >>=20 >> http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt >>=20 >> Think of a LISP-DDT query as the analog to a DNS name server (NS) >> query, and a LISP map request as the analog to a DNS address (A) >> query (LISP-DDT does not store the EID to RLOC mappings returned in = a >> map request). >=20 > What we mean is that it uses the same models as DNS. It does not use = the DNS protocol. >=20 >> Said this I would like to ask why not use new instance of DNS with = DNSSEC completely independent on current name resolution DNS here ? >>=20 >> It walks like a duck .. it quacks like a duck .. it must be a duck ! >=20 > Because it is too hard to encode long power-of-2 addresses in the DNS = name string. >=20 >> Defining new set of records and leveraging a lot of work which went = into (and still going) into DNS one could think would make a lot of = sense rather then reinventing the wheel. >=20 > And we did not want features like recursive lookups and DNSSEC, per = spec. >=20 >> If not .. if DDT approach can not be serviced by DNS architecture I = think it would be very useful to document why. Also in the same time it = would be great to announce plans for open source DDT support ? >=20 I complete agree that using DNS protocol is not the best idea, even if = we proposed it in the academic paper (ref given by Olivier). First, as Dino and Olivier = say, DNS as it is today, is not very good at "boundary less" prefix matching (binary encoded = names). Second, because the name is of limited size in number of characters you might have = troubles with long addresses with instance ID because of the way you have to encode. And = the final two points, which have been pointed out by Isidor, is that (i) negative mappings are = not implementable as-is in DNS and more importantly (ii) DNS caching is poor for the LISP = usage as it is caches the information with the exact matching and not the wildcard reply. = However, I let Isidor extending the discussion on these two points as his the guy that = discovered that (so I give to Cesar what belongs to Cesar!) So what I would conclude, is that while thinking about the problem, DNS = seems to be the solution, but while implementing it, it is clearly no adapted. The = changes to fit DNS to the purpose are very limited but somehow fundamentals so I have the = impression that the efforts necessary to map DDT to DNS are not worth w.r.t. the = complexity of implementing them, the machinery to start at the IETF to add the new features needing = in DNS specs, and linking DNS with all the LISP microcosm. Particularly as implementing = LISP-DDT is very easy as most of the code is the same as the code used at the ITR, MR, MS = and ETR, so at the end, DDT forms a nice continuous package with the rest of LISP = (i.e., same encoding, same terminology, same mechanism, same code) Thank you, Damien Saucez > Dino >=20 >>=20 >> Many thx, >> R. >> _______________________________________________ >> 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 From gwiley@verisign.com Tue Mar 27 23:25:12 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6521F8733 for ; Tue, 27 Mar 2012 23:25:12 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3dfw9dCMhgT for ; Tue, 27 Mar 2012 23:25:12 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3D421F8732 for ; Tue, 27 Mar 2012 23:25:11 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKT3KuxFyn0EGD8lYBk3UVd/cBAPJhVShU@postini.com; Tue, 27 Mar 2012 23:25:11 PDT Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q2S6P7gu027687; Wed, 28 Mar 2012 02:25:07 -0400 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 02:25:07 -0400 Received: from BRN1WNEXCAS02.vcorp.ad.vrsn.com ([10.173.152.206]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 02:25:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 28 Mar 2012 02:25:06 -0400 From: "Wiley, Glen" To: "'robert@raszuk.net'" , "'lisp@ietf.org'" Thread-Topic: [lisp] DDT vs DNS Thread-Index: AQHNDFMTx6AiCOzt5EeSsSenikBDn5Z/PmGN Date: Wed, 28 Mar 2012 06:25:05 +0000 Message-ID: <641EE49757824F4BBE5F863B22FDDBF20C8A12@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <4F721A51.4040901@raszuk.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.174] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Mar 2012 06:25:07.0459 (UTC) FILETIME=[850A2D30:01CD0CAB] Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 06:25:13 -0000 Nifty idea, as a dns operator that would make it easy for us :) Having said that, dns is useful as a common point of reference to help expl= ain ddt but has significant enough differences (and the joy of dodging lega= cy baggage) to make a separate protocol a sensible option. ----- Original Message ----- From: Robert Raszuk [mailto:robert@raszuk.net] Sent: Tuesday, March 27, 2012 03:51 PM=0A= To: lisp@ietf.org Subject: [lisp] DDT vs DNS Hi, During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and LISP-DDT Database Transfer stated that this is very much like DNS. Likewise the drafts say it too: http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 Conceptually, this is similar to the way that a client of the Domain Name System (DNS) follows referrals (DNS responses that contain only NS records) from a series of DNS servers until it finds an answer. http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt Think of a LISP-DDT query as the analog to a DNS name server (NS) query, and a LISP map request as the analog to a DNS address (A) query (LISP-DDT does not store the EID to RLOC mappings returned in a map request). Said this I would like to ask why not use new instance of DNS with=20 DNSSEC completely independent on current name resolution DNS here ? It walks like a duck .. it quacks like a duck .. it must be a duck ! Defining new set of records and leveraging a lot of work which went into=20 (and still going) into DNS one could think would make a lot of sense=20 rather then reinventing the wheel. If not .. if DDT approach can not be serviced by DNS architecture I=20 think it would be very useful to document why. Also in the same time it=20 would be great to announce plans for open source DDT support ? Many thx, R. _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From hoefling@informatik.uni-tuebingen.de Wed Mar 28 00:11:11 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF85321E8161 for ; Wed, 28 Mar 2012 00:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6j9nDS7y8Px for ; Wed, 28 Mar 2012 00:11:11 -0700 (PDT) Received: from mx5.informatik.uni-tuebingen.de (mx5.Informatik.Uni-Tuebingen.De [134.2.12.32]) by ietfa.amsl.com (Postfix) with SMTP id B135A21E80E3 for ; Wed, 28 Mar 2012 00:11:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AB2F752A3 for ; Wed, 28 Mar 2012 09:11:04 +0200 (MEST) X-Virus-Scanned: amavisd-new at informatik.uni-tuebingen.de Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5.informatik.uni-tuebingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnqS6Zm9mruZ for ; Wed, 28 Mar 2012 09:10:58 +0200 (MEST) Received: from zcs-bs.informatik.uni-tuebingen.de (zcs-bs.Informatik.Uni-Tuebingen.De [134.2.12.62]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C7C7F528D for ; Wed, 28 Mar 2012 09:10:58 +0200 (MEST) Received: from [130.129.8.176] (dhcp-90b0.meeting.ietf.org [130.129.8.176]) by zcs-bs.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3ED0E415FAE0 for ; Wed, 28 Mar 2012 09:10:58 +0200 (CEST) Message-ID: <4F72B978.5030509@informatik.uni-tuebingen.de> Date: Wed, 28 Mar 2012 09:10:48 +0200 From: Michael Hoefling Organization: Unversity of Tuebingen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: lisp@ietf.org References: <641EE49757824F4BBE5F863B22FDDBF20C8A12@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <641EE49757824F4BBE5F863B22FDDBF20C8A12@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 07:11:12 -0000 As far as I got it, LISP-DDT is based on the ideas of LISP-TREE, which is based on DNS. Just in case you're not familiar with LISP-TREE, take a look on this paper for more information: http://inl.info.ucl.ac.be/system/files/2010-jakab-jsac-lisp-tree.pdf Regards, Michael Am 28.03.2012 08:25, schrieb Wiley, Glen: > Nifty idea, as a dns operator that would make it easy for us :) > > Having said that, dns is useful as a common point of reference to help explain ddt but has significant enough differences (and the joy of dodging legacy baggage) to make a separate protocol a sensible option. > > ----- Original Message ----- > From: Robert Raszuk [mailto:robert@raszuk.net] > Sent: Tuesday, March 27, 2012 03:51 PM > To: lisp@ietf.org > Subject: [lisp] DDT vs DNS > > Hi, > > During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and > LISP-DDT Database Transfer stated that this is very much like DNS. > > Likewise the drafts say it too: > > http://tools.ietf.org/html/draft-fuller-lisp-ddt-00 > > Conceptually, > this is similar to the way that a client of the Domain Name System > (DNS) follows referrals (DNS responses that contain only NS records) > from a series of DNS servers until it finds an answer. > > http://tools.ietf.org/id/draft-wiley-lisp-ddtxfer-01.txt > > Think of a LISP-DDT query as the analog to a DNS name server (NS) > query, and a LISP map request as the analog to a DNS address (A) > query (LISP-DDT does not store the EID to RLOC mappings returned in a > map request). > > Said this I would like to ask why not use new instance of DNS with > DNSSEC completely independent on current name resolution DNS here ? > > It walks like a duck .. it quacks like a duck .. it must be a duck ! > > Defining new set of records and leveraging a lot of work which went into > (and still going) into DNS one could think would make a lot of sense > rather then reinventing the wheel. > > If not .. if DDT approach can not be serviced by DNS architecture I > think it would be very useful to document why. Also in the same time it > would be great to announce plans for open source DDT support ? > > Many thx, > R. > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp -- Dipl.-Inform. Michael Hoefling, M.Sc. University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70507, fax: (+49)-7071/29-5220 mailto: hoefling@informatik.uni-tuebingen.de http://kn.inf.uni-tuebingen.de/staff/hoefling From kouvelas@cisco.com Wed Mar 28 00:38:10 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB84321F87C9 for ; Wed, 28 Mar 2012 00:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YLeXkFsQYVE for ; Wed, 28 Mar 2012 00:38:10 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45D21F87B7 for ; Wed, 28 Mar 2012 00:38:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kouvelas@cisco.com; l=1902; q=dns/txt; s=iport; t=1332920288; x=1334129888; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vHv08FPAyDFIk+jd+dtV8jZ3yJ9jRquNrOpNKh5aHoo=; b=FfpNOf9hFOX3S0OYIGDy5le4gkl5PCwIhfA3GEvFnrv4rPcHVZnUbPKf tnHsaRgaqOQnmRBMctMr7uzgc33QSJJHpsQH9gZSIiF/CxyWWsjdry+/L 1YcVnhRCcFZ8IBNx5Cu79Ewl76Rk6mcajbSFzTBJ76xAouIfxO6LtzkmP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGa/ck+rRDoI/2dsb2JhbABFuGuBB4IJAQEBBBIBJUARCxgJFg8JAwIBAgFFEwgBAR6HZ5s4llGIQIpfgnyDJASIUoJoiieGW4dqgWiCaoFR X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="34874012" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Mar 2012 07:38:08 +0000 Received: from sjc-kouvelas-8714.cisco.com (sjc-kouvelas-8714.cisco.com [10.19.208.101]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2S7c7Cg012370 for ; Wed, 28 Mar 2012 07:38:07 GMT Message-ID: <4F72BFDE.6090705@cisco.com> Date: Wed, 28 Mar 2012 10:38:06 +0300 From: Isidor Kouvelas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: lisp@ietf.org References: <4F721A51.4040901@raszuk.net> <3E0371CC-F242-4A70-8C4F-1B7BB1D6FE73@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 07:38:11 -0000 On 28/3/12 2:09 AM, Damien Saucez wrote: > I complete agree that using DNS protocol is not the best idea, even if we proposed it in > the academic paper (ref given by Olivier). First, as Dino and Olivier say, DNS as it is today, > is not very good at "boundary less" prefix matching (binary encoded names). Second, because > the name is of limited size in number of characters you might have troubles with long > addresses with instance ID because of the way you have to encode. And the final two points, > which have been pointed out by Isidor, is that (i) negative mappings are not implementable > as-is in DNS and more importantly (ii) DNS caching is poor for the LISP usage as it is caches > the information with the exact matching and not the wildcard reply. However, I let Isidor > extending the discussion on these two points as his the guy that discovered that (so I give > to Cesar what belongs to Cesar!) Olivier and Damien have accurately summed up the findings of the DNS based mapping system prototype we worked on. - When matching a delegation hole the DNS NXDOMAIN answer does not include information on the hole that was matched in the zone file. This information is required by the resolver to return the negative map-reply to the ITR. - The DNS answer contains the full name that was queried as well as the SOA prefix. It does not contain the name of the wild-card entry in the zone file that was matched by the query and that points to the map-servers. That entry represents the prefix being delegated to the map-server and is what ideally would be cached by the resolvers. - Encoding XEID prefixes would be best done with the DNS bitlabel extensions that have been deprecated and removed from some (most?) implementations. There are ways around all of the above but not without modifying the DNS server / resolver code. Isidor From darlewis@cisco.com Fri Mar 30 04:44:10 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6089E21F87EB for ; Fri, 30 Mar 2012 04:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.89 X-Spam-Level: X-Spam-Status: No, score=-8.89 tagged_above=-999 required=5 tests=[AWL=1.109, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0nhSUrQvUIq for ; Fri, 30 Mar 2012 04:44:09 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3012021F87A3 for ; Fri, 30 Mar 2012 04:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=1446; q=dns/txt; s=iport; t=1333107849; x=1334317449; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cnkzaPZCAknfj+Rnhv2w00D31cC1sMLViK97hXuT/nM=; b=hJbQTncxhoD/6SvyjcQCoRfSpCFfBsjke5LSINda/PLYUNHUZpuVCQZE tgwLEiGRoOwpa7D+b9NCGMH5+IHKR+nkIdECEXYi+1+qLQL7HA3Mjy3IF G9pMl5Gz4wm76mPY3dEnvUdXRbOK9Z78ODDEPQE+uwxt0RecD/6siBojS 4=; X-IronPort-AV: E=Sophos;i="4.75,342,1330905600"; d="scan'208";a="38269903" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 30 Mar 2012 11:44:09 +0000 Received: from sjc-vpn5-909.cisco.com (sjc-vpn5-909.cisco.com [10.21.91.141]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2UBi7Nu019265; Fri, 30 Mar 2012 11:44:08 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Darrel Lewis In-Reply-To: <4F721A51.4040901@raszuk.net> Date: Fri, 30 Mar 2012 04:44:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> References: <4F721A51.4040901@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 11:44:10 -0000 On Mar 27, 2012, at 12:51 PM, Robert Raszuk wrote: > Hi, >=20 > During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and > LISP-DDT Database Transfer stated that this is very much like DNS. >=20 This thread has documented some of the reasons why the authors decided = to develop DDT instead of re-using DNS (documented in LISP-TREE). In = addition to these, the DDT authors felt that operational experience with = LISP+ALT (which re-used BGP and GRE for distributing EID Prefixes) = showed that re-using another protocol, while inheriting many useful = features, also brought in many un-needed features which added bloat to = the implementation and operational complexity to the network.=20 >=20 > If not .. if DDT approach can not be serviced by DNS architecture I = think it would be very useful to document why. Other mapping systems have been explored before with LISP, to various = levels of maturity. (EMACS, CONS, etc). Its my understanding that the = LISP-TREE draft will be updated to reflect the work done to date, which = should include the limitations of this approach. > Also in the same time it would be great to announce plans for open = source DDT support ? All are welcome to contribute to the Open Source LISP (the scope of = which includes the mapping system) effort. More information can be = found at http://www.openlisp.org/). Regards, -Darrel= From robert@raszuk.net Fri Mar 30 06:07:11 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2221F8472 for ; Fri, 30 Mar 2012 06:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFmcyHlgGPf3 for ; Fri, 30 Mar 2012 06:07:10 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 86CC121F8470 for ; Fri, 30 Mar 2012 06:07:10 -0700 (PDT) Received: (qmail 5467 invoked by uid 399); 30 Mar 2012 13:07:09 -0000 Received: from unknown (HELO ?10.0.1.4?) (pbs:robert@raszuk.net@79.141.15.165) by mail1310.opentransfer.com with ESMTPM; 30 Mar 2012 13:07:09 -0000 X-Originating-IP: 79.141.15.165 Message-ID: <4F75B000.7000301@raszuk.net> Date: Fri, 30 Mar 2012 15:07:12 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Darrel Lewis References: <4F721A51.4040901@raszuk.net> <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> In-Reply-To: <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net 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, 30 Mar 2012 13:07:11 -0000 Hi Darrel, My point was not to say that DDT is a wrong approach. I am just looking from user POV and wanted to see why DNS infra (which is relatively easy to reuse) would not offer me the off the shelf open source tools to build a mapping plane. Do you really expect that every SP potentially interested in LISP will develop it's own mapping plane code ? If you look at bigger picture we are right there in the IETF with the need for inter-as globally scoped information distribution. Some push to use BGP new SAFI as an overlay for CDNI, some put more data onto existing DNS, yet some develop new point protocols (DDT). That clearly proves to me the need to have a common service bus .. perhaps reusing a lot of BGP attributes however allowing very easy flexibility for new types of information transport without need to go to IETF and each time argue for 2 years to justify new SAFI. Openlisp as far as I see have no mapping plane code available. I guess the ALT failed as it would have to include full BGP. Maybe with DDT you will have more luck. Contrary openlisp.org has ITR code which practically I would rather have hardware based. Mapping plane is x86/vm appliance based so it would be much more important to download and run (if one needs LISP). Last I was not clear from any presentations how DDT would inter-operate with ALT. Well perhaps there is no issue with migration yet however as we are at the experimental mode and it would be great to see how easy/difficult is to migrate one mapping plane to the other. Best regards, R. > On Mar 27, 2012, at 12:51 PM, Robert Raszuk wrote: > >> Hi, >> >> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC >> and LISP-DDT Database Transfer stated that this is very much like >> DNS. >> > > > This thread has documented some of the reasons why the authors > decided to develop DDT instead of re-using DNS (documented in > LISP-TREE). In addition to these, the DDT authors felt that > operational experience with LISP+ALT (which re-used BGP and GRE for > distributing EID Prefixes) showed that re-using another protocol, > while inheriting many useful features, also brought in many un-needed > features which added bloat to the implementation and operational > complexity to the network. > > >> >> If not .. if DDT approach can not be serviced by DNS architecture I >> think it would be very useful to document why. > > Other mapping systems have been explored before with LISP, to various > levels of maturity. (EMACS, CONS, etc). Its my understanding that > the LISP-TREE draft will be updated to reflect the work done to date, > which should include the limitations of this approach. > > >> Also in the same time it would be great to announce plans for open >> source DDT support ? > > All are welcome to contribute to the Open Source LISP (the scope of > which includes the mapping system) effort. More information can be > found at http://www.openlisp.org/). > > Regards, > > -Darrel > From damien.saucez@gmail.com Fri Mar 30 06:42:04 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4521F86B5 for ; Fri, 30 Mar 2012 06:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJdIiy2pVjOl for ; Fri, 30 Mar 2012 06:42:04 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBF2C21F86B3 for ; Fri, 30 Mar 2012 06:42:03 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so485681wib.13 for ; Fri, 30 Mar 2012 06:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QRa9FbqvlfNzT8rydH/A4ox3RHhqS31ixicv9AbK4cc=; b=rTyn2FpP/TnczJ1wiqgwTJPVOIFqEyPymgOLyGhzyoz1ArQ2Vd5Ld+vTHogBcwwf1W fb1YUBIEiAR/wGyk5qeK88fUYCbdzc4V4YTXmzuuHmkBXmQOtpH7lbtVUjDnYSlcEuo7 yHkNyWKARU6DcVS4RoUckw0Bce7KapHkZQ1lYT9LRTpFSlxtkFBuUyWFS8FQvCwAUAOm ZaAnq5z0Xqdlba1L86+tMSn2bOjFK34UIboixgd8Ug7oiIGb/7Q9vVHuyrHhCC4Z1bZ2 chmupHcnfe8Qsjg0vh9b0wvpXxgHpjqyx8gK3OW0q3fIfdNvv+0qLOiuOF2dB00RRjpt 8AcA== Received: by 10.180.101.8 with SMTP id fc8mr6627326wib.12.1333114922996; Fri, 30 Mar 2012 06:42:02 -0700 (PDT) Received: from [192.168.0.146] (AMontsouris-152-1-57-198.w83-202.abo.wanadoo.fr. [83.202.15.198]) by mx.google.com with ESMTPS id n20sm10451571wiw.5.2012.03.30.06.42.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 06:42:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Damien Saucez In-Reply-To: <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> Date: Fri, 30 Mar 2012 15:41:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F26BF2B-A5D6-4906-8130-C0E3A167EF43@gmail.com> References: <4F721A51.4040901@raszuk.net> <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> To: Darrel Lewis X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 13:42:04 -0000 On 30 Mar 2012, at 13:44, Darrel Lewis wrote: >=20 > On Mar 27, 2012, at 12:51 PM, Robert Raszuk wrote: >=20 >> Hi, >>=20 >> During wg meeting today all presentations LISP-DDT, LISP-DDT-SEC and >> LISP-DDT Database Transfer stated that this is very much like DNS. >>=20 > >=20 > This thread has documented some of the reasons why the authors decided = to develop DDT instead of re-using DNS (documented in LISP-TREE). In = addition to these, the DDT authors felt that operational experience with = LISP+ALT (which re-used BGP and GRE for distributing EID Prefixes) = showed that re-using another protocol, while inheriting many useful = features, also brought in many un-needed features which added bloat to = the implementation and operational complexity to the network.=20 >=20 > >>=20 >> If not .. if DDT approach can not be serviced by DNS architecture I = think it would be very useful to document why. >=20 > Other mapping systems have been explored before with LISP, to various = levels of maturity. (EMACS, CONS, etc). Its my understanding that the = LISP-TREE draft will be updated to reflect the work done to date, which = should include the limitations of this approach. >=20 >=20 >> Also in the same time it would be great to announce plans for open = source DDT support ? >=20 > All are welcome to contribute to the Open Source LISP (the scope of = which includes the mapping system) effort. More information can be = found at http://www.openlisp.org/). >=20 We are working on an open source implementation of DDT (to be later = added to OpenLISP) that we are still testing and improving. Feel free to contact us if you are = willing to contribute. Best regards, Damien Saucez > Regards, >=20 > -Darrel > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From darlewis@cisco.com Fri Mar 30 06:57:14 2012 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B1721F84AF for ; Fri, 30 Mar 2012 06:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.952 X-Spam-Level: X-Spam-Status: No, score=-8.952 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSzjmVIEJx41 for ; Fri, 30 Mar 2012 06:57:13 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D99B321F849A for ; Fri, 30 Mar 2012 06:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=darlewis@cisco.com; l=3775; q=dns/txt; s=iport; t=1333115834; x=1334325434; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xVftqpfz2K89EB9136tLTWEKbRTNZBFcZfJG14Cw9so=; b=COSW0ax1Wn7JA3E3Cdv26Kr22s43iEWai3IJt5rFx0L0DQ+7xCc9pwe5 Dv+ivjvEcdiNhOnesA6LHOXpZGGFi79/4YGZrBnXuyE6f6RZ1uM3P24me xDXHcs8kUaXJEjRcVmrX2ORIytNja6eFZb6xeKWhS4tYFEBM1OmhkVtrQ c=; X-IronPort-AV: E=Sophos;i="4.75,344,1330905600"; d="scan'208";a="38373672" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 30 Mar 2012 13:57:13 +0000 Received: from sjc-vpn3-74.cisco.com (sjc-vpn3-74.cisco.com [10.21.64.74]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2UDvBEr005588; Fri, 30 Mar 2012 13:57:12 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Darrel Lewis In-Reply-To: <4F75B000.7000301@raszuk.net> Date: Fri, 30 Mar 2012 06:57:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <421DFF97-9364-4F65-A3A0-6F0255E6FD94@cisco.com> References: <4F721A51.4040901@raszuk.net> <219AA420-A4F0-45F1-82E8-C5706EDAE886@cisco.com> <4F75B000.7000301@raszuk.net> To: robert@raszuk.net X-Mailer: Apple Mail (2.1257) Cc: "lisp@ietf.org" Subject: Re: [lisp] DDT vs DNS X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 13:57:14 -0000 Hi Robert, On Mar 30, 2012, at 6:07 AM, Robert Raszuk wrote: > Hi Darrel, >=20 > My point was not to say that DDT is a wrong approach. I am just = looking from user POV and wanted to see why DNS infra (which is = relatively easy to reuse) would not offer me the off the shelf open = source tools to build a mapping plane. Do you really expect that every = SP potentially interested in LISP will develop it's own mapping plane = code ? No of course not, I'm sorry if I gave that impression. I expect (hope?) = there will be implementations from a variety vendors, as well as open = source implementations. >=20 > If you look at bigger picture we are right there in the IETF with the = need for inter-as globally scoped information distribution. Some push to = use BGP new SAFI as an overlay for CDNI, some put more data onto = existing DNS, yet some develop new point protocols (DDT). That clearly = proves to me the need to have a common service bus .. perhaps reusing a = lot of BGP attributes however allowing very easy flexibility for new = types of information transport without need to go to IETF and each time = argue for 2 years to justify new SAFI. Personally, I like the fact that there are a wide set of solutions to a = variety of different problems. But I can see how others might find the = current environment an opportunity for consolidation. >=20 > Openlisp as far as I see have no mapping plane code available. I have heard from people here in Paris that they are on open source DDT = Mapping system code, and I was told that they welcome contributions. :-) > I guess the ALT failed as it would have to include full BGP. I don't think the ALT failed per say (though, admittedly, I'm biased :-) = ). But I do think it was found to have some properties that operators = found costly and we wanted to do better. As I said in my earlier = message, a part of that cost was the use of a protocol that wasn't = explicitly designed for LISP. The original charter of the LISP WG = explicitly encouraged further mapping system experimentation, something = the authors of LISP+ALT have been enthusiastically working on. > Maybe with DDT you will have more luck. Contrary openlisp.org has ITR = code which practically I would rather have hardware based. Mapping plane = is x86/vm appliance based so it would be much more important to download = and run (if one needs LISP). >=20 I agree that it makes sense to have solutions in the mapping plane that = can be independent of hardware forwarding implementations. > Last I was not clear from any presentations how DDT would = inter-operate with ALT. Well perhaps there is no issue with migration = yet however as we are at the experimental mode and it would be great to = see how easy/difficult is to migrate one mapping plane to the other. We spent some time talking about interoperability and decided that it = was less costly to migrate directly to DDT. We migrated the LISP Beta = Network (www.lisp4.net) from LISP+ALT to LISP-DDT a couple of weeks ago. = The migration went smoothly, and we've gotten a good bit of feedback on = the protocol that the authors hope to reflect in future versions of the = draft. One thing to note is that the sites did not notice the change, = since xTRs interface to the mapping system with Map-Resolvers and = Map-Servers, and those interfaces did not change. We have recently added a second, independent to the Beta Network, lisp = service provider network to the LISP-DDT mapping system, and have plans = for connecting other LISP networks in the coming weeks. For more = information about the ongoing deployment of LISP-DDT, you can check out = ddt-root.org. Regards, -Darrel